avec Solaris l'executable se lance simplement en tapant son nom tant que
je suis dans le repertoire courant.
Avec Ubuntu j'ai le message d'erreur suivant : "bash:a.out:commande not
found". Je comprends que l'executable n'est pas recherché dans le
repertoire courant mais dans la liste des commandes de bash. Si c'est ça
pourquoi et comment y remedier autrement qu'en tapant './a.out' pour que
la recherche soit faite dans le repertoire courant?
Merci de votre aide.
--
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé.
Même pour une utilisation purement bureautique, il y a quelques moyens pour un extérieur de placer des fichiers avec le nom qu'il veut. Par exemple : Firefox, quand il télécharge un fichier pour le transmettre à une application extérieure (un PDF pour xpdf, typiquement), le met dans /tmp et essaie de préserver le nom original. Dans ces condition, un fichier ls servi avec le content-type application/pdf doit donc suffire.
screetch wrote in message <43d75c7a$0$1380$626a54ce@news.free.fr>:
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la
machine, je ne vois pas l'interet de placer une sécurité pour un trojan
qu'on aurait soi même placé.
Même pour une utilisation purement bureautique, il y a quelques moyens pour
un extérieur de placer des fichiers avec le nom qu'il veut. Par exemple :
Firefox, quand il télécharge un fichier pour le transmettre à une
application extérieure (un PDF pour xpdf, typiquement), le met dans /tmp et
essaie de préserver le nom original. Dans ces condition, un fichier ls servi
avec le content-type application/pdf doit donc suffire.
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé.
Même pour une utilisation purement bureautique, il y a quelques moyens pour un extérieur de placer des fichiers avec le nom qu'il veut. Par exemple : Firefox, quand il télécharge un fichier pour le transmettre à une application extérieure (un PDF pour xpdf, typiquement), le met dans /tmp et essaie de préserver le nom original. Dans ces condition, un fichier ls servi avec le content-type application/pdf doit donc suffire.
Jean-Louis Liagre
Paul Gaborit wrote:
[...]
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
Paul Gaborit wrote:
[...]
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les
débutants en programmation ne plus rien comprendre :
% cc -o test test.c
% test
%
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera
pas "Hello World !", une autre erreur classique de débutant ...
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
Harpo
Jean-Louis Liagre wrote:
Paul Gaborit wrote:
[...]
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells. Il me semble que pour au moins les ancêtres des shells actuels, c'était une commande, il y a d'ailleurs chez moi un /usr/bin/test. Pour utiliser une commande sur fichier au lieu d'un builtin, en bash :
enable -n command command
On est de moins en moins en charte avec fclc : FU2
-- http://harpo.free.fr/
Jean-Louis Liagre wrote:
Paul Gaborit wrote:
[...]
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les
débutants en programmation ne plus rien comprendre :
% cc -o test test.c
% test
%
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera
pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas
nécessairement le cas de tous les shells.
Il me semble que pour au moins les ancêtres des shells actuels, c'était
une commande, il y a d'ailleurs chez moi un /usr/bin/test.
Pour utiliser une commande sur fichier au lieu d'un builtin, en bash :
enable -n command
command
On est de moins en moins en charte avec fclc : FU2
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells. Il me semble que pour au moins les ancêtres des shells actuels, c'était une commande, il y a d'ailleurs chez moi un /usr/bin/test. Pour utiliser une commande sur fichier au lieu d'un builtin, en bash :
enable -n command command
On est de moins en moins en charte avec fclc : FU2
-- http://harpo.free.fr/
Stephane Chazelas
On Wed, 25 Jan 2006 18:28:17 +0000 (UTC), Nicolas George wrote:
screetch wrote in message <43d75c7a$0$1380$:
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé.
Même pour une utilisation purement bureautique, il y a quelques moyens pour un extérieur de placer des fichiers avec le nom qu'il veut. Par exemple : Firefox, quand il télécharge un fichier pour le transmettre à une application extérieure (un PDF pour xpdf, typiquement), le met dans /tmp et essaie de préserver le nom original. Dans ces condition, un fichier ls servi avec le content-type application/pdf doit donc suffire.
Ce fichier n'aura pas les permissions d'execution.
-- Stephane
On Wed, 25 Jan 2006 18:28:17 +0000 (UTC), Nicolas George wrote:
screetch wrote in message <43d75c7a$0$1380$626a54ce@news.free.fr>:
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la
machine, je ne vois pas l'interet de placer une sécurité pour un trojan
qu'on aurait soi même placé.
Même pour une utilisation purement bureautique, il y a quelques moyens pour
un extérieur de placer des fichiers avec le nom qu'il veut. Par exemple :
Firefox, quand il télécharge un fichier pour le transmettre à une
application extérieure (un PDF pour xpdf, typiquement), le met dans /tmp et
essaie de préserver le nom original. Dans ces condition, un fichier ls servi
avec le content-type application/pdf doit donc suffire.
Ce fichier n'aura pas les permissions d'execution.
On Wed, 25 Jan 2006 18:28:17 +0000 (UTC), Nicolas George wrote:
screetch wrote in message <43d75c7a$0$1380$:
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé.
Même pour une utilisation purement bureautique, il y a quelques moyens pour un extérieur de placer des fichiers avec le nom qu'il veut. Par exemple : Firefox, quand il télécharge un fichier pour le transmettre à une application extérieure (un PDF pour xpdf, typiquement), le met dans /tmp et essaie de préserver le nom original. Dans ces condition, un fichier ls servi avec le content-type application/pdf doit donc suffire.
Ce fichier n'aura pas les permissions d'execution.
-- Stephane
Nicolas George
Stephane Chazelas wrote in message :
Ce fichier n'aura pas les permissions d'execution.
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit quand même y avoir des scénarii plausibles.
Stephane Chazelas wrote in message
<slrndth13c.3rj.stephane_chazelas@duey.spider.com>:
Ce fichier n'aura pas les permissions d'execution.
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit
quand même y avoir des scénarii plausibles.
Ce fichier n'aura pas les permissions d'execution.
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit quand même y avoir des scénarii plausibles.
Jean-Louis Liagre
Harpo wrote:
Jean-Louis Liagre wrote:
Paul Gaborit wrote:
[...]
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans, et dans *tous* leurs descendants et clones, soit l'immense majorité des shells utilisés aujourd'hui (sh, ksh, pdksh, bash, zsh, csh, tcsh, ...)
Harpo wrote:
Jean-Louis Liagre wrote:
Paul Gaborit wrote:
[...]
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les
débutants en programmation ne plus rien comprendre :
% cc -o test test.c
% test
%
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera
pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas
nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans,
et dans *tous* leurs descendants et clones, soit l'immense majorité des
shells utilisés aujourd'hui (sh, ksh, pdksh, bash, zsh, csh, tcsh, ...)
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans, et dans *tous* leurs descendants et clones, soit l'immense majorité des shells utilisés aujourd'hui (sh, ksh, pdksh, bash, zsh, csh, tcsh, ...)
Stephane Chazelas
On Thu, 26 Jan 2006 13:21:42 +0100, Jean-Louis Liagre wrote: [...]
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans, et dans *tous* leurs descendants et clones, soit l'immense majorité des shells utilisés aujourd'hui (sh, ksh, pdksh, bash, zsh, csh, tcsh, ...)
Non, il ne l'etait pas dans les premieres version du Bourne shell et il ne l'est toujours pas dans csh ou tcsh. Il ne l'est pas dans rc ou ses descendants non plus IIRC.
-- Stephane
On Thu, 26 Jan 2006 13:21:42 +0100, Jean-Louis Liagre wrote:
[...]
% cc -o test test.c
% test
%
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera
pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas
nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans,
et dans *tous* leurs descendants et clones, soit l'immense majorité des
shells utilisés aujourd'hui (sh, ksh, pdksh, bash, zsh, csh, tcsh, ...)
Non, il ne l'etait pas dans les premieres version du Bourne
shell et il ne l'est toujours pas dans csh ou tcsh. Il ne l'est
pas dans rc ou ses descendants non plus IIRC.
On Thu, 26 Jan 2006 13:21:42 +0100, Jean-Louis Liagre wrote: [...]
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
Même si "." est dans le PATH, l'exemple ci dessus n'affichera pas "Hello World !", une autre erreur classique de débutant ...
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans, et dans *tous* leurs descendants et clones, soit l'immense majorité des shells utilisés aujourd'hui (sh, ksh, pdksh, bash, zsh, csh, tcsh, ...)
Non, il ne l'etait pas dans les premieres version du Bourne shell et il ne l'est toujours pas dans csh ou tcsh. Il ne l'est pas dans rc ou ses descendants non plus IIRC.
-- Stephane
screetch
Nicolas George wrote:
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit quand même y avoir des scénarii plausibles. je trouve que c'est justement le genre de "paranoia" de ce qui pourrait
eventuellement arriver, qui est tout a fait valable sur une machine partagée ou un serveur mais correspond a du surarmement pour une machine d'un utilisateur lambda relié a internet.
Nicolas George wrote:
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit
quand même y avoir des scénarii plausibles.
je trouve que c'est justement le genre de "paranoia" de ce qui pourrait
eventuellement arriver, qui est tout a fait valable sur une machine
partagée ou un serveur mais correspond a du surarmement pour une machine
d'un utilisateur lambda relié a internet.
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit quand même y avoir des scénarii plausibles. je trouve que c'est justement le genre de "paranoia" de ce qui pourrait
eventuellement arriver, qui est tout a fait valable sur une machine partagée ou un serveur mais correspond a du surarmement pour une machine d'un utilisateur lambda relié a internet.
Harpo
Jean-Louis Liagre wrote:
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans,
Ce n'est pas galant de me faire remarquer mon age.
Jean-Louis Liagre wrote:
C'est parce que test est une builtin de bash, mais ce n'est pas
nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans,
Ce n'est pas galant de me faire remarquer mon age.
C'est parce que test est une builtin de bash, mais ce n'est pas nécessairement le cas de tous les shells.
C'est une builtin dans le bourne shell et csh depuis au moins 20 ans,
Ce n'est pas galant de me faire remarquer mon age.
Harpo
screetch wrote:
Nicolas George wrote:
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit quand même y avoir des scénarii plausibles.
je trouve que c'est justement le genre de "paranoia" de ce qui pourrait eventuellement arriver, qui est tout a fait valable sur une machine partagée ou un serveur mais correspond a du surarmement pour une machine d'un utilisateur lambda relié a internet.
L'utilisateur lambda a souvent un serveur Apache pour tester son site web où il montre les dernières photos de son chien et de sa femme pendant ses dernières vacances à Vesoul. S'il regardait ses logs il serait sans doute étonné du nombre d'attaques, certes minables, qu'il reçoit tous les jours. Il ne sait généralement pas non plus quels sont les ports ouverts sur sa machine. Ce n'est pas une question de paranoïa, surtout s'il sait que backup et restore sont les deux mammelles de l'informatique.
screetch wrote:
Nicolas George wrote:
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais
il doit quand même y avoir des scénarii plausibles.
je trouve que c'est justement le genre de "paranoia" de ce qui
pourrait eventuellement arriver, qui est tout a fait valable sur une
machine partagée ou un serveur mais correspond a du surarmement pour
une machine d'un utilisateur lambda relié a internet.
L'utilisateur lambda a souvent un serveur Apache pour tester son site
web où il montre les dernières photos de son chien et de sa femme
pendant ses dernières vacances à Vesoul. S'il regardait ses logs il
serait sans doute étonné du nombre d'attaques, certes minables, qu'il
reçoit tous les jours. Il ne sait généralement pas non plus quels sont
les ports ouverts sur sa machine.
Ce n'est pas une question de paranoïa, surtout s'il sait que backup et
restore sont les deux mammelles de l'informatique.
Ah oui, bien vu. Bon, ce ne sera probablement pas aussi simple, mais il doit quand même y avoir des scénarii plausibles.
je trouve que c'est justement le genre de "paranoia" de ce qui pourrait eventuellement arriver, qui est tout a fait valable sur une machine partagée ou un serveur mais correspond a du surarmement pour une machine d'un utilisateur lambda relié a internet.
L'utilisateur lambda a souvent un serveur Apache pour tester son site web où il montre les dernières photos de son chien et de sa femme pendant ses dernières vacances à Vesoul. S'il regardait ses logs il serait sans doute étonné du nombre d'attaques, certes minables, qu'il reçoit tous les jours. Il ne sait généralement pas non plus quels sont les ports ouverts sur sa machine. Ce n'est pas une question de paranoïa, surtout s'il sait que backup et restore sont les deux mammelles de l'informatique.
