-- Si vous êtes victime d'un cambriolage parce que vous avez oublié de fermer une porte de votre logement, ce n'est pas en refermant simplement cette porte que le cambrioleur, qui connait désormais votre habitat, ne reviendra pas... par une fenêtre laissée ouverte. --{ Nan'Art sécurise les pages perso }--
--{ Nicolas George a plopé ceci: }--
echo est un composant de terminal
Elle sort d'où, cette traduction d'illetré ?
Bah, voyons, du Gnome...
--
Si vous êtes victime d'un cambriolage parce que vous avez oublié de fermer une
porte de votre logement, ce n'est pas en refermant simplement cette porte que
le cambrioleur, qui connait désormais votre habitat, ne reviendra pas... par
une fenêtre laissée ouverte. --{ Nan'Art sécurise les pages perso }--
-- Si vous êtes victime d'un cambriolage parce que vous avez oublié de fermer une porte de votre logement, ce n'est pas en refermant simplement cette porte que le cambrioleur, qui connait désormais votre habitat, ne reviendra pas... par une fenêtre laissée ouverte. --{ Nan'Art sécurise les pages perso }--
mpg
Le (on) mardi 29 janvier 2008 21:54, Nicolas George a écrit (wrote) :
YBM wrote in message <479f9062$0$24031$:
echo est un composant de terminal
Elle sort d'où, cette traduction d'illetré ?
Autant la différence entre un shell et un terminal, oki, je vois, autant je ne saurais pas comment traduire builtin si j'avais à la faire. Des idées ?
Manuel.
Le (on) mardi 29 janvier 2008 21:54, Nicolas George a écrit (wrote) :
YBM wrote in message <479f9062$0$24031$426a74cc@news.free.fr>:
echo est un composant de terminal
Elle sort d'où, cette traduction d'illetré ?
Autant la différence entre un shell et un terminal, oki, je vois, autant je
ne saurais pas comment traduire builtin si j'avais à la faire. Des idées ?
Elle est atroce, on en parlait dans f.c.u il y a peu... et surtout incorrecte, echo est un composant (à la limite) du ... shell (interpréteur de commandes si on insiste).
en anglais c'est "shell builtin"
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
YBM wrote in message <479f9062$0$24031$426a74cc@news.free.fr>:
echo est un composant de terminal
Elle sort d'où, cette traduction d'illetré ?
Elle est atroce, on en parlait dans f.c.u il y a peu...
et surtout incorrecte, echo est un composant (à la limite)
du ... shell (interpréteur de commandes si on insiste).
en anglais c'est "shell builtin"
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Elle est atroce, on en parlait dans f.c.u il y a peu... et surtout incorrecte, echo est un composant (à la limite) du ... shell (interpréteur de commandes si on insiste).
en anglais c'est "shell builtin"
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
mpg
Le (on) mercredi 30 janvier 2008 01:01, YBM a écrit (wrote) :
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Voyons voir :
:~$ ls > /dev/null && type ls ls is hashed (/bin/ls)
Ah oui, en effet. C'est censé vouloir dire quoi ?
Notons par ailleurs que sous zsh :
:~% ls > /dev/null && type ls ls is /bin/ls
Bien sûr, je dis ça en passant... :)
Manuel.
Le (on) mercredi 30 janvier 2008 01:01, YBM a écrit (wrote) :
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Voyons voir :
mpg@siegel:~$ ls > /dev/null && type ls
ls is hashed (/bin/ls)
Ah oui, en effet. C'est censé vouloir dire quoi ?
Notons par ailleurs que sous zsh :
mpg@siegel:~% ls > /dev/null && type ls
ls is /bin/ls
Le (on) mercredi 30 janvier 2008 01:01, YBM a écrit (wrote) :
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Voyons voir :
:~$ ls > /dev/null && type ls ls is hashed (/bin/ls)
Ah oui, en effet. C'est censé vouloir dire quoi ?
Notons par ailleurs que sous zsh :
:~% ls > /dev/null && type ls ls is /bin/ls
Bien sûr, je dis ça en passant... :)
Manuel.
YBM
Le (on) mercredi 30 janvier 2008 01:01, YBM a écrit (wrote) :
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Voyons voir :
:~$ ls > /dev/null && type ls ls is hashed (/bin/ls)
Ah oui, en effet. C'est censé vouloir dire quoi ?
Que l'entrée 'ls' est présente dans le cache des commandes externes qui permet à bash d'éviter à reparcourir le PATH. L'information est pertinente par rapport à ce que dit zsh :
Notons par ailleurs que sous zsh : :~% ls > /dev/null && type ls ls is /bin/ls
Puisqu'on peut, alors, comprendre que si on a déplacé la commande, ou placé une commande de même nom dans un répertoire mieux placé dans PATH, ça ne marche pas très bien.
L'erreur est de donner une information inutile (mon cache est une table de hachage, la belle affaire).
En français c'est pire, on ajoute la traduction pédante à l'information inutile :
$ mv --help > /dev/null && type mv mv est brouillé (/bin/mv)
(l'exemple avec ls n'est pas parlant dans mon cas, puisqu'il est un alias).
Le (on) mercredi 30 janvier 2008 01:01, YBM a écrit (wrote) :
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Voyons voir :
mpg@siegel:~$ ls > /dev/null && type ls
ls is hashed (/bin/ls)
Ah oui, en effet. C'est censé vouloir dire quoi ?
Que l'entrée 'ls' est présente dans le cache des commandes
externes qui permet à bash d'éviter à reparcourir le PATH.
L'information est pertinente par rapport à ce que dit zsh :
Notons par ailleurs que sous zsh :
mpg@siegel:~% ls > /dev/null && type ls
ls is /bin/ls
Puisqu'on peut, alors, comprendre que si on a déplacé
la commande, ou placé une commande de même nom dans un
répertoire mieux placé dans PATH, ça ne marche pas très
bien.
L'erreur est de donner une information inutile (mon cache
est une table de hachage, la belle affaire).
En français c'est pire, on ajoute la traduction pédante à
l'information inutile :
$ mv --help > /dev/null && type mv
mv est brouillé (/bin/mv)
(l'exemple avec ls n'est pas parlant dans mon cas, puisqu'il
est un alias).
Le (on) mercredi 30 janvier 2008 01:01, YBM a écrit (wrote) :
il y a pire : ls > /dev/null && type ls
(et là c'est sacrément discutable en anglais aussi)
Voyons voir :
:~$ ls > /dev/null && type ls ls is hashed (/bin/ls)
Ah oui, en effet. C'est censé vouloir dire quoi ?
Que l'entrée 'ls' est présente dans le cache des commandes externes qui permet à bash d'éviter à reparcourir le PATH. L'information est pertinente par rapport à ce que dit zsh :
Notons par ailleurs que sous zsh : :~% ls > /dev/null && type ls ls is /bin/ls
Puisqu'on peut, alors, comprendre que si on a déplacé la commande, ou placé une commande de même nom dans un répertoire mieux placé dans PATH, ça ne marche pas très bien.
L'erreur est de donner une information inutile (mon cache est une table de hachage, la belle affaire).
En français c'est pire, on ajoute la traduction pédante à l'information inutile :
$ mv --help > /dev/null && type mv mv est brouillé (/bin/mv)
(l'exemple avec ls n'est pas parlant dans mon cas, puisqu'il est un alias).
Thierry B.
--{ Nicolas George a plopé ceci: }--
"Thierry B." wrote in message :
Bah, voyons, du Gnome...
Le rapport entre Gnome et bash ?
La "traduction d'illetré" ?
-- { SIGWHAT?!!, "BACKSIGNAL" }, /* the processus signal the kill program it disagree with the previous signal given. See anarchy(3) */ --{ f.m.b.l revisite la command kill }--
--{ Nicolas George a plopé ceci: }--
"Thierry B." wrote in message <j5i475-obs.ln1@prout.stex>:
Bah, voyons, du Gnome...
Le rapport entre Gnome et bash ?
La "traduction d'illetré" ?
--
{ SIGWHAT?!!, "BACKSIGNAL" },
/* the processus signal the kill program it disagree
with the previous signal given. See anarchy(3) */
--{ f.m.b.l revisite la command kill }--
-- { SIGWHAT?!!, "BACKSIGNAL" }, /* the processus signal the kill program it disagree with the previous signal given. See anarchy(3) */ --{ f.m.b.l revisite la command kill }--
Nicolas George
YBM wrote in message <479fdba7$0$8483$:
Puisqu'on peut, alors, comprendre que si on a déplacé la commande, ou placé une commande de même nom dans un répertoire mieux placé dans PATH, ça ne marche pas très bien.
zsh donne aussi cette information, puisqu'il indique le chemin de la commande. Par exemple :
~ $ type cat cat is /bin/cat
Qui s'oppose à :
~ $ where cat /home/cigaes/bin/cat /bin/cat
YBM wrote in message <479fdba7$0$8483$426a34cc@news.free.fr>:
Puisqu'on peut, alors, comprendre que si on a déplacé
la commande, ou placé une commande de même nom dans un
répertoire mieux placé dans PATH, ça ne marche pas très
bien.
zsh donne aussi cette information, puisqu'il indique le chemin de la
commande. Par exemple :
Puisqu'on peut, alors, comprendre que si on a déplacé la commande, ou placé une commande de même nom dans un répertoire mieux placé dans PATH, ça ne marche pas très bien.
zsh donne aussi cette information, puisqu'il indique le chemin de la commande. Par exemple :
