comportement de grep bizarre ?

Stephane Chazelas wrote:

Ca devrait etre:

eval "`dircolors -<option>`"

La page de manuel de dircolors donne pourtant:

Typical usage:
eval `dircolors [OPTION] ... [FILE]`

(For fileutils-3.16 with color-ls patch 3.12.0.3)


Quant à "eval", dans la page de sh (ash-0.4):

eval string...
Concatenate all the arguments with spaces. Then re-parse and execute
the command.


Qu'est-ce qui fait de l'absence de double-quotes (guillemets ??) un bogue ?

C'est un bug a signaler aux mainteneurs de la distribution/du
systeme, a mon avis.

Hélas, il est gravement malade...
J'attends le développement de votre réponse avant d'évoquer la question
sur les ng/ml approprié(e)s.

2004-12-14, 16:52(+01), gregg:

Stephane Chazelas wrote:

Ca devrait etre:

eval "`dircolors -<option>`"

La page de manuel de dircolors donne pourtant:

Typical usage:
eval `dircolors [OPTION] ... [FILE]`

Hop! Un autre bug.

[...]

Quant à "eval", dans la page de sh (ash-0.4):

eval string...
Concatenate all the arguments with spaces. Then re-parse and execute
the command.


Qu'est-ce qui fait de l'absence de double-quotes (guillemets ??) un bogue ?

Sans quote, le resultat de:

`dircolors -...` est sujet a word splitting et filename
generation (sauf en zsh ou il y a juste le word splitting).

Le resultat de dircolors -b, chez moi est quelquechose comme:

LS_COLORS='no:fi:di
;34:ln
;36:pi@;33:so
;35:do=0
1;35:bd@;33;01:cd@;33;01:or@;31;01:ex
;32:*.tar
;31:*
.tgz
;31:';
export LS_COLORS

(sans les saut de lignes).

Avec la valeur par defaut d'IFS, sans les quotes, ca va etre
decoupé en 3 mots:

"LS_...35:';", "export" et "LS_COLORS". A cause des "*", le
premier mot est un pattern, donc le shell va chercher dans le
repertoire courant les fichiers correspondant.

Par exemple, si je fais:

touch "LS_COLORS='no:fi:di
;34:ln
;36:pi@;33:so
;
35:do
;35:bd@;33;01:cd@;33;01:or@;31;01:ex
;32:Z.tar=
01;31:'; rm -rf $HOME; : '.tgz
;31:';"

devinez ce qui va se passer, si je fais un:

eval `dircolors -b`

Pour avoir une petite idee:

$ bash -c 'echo `dircolors -b a`'
LS_COLORS='no:fi:di
;34:ln
;36:pi@;33:so
;35:do

;35:bd@;33;01:cd@;33;01:or@;31;01:ex
;32:Z.tar
;31:';
rm -rf $HOME; : '.tgz
;31:'; export LS_COLORS

Heureusement que j'ai utilisé "echo" a la place de "eval"!

--
Stephane

( Tue, 14 Dec 2004 16:30:56 +0000 ) Stephane Chazelas :
[...]
<soupir>
Encore un autre sujet ou je sens que je comprends pas grand chose.
Avec le truc sur le character encoding, et les histoires de rxvt, ca
commence a faire un sacré paquet... (snif...)

--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)

Rakotomandimby (R12y) Mihamina wrote:

( Tue, 14 Dec 2004 16:30:56 +0000 ) Stephane Chazelas :
[...]
<soupir>
Encore un autre sujet ou je sens que je comprends pas grand chose.
Avec le truc sur le character encoding, et les histoires de rxvt, ca
commence a faire un sacré paquet... (snif...)

C'est juste une histoire de caractères de contrôle, placés devant les

informations affichées, indiquant au terminal des informations sur les
attributs d'affichage (couleur text/fond, etc.) transparents à l'ouil du
lecteur. Il n'en reste pas moins, que ces informations sont perçues
comme des caractères supplémentaires par les programmes lisant ces
informations au travers d'un pipe.

Le 14 Dec 2004, Stephane Chazelas a dit :

devinez ce qui va se passer, si je fais un:

eval `dircolors -b`

Pour avoir une petite idee:

$ bash -c 'echo `dircolors -b a`'
LS_COLORS='no:fi:di
;34:ln
;36:pi@;33:so
;35:do

;35:bd@;33;01:cd@;33;01:or@;31;01:ex
;32:Z.tar
;31:';
rm -rf $HOME; : '.tgz
;31:'; export LS_COLORS

Heureusement que j'ai utilisé "echo" a la place de "eval"!

Ce genre de piège à con, tu connais par la pratique et parce que tu es bon,
ou pour t'être cassé les dents dessus ?
C'est sûr qu'on doit mieux s'en rappeler après avoir viré son $HOME...

Sébastien Kirche

2004-12-15, 00:08(+01), Rakotomandimby (R12y) Mihamina:

( Tue, 14 Dec 2004 16:30:56 +0000 ) Stephane Chazelas :
[...]
<soupir>
Encore un autre sujet ou je sens que je comprends pas grand chose.
Avec le truc sur le character encoding, et les histoires de rxvt, ca
commence a faire un sacré paquet... (snif...)

Pour voir la difference entre _avec_ et _sans_ quotes,

Essaie (avec bash, sh ou ksh):

var='* | .* | *.txt'
IFS='| '
printf '1<%s>n' $var
printf '2<%s>n' "$var"
printf '3<%s>n' `printf %b '52'`
printf '4<%s>n' "`printf %b '52'`"

Avec zsh,

var=''
IFS='| '
printf '1<%s>n' $var
printf '2<%s>n' "$var"
printf '3<%s>n' `echo 'a | b'`
printf '4<%s>n' "`echo 'a | b'`"

--
Stephane

2004-12-15, 09:49(+01), Sebastien Kirche:

Le 14 Dec 2004, Stephane Chazelas a dit :

devinez ce qui va se passer, si je fais un:

eval `dircolors -b`

Pour avoir une petite idee:

$ bash -c 'echo `dircolors -b a`'
LS_COLORS='no:fi:di
;34:ln
;36:pi@;33:so
;35:do

;35:bd@;33;01:cd@;33;01:or@;31;01:ex
;32:Z.tar
;31:';
rm -rf $HOME; : '.tgz
;31:'; export LS_COLORS

Heureusement que j'ai utilisé "echo" a la place de "eval"!

Ce genre de piège à con, tu connais par la pratique et parce que tu es bon,
ou pour t'être cassé les dents dessus ?

C'est une regle elementaire de shell scripting, c'est dommage
que l'accent ne soit pas plus mis dessus dans la plupart des
manuels.

On quote toujours les variables et les "command substitution"
(ou on utilise des variables intermediaires) sauf quand on a une
bonne raison de ne pas le faire.

Et les bonnes raisons de ne pas le faire, c'est quand on veut
utiliser justement le "word splitting" et/ou la "filename
generation", auquel cas il faut bien s'assurer de la valeur
d'IFS et du positionnement du flag "f".

Dans:

rm `ls`

vraissemblablement, je ne veux pas effacer *le* fichier dont le
nom est l'output de ls. Je veux plutot considerer l'output de ls
comme une liste de fichiers (separés par des n). Par contre, si
un des fichiers s'appelle "*", ca ne veut pas dire pour autant
que je veux prendre ca pour la liste des fichiers dans le
repertoire courant.

Donc, si je veux faire rm `ls`, il faut d'abord que je fasse:

IFS='
' # c'est une liste separee par des sauts de lignes (tant pis
# pour les fichiers dont le nom contient des sauts de ligne)
set -f # "*" doit etre pris pour le fichier "*", pas pour la
# liste des fichiers dans le repertoire courant
rm -- `ls` # les arguments sont bien des fichiers, pas des
# options a passer a rm.

Evidemment:

rm -- *

est plus approprié dans ce cas.

--
Stephane

Stephane Chazelas wrote:

eval "`dircolors -<option>`"

C'est un bug a signaler aux mainteneurs de la distribution/du
systeme, a mon avis.

J'ai eu l'occasion d'utiliser un système GNU/Linux Fedora, ce matin, et
le etc/profile.d/colors.sh lui non plus ne contenait pas de "" pour
encadrer eval...

Je me demande combien de systèmes n'implémentent pas ?

++

2004-12-15, 23:09(+01), gregg:

Stephane Chazelas wrote:

eval "`dircolors -<option>`"

C'est un bug a signaler aux mainteneurs de la distribution/du
systeme, a mon avis.

J'ai eu l'occasion d'utiliser un système GNU/Linux Fedora, ce matin, et
le etc/profile.d/colors.sh lui non plus ne contenait pas de "" pour
encadrer eval...

Je me demande combien de systèmes n'implémentent pas ?
[...]

J'ai signalé le probleme de documentation aux mainteneurs de
coreutils. C'est fixé dans la version accessible par CVS.
Le developpeur a soumis un bug report pour debian (qui a le
probleme apparemment), tu peux peut-etre en soumettre un aux
gens de Fedora.

Voir:

http://lists.gnu.org/archive/html/bug-coreutils/2004-12/msg00058.html

Cela dit, la plupart des scripts sur la plupart des
distributions ont des problemes similaires. A croire que
personne ne connait les principes de base du shell scripting (on
ne peut pas trop les blamer, c'est tellement awkward).

--
Stephane