je croyais que which indiquait l'emplacement de tous les logiciels dont
on donne le nom, present dans le PATH
je viens de m'appercevoir que non, il ne donne que celui qui va etre
executé, cad le 1er
y a t il qqch qui puisse repondre à mon besoin ?
j'ai fait un tas de petits logiciels avec des noms tres courts,
et je me suis demandé apres si il n'y avait pas dans le systeme des
logiciels avec les memes noms (auquel cas ca pourrait poser des pbs :-/ )
donc j'ai besoin de ca pour verifier maintenant si il y a chevauchement
ou pas :-)
--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
Sur les BSD, il y a whereis qui permet de rechercher ça, et bien plus. On doit le trouver sur les Linux aussi, normalement. c'est bizarre !
on dirait que ca ne donne que ce qui a été installé par le systeme ca se base sur quoi ?
« man whereis » devrait répondre à votre question. Effectivement, par défaut, il ne se base pas vraiment sur le PATH, et ne retourne qu'un seul résultat. Pour faire ce que vous voulez : $ whereis -a -b -B $PATH -f <cmd>
Sur les BSD, il y a whereis qui permet de rechercher ça, et bien
plus. On doit le trouver sur les Linux aussi, normalement.
c'est bizarre !
on dirait que ca ne donne que ce qui a été installé par le systeme
ca se base sur quoi ?
« man whereis » devrait répondre à votre question. Effectivement, par
défaut, il ne se base pas vraiment sur le PATH, et ne retourne qu'un
seul résultat. Pour faire ce que vous voulez :
$ whereis -a -b -B $PATH -f <cmd>
Sur les BSD, il y a whereis qui permet de rechercher ça, et bien plus. On doit le trouver sur les Linux aussi, normalement. c'est bizarre !
on dirait que ca ne donne que ce qui a été installé par le systeme ca se base sur quoi ?
« man whereis » devrait répondre à votre question. Effectivement, par défaut, il ne se base pas vraiment sur le PATH, et ne retourne qu'un seul résultat. Pour faire ce que vous voulez : $ whereis -a -b -B $PATH -f <cmd>
Arnaud Launay
Le Mon, 4 Jun 2007 09:06:26 +0200, Thierry Boudet écrivit:
J'ai trouvé récemment un O'Reilly "Introduction aux scripts shells" qui répond à toute cette gamme de questions.
Ouais. Celui-là aussi, il est en train de prendre la poussière sur mon parquet... *soupir*
In article (Dans l'article) , Stephane Dupille wrote (écrivait) :
Sur les BSD, il y a whereis qui permet de rechercher ça, et bien plus. On doit le trouver sur les Linux aussi, normalement. c'est bizarre !
on dirait que ca ne donne que ce qui a été installé par le systeme ca se base sur quoi ?
« man whereis » devrait répondre à votre question. Effectivement, par défaut, il ne se base pas vraiment sur le PATH, et ne retourne qu'un seul résultat. Pour faire ce que vous voulez : $ whereis -a -b -B $PATH -f <cmd>
le mien n'a aucune option :-( dommage ...
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <yge6464q6xp.fsf@nospam.fr.eu.org>,
Stephane Dupille <sdupille@NOSPAM.fr.eu.org> wrote (écrivait) :
Sur les BSD, il y a whereis qui permet de rechercher ça, et bien
plus. On doit le trouver sur les Linux aussi, normalement.
c'est bizarre !
on dirait que ca ne donne que ce qui a été installé par le systeme
ca se base sur quoi ?
« man whereis » devrait répondre à votre question. Effectivement, par
défaut, il ne se base pas vraiment sur le PATH, et ne retourne qu'un
seul résultat. Pour faire ce que vous voulez :
$ whereis -a -b -B $PATH -f <cmd>
le mien n'a aucune option :-(
dommage ...
--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) , Stephane Dupille wrote (écrivait) :
Sur les BSD, il y a whereis qui permet de rechercher ça, et bien plus. On doit le trouver sur les Linux aussi, normalement. c'est bizarre !
on dirait que ca ne donne que ce qui a été installé par le systeme ca se base sur quoi ?
« man whereis » devrait répondre à votre question. Effectivement, par défaut, il ne se base pas vraiment sur le PATH, et ne retourne qu'un seul résultat. Pour faire ce que vous voulez : $ whereis -a -b -B $PATH -f <cmd>
le mien n'a aucune option :-( dommage ...
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
Thomas
In article (Dans l'article) <f3vnum$87n$, (Luc Habert) wrote (écrivait) :
Thomas :
si je met ca dans un fichier, avec juste $1 pour $MACHIN, ca suffit ? faut que je precise le nom d'un shell au debut ?
Oui, « #!/bin/sh ». Mon code est du sh,
merci :-)
je n'ai aucune idée de si ça marche avec tcsh.
pas de pb :-)
que fait set -f et set +f ? et à quoi sert IFS ? puisqu'il n'est pas dans la boucle
Quand tu as un « $PLOUM » non quoté (dans mon code, c'était le « $PATH »), son contenu subi deux transformations : - découpage en morceaux séparés par les caractères contenus dans la variable IFS (qui par défaut contient le whitespace) - chaque morceau est ensuite examiné pour voir si il contient des « * », « ? » et « [] », auquel cas il y a expansion en tous les noms de fichiers qui matchent (si il n'y en a pas, le morceau est laissé tel quel, oui, c'est bizarre, mais ça peut être utile).
Donc mon « IFS=: » sert à ce que dans le « for d in $PATH; » le contenu de la variable « PATH » soit découpé sur les « : ». Mais ensuite, je ne veux pas que la deuxième étape soit effectuée, donc je la désactive avec le « set -f ».
merci bcp :-)
À la fin, je restaure la valeur initiale de « IFS », et je réactive le globbing avec « set +f ».
juste une petite derniere question :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal, si j'ai bien compris, quand on met ca dans un fichier qu'on execute, on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans le shell créé pour executer ce script, ca n'a pas été modifié globalement
c'est bien ca ? :-)
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <f3vnum$87n$2@nef.ens.fr>,
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote (écrivait) :
Thomas :
si je met ca dans un fichier, avec juste $1 pour $MACHIN, ca suffit ?
faut que je precise le nom d'un shell au debut ?
Oui, « #!/bin/sh ». Mon code est du sh,
merci :-)
je n'ai aucune idée de si ça marche
avec tcsh.
pas de pb :-)
que fait set -f et set +f ?
et à quoi sert IFS ? puisqu'il n'est pas dans la boucle
Quand tu as un « $PLOUM » non quoté (dans mon code, c'était le « $PATH »),
son contenu subi deux transformations :
- découpage en morceaux séparés par les caractères contenus dans la variable
IFS (qui par défaut contient le whitespace)
- chaque morceau est ensuite examiné pour voir si il contient des « * »,
« ? » et « [] », auquel cas il y a expansion en tous les noms de fichiers
qui matchent (si il n'y en a pas, le morceau est laissé tel quel, oui, c'est
bizarre, mais ça peut être utile).
Donc mon « IFS=: » sert à ce que dans le « for d in $PATH; » le contenu de
la variable « PATH » soit découpé sur les « : ». Mais ensuite, je ne veux
pas que la deuxième étape soit effectuée, donc je la désactive avec le « set
-f ».
merci bcp :-)
À la fin, je restaure la valeur initiale de « IFS », et je réactive le
globbing avec « set +f ».
juste une petite derniere question :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal,
si j'ai bien compris, quand on met ca dans un fichier qu'on execute,
on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans
le shell créé pour executer ce script, ca n'a pas été modifié globalement
c'est bien ca ? :-)
--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <f3vnum$87n$, (Luc Habert) wrote (écrivait) :
Thomas :
si je met ca dans un fichier, avec juste $1 pour $MACHIN, ca suffit ? faut que je precise le nom d'un shell au debut ?
Oui, « #!/bin/sh ». Mon code est du sh,
merci :-)
je n'ai aucune idée de si ça marche avec tcsh.
pas de pb :-)
que fait set -f et set +f ? et à quoi sert IFS ? puisqu'il n'est pas dans la boucle
Quand tu as un « $PLOUM » non quoté (dans mon code, c'était le « $PATH »), son contenu subi deux transformations : - découpage en morceaux séparés par les caractères contenus dans la variable IFS (qui par défaut contient le whitespace) - chaque morceau est ensuite examiné pour voir si il contient des « * », « ? » et « [] », auquel cas il y a expansion en tous les noms de fichiers qui matchent (si il n'y en a pas, le morceau est laissé tel quel, oui, c'est bizarre, mais ça peut être utile).
Donc mon « IFS=: » sert à ce que dans le « for d in $PATH; » le contenu de la variable « PATH » soit découpé sur les « : ». Mais ensuite, je ne veux pas que la deuxième étape soit effectuée, donc je la désactive avec le « set -f ».
merci bcp :-)
À la fin, je restaure la valeur initiale de « IFS », et je réactive le globbing avec « set +f ».
juste une petite derniere question :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal, si j'ai bien compris, quand on met ca dans un fichier qu'on execute, on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans le shell créé pour executer ce script, ca n'a pas été modifié globalement
c'est bien ca ? :-)
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
Thomas
In article (Dans l'article) <f3vnfu$87n$, (Luc Habert) wrote (écrivait) :
Thomas :
moi c'est tcsh
Pitié, oublie cette horreur...
il parait effectivement, que sh c'est bcp mieux pour les scripts mais que tcsh c'est quand meme un peu mieux pour l'interactivité
je me suis habitué à tcsh avec mac os x 10.1, avec l'historique, l'autocompletion quand on tape <tab>, etc
quand apple a mis bash par defaut dans mac os x 10.3, j'ai pas reussi à retrouver mes petits alors je suis vite revenu à tcsh
mais comme je vais bientot acheter un nouveau mac avec mac os x 10.5, je me demande si je ne ferais pas mieux d'y passer ...
à ton avis ? bash peut etre aussi confortable que tcsh à utiliser interactivement ? tu voudras bien m'aider à le parametrer ?
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <f3vnfu$87n$1@nef.ens.fr>,
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote (écrivait) :
Thomas :
moi c'est tcsh
Pitié, oublie cette horreur...
il parait effectivement, que sh c'est bcp mieux pour les scripts
mais que tcsh c'est quand meme un peu mieux pour l'interactivité
je me suis habitué à tcsh avec mac os x 10.1,
avec l'historique, l'autocompletion quand on tape <tab>, etc
quand apple a mis bash par defaut dans mac os x 10.3, j'ai pas reussi à
retrouver mes petits alors je suis vite revenu à tcsh
mais comme je vais bientot acheter un nouveau mac avec mac os x 10.5, je
me demande si je ne ferais pas mieux d'y passer ...
à ton avis ?
bash peut etre aussi confortable que tcsh à utiliser interactivement ?
tu voudras bien m'aider à le parametrer ?
--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <f3vnfu$87n$, (Luc Habert) wrote (écrivait) :
Thomas :
moi c'est tcsh
Pitié, oublie cette horreur...
il parait effectivement, que sh c'est bcp mieux pour les scripts mais que tcsh c'est quand meme un peu mieux pour l'interactivité
je me suis habitué à tcsh avec mac os x 10.1, avec l'historique, l'autocompletion quand on tape <tab>, etc
quand apple a mis bash par defaut dans mac os x 10.3, j'ai pas reussi à retrouver mes petits alors je suis vite revenu à tcsh
mais comme je vais bientot acheter un nouveau mac avec mac os x 10.5, je me demande si je ne ferais pas mieux d'y passer ...
à ton avis ? bash peut etre aussi confortable que tcsh à utiliser interactivement ? tu voudras bien m'aider à le parametrer ?
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
Luc.Habert.00__arjf
Thomas :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal, si j'ai bien compris, quand on met ca dans un fichier qu'on execute, on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans le shell créé pour executer ce script, ca n'a pas été modifié globalement
Oui, tout à fait. Mais si tu intègres ce code dans un script plus grand, il vaut mieux rétablir les valeurs par défaut. En fait, ce que je fais est assez moche : par exemple, si on a déjà fait un OLDIFS=$IFS ailleurs, on casse tout. Certains shells permettent de déclarer des variables comme locales à une fonction, mais ce n'est pas standard. Pour le globbing, en revanche, il y a une solution standard plus satisfaisante :
case $- in *f*) DONTRESTOREGLOB=t;; *) DONTRESTOREGLOB=;; esac ... if test -z "$DONTRESTOREGLOB"; then set +f; fi
Bon, on a toujours le problème de la colision de nom sur la variable, mais tant qu'on n'a pas de récursion, on peut s'en sortir en modifiant le nom de la variable. Et en présence de récursion, on pourrait s'en sortir en calculant le nom de la variable avec « eval », mais ça devient vraiment gore.
Thomas :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal,
si j'ai bien compris, quand on met ca dans un fichier qu'on execute,
on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans
le shell créé pour executer ce script, ca n'a pas été modifié globalement
Oui, tout à fait. Mais si tu intègres ce code dans un script plus grand, il
vaut mieux rétablir les valeurs par défaut. En fait, ce que je fais est
assez moche : par exemple, si on a déjà fait un OLDIFS=$IFS ailleurs, on
casse tout. Certains shells permettent de déclarer des variables comme
locales à une fonction, mais ce n'est pas standard. Pour le globbing, en
revanche, il y a une solution standard plus satisfaisante :
case $- in *f*) DONTRESTOREGLOB=t;; *) DONTRESTOREGLOB=;; esac
...
if test -z "$DONTRESTOREGLOB"; then set +f; fi
Bon, on a toujours le problème de la colision de nom sur la variable, mais
tant qu'on n'a pas de récursion, on peut s'en sortir en modifiant le nom de
la variable. Et en présence de récursion, on pourrait s'en sortir en
calculant le nom de la variable avec « eval », mais ça devient vraiment
gore.
ces parametres qu'on doit retablir si on tape tout ca dans le terminal, si j'ai bien compris, quand on met ca dans un fichier qu'on execute, on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans le shell créé pour executer ce script, ca n'a pas été modifié globalement
Oui, tout à fait. Mais si tu intègres ce code dans un script plus grand, il vaut mieux rétablir les valeurs par défaut. En fait, ce que je fais est assez moche : par exemple, si on a déjà fait un OLDIFS=$IFS ailleurs, on casse tout. Certains shells permettent de déclarer des variables comme locales à une fonction, mais ce n'est pas standard. Pour le globbing, en revanche, il y a une solution standard plus satisfaisante :
case $- in *f*) DONTRESTOREGLOB=t;; *) DONTRESTOREGLOB=;; esac ... if test -z "$DONTRESTOREGLOB"; then set +f; fi
Bon, on a toujours le problème de la colision de nom sur la variable, mais tant qu'on n'a pas de récursion, on peut s'en sortir en modifiant le nom de la variable. Et en présence de récursion, on pourrait s'en sortir en calculant le nom de la variable avec « eval », mais ça devient vraiment gore.
Luc.Habert.00__arjf
Thomas :
il parait effectivement, que sh c'est bcp mieux pour les scripts mais que tcsh c'est quand meme un peu mieux pour l'interactivité
C'est sûr que sh pour l'interactivité... Mais pour ça, le summum, c'est zsh. C'est un croisement entre une usine à gaz et une moussaka géante, mais pour de l'interactif, c'est un peu ce qu'on veut, en fait. (Et je dis ça alors que je n'utilise que très peu de ses features, par exemple je déteste la complétion intelligente, alors que c'est un des points où zsh est proprement hallucinant.)
Thomas :
il parait effectivement, que sh c'est bcp mieux pour les scripts
mais que tcsh c'est quand meme un peu mieux pour l'interactivité
C'est sûr que sh pour l'interactivité... Mais pour ça, le summum, c'est zsh.
C'est un croisement entre une usine à gaz et une moussaka géante, mais pour
de l'interactif, c'est un peu ce qu'on veut, en fait. (Et je dis ça alors
que je n'utilise que très peu de ses features, par exemple je déteste la
complétion intelligente, alors que c'est un des points où zsh est
proprement hallucinant.)
il parait effectivement, que sh c'est bcp mieux pour les scripts mais que tcsh c'est quand meme un peu mieux pour l'interactivité
C'est sûr que sh pour l'interactivité... Mais pour ça, le summum, c'est zsh. C'est un croisement entre une usine à gaz et une moussaka géante, mais pour de l'interactif, c'est un peu ce qu'on veut, en fait. (Et je dis ça alors que je n'utilise que très peu de ses features, par exemple je déteste la complétion intelligente, alors que c'est un des points où zsh est proprement hallucinant.)
Stephane Dupille
[ whereis ]
le mien n'a aucune option :-(
Ce ne serait pas un whereis builtin du shell, par hasard ?
dommage ...
'fectivement, dommage.
[ whereis ]
le mien n'a aucune option :-(
Ce ne serait pas un whereis builtin du shell, par hasard ?
Ce ne serait pas un whereis builtin du shell, par hasard ?
dommage ...
'fectivement, dommage.
Thomas
In article (Dans l'article) <f41887$2d6l$, (Luc Habert) wrote (écrivait) :
Thomas :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal, si j'ai bien compris, quand on met ca dans un fichier qu'on execute, on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans le shell créé pour executer ce script, ca n'a pas été modifié globalement
Oui, tout à fait. Mais si tu intègres ce code dans un script plus grand, il vaut mieux rétablir les valeurs par défaut.
tu veux dire que si on execute un script avec un shell interactif, les variables faites dans le script ne sont pas transmises au shell, mais si on execute un script avec un autre script, les variables sont transmises au script precedent ? bizarre 8-|
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <f41887$2d6l$1@nef.ens.fr>,
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote (écrivait) :
Thomas :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal,
si j'ai bien compris, quand on met ca dans un fichier qu'on execute,
on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans
le shell créé pour executer ce script, ca n'a pas été modifié globalement
Oui, tout à fait. Mais si tu intègres ce code dans un script plus grand, il
vaut mieux rétablir les valeurs par défaut.
tu veux dire que si on execute un script avec un shell interactif, les
variables faites dans le script ne sont pas transmises au shell,
mais si on execute un script avec un autre script, les variables sont
transmises au script precedent ?
bizarre 8-|
--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <f41887$2d6l$, (Luc Habert) wrote (écrivait) :
Thomas :
ces parametres qu'on doit retablir si on tape tout ca dans le terminal, si j'ai bien compris, quand on met ca dans un fichier qu'on execute, on n'a pas besoin de les retablir, parce que ca n'a été modifié que dans le shell créé pour executer ce script, ca n'a pas été modifié globalement
Oui, tout à fait. Mais si tu intègres ce code dans un script plus grand, il vaut mieux rétablir les valeurs par défaut.
tu veux dire que si on execute un script avec un shell interactif, les variables faites dans le script ne sont pas transmises au shell, mais si on execute un script avec un autre script, les variables sont transmises au script precedent ? bizarre 8-|
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
Thomas
In article (Dans l'article) , Stephane Dupille wrote (écrivait) :
[ whereis ]
le mien n'a aucune option :-(
Ce ne serait pas un whereis builtin du shell, par hasard ?
non :
thomas% which whereis /usr/bin/whereis thomas% which which which: shell built-in command.
dommage ...
'fectivement, dommage.
pas grave, j'utilise le script de Luc Habert et ca marche impec :-)
-- Informations sur Nicolas Sarkozy : http://www.betapolitique.fr/spip.php?article0602 http://www.betapolitique.fr/spip.php?article0601 http://www.betapolitique.fr/spip.php?article0414 http://www.betapolitique.fr/spip.php?article0606 http://tDeContes.hd.free.fr/divers/Ruptures.pdf
In article (Dans l'article) <ygey7izpycr.fsf@nospam.fr.eu.org>,
Stephane Dupille <sdupille@NOSPAM.fr.eu.org> wrote (écrivait) :
[ whereis ]
le mien n'a aucune option :-(
Ce ne serait pas un whereis builtin du shell, par hasard ?
non :
thomas% which whereis
/usr/bin/whereis
thomas% which which
which: shell built-in command.
dommage ...
'fectivement, dommage.
pas grave, j'utilise le script de Luc Habert et ca marche impec :-)
--
Informations sur Nicolas Sarkozy :
http://www.betapolitique.fr/spip.php?article0602
http://www.betapolitique.fr/spip.php?article0601
http://www.betapolitique.fr/spip.php?article0414
http://www.betapolitique.fr/spip.php?article0606
http://tDeContes.hd.free.fr/divers/Ruptures.pdf
