[bash] Bug ou feature ?

Bonjour à tous,

Je viens de passer quelques jours à pister un bug dans un script
shell pas compliqué du tout et j'aimerais savoir s'il s'agit d'une
fonctionnalité ou d'un bug (et si c'est une fonctionnalité
m'expliquer pourquoi).

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin
QUEUE=/home/machin/queue

for i in $QUEUE/*.to_be_sent
do
echo $i
done

exit 0

Trivial me direz vous. Lorsque la queue est vide, je ne devrais
obtenir aucune réponse. Raté, j'obtiens un superbe :

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin
QUEUE=/home/machin/queue

for i in $QUEUE/*.to_be_sent
do
echo $i
done

exit 0

Trivial me direz vous. Lorsque la queue est vide, je ne devrais
obtenir aucune réponse. Raté, j'obtiens un superbe :

/home/machin/queue/*.to_be_sent

JKB <jkb@koenigsberg.invalid> writes:

[...]

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin
QUEUE=/home/machin/queue

for i in $QUEUE/*.to_be_sent
do
echo $i
done

exit 0

Trivial me direz vous. Lorsque la queue est vide, je ne devrais
obtenir aucune réponse. Raté, j'obtiens un superbe :

/home/machin/queue/*.to_be_sent

C'est le comportement par défaut de bash (aucune idée si c'est
standard). Le man de bash dit :

Pathname Expansion
After word splitting, unless the -f option has been set, bash scans
each word for the characters *, ?, and [. If one of these characters
appears, then the word is regarded as a pattern, and replaced with an
alphabetically sorted list of file names matching the pattern. If no
matching file names are found, and the shell option nullglob is not
enabled, the word is left unchanged. If the nullglob option is set,
and no matches are found, the word is removed. If the failglob shell
option is set, and no matches are found, an error message is printed
and the command is not executed. [...]

Si tu tiens à bash, alors nullglob est sûrement l'option que tu cherches.

Trivial me direz vous. Lorsque la queue est vide, je ne devrais
obtenir aucune réponse. Raté, j'obtiens un superbe :

/home/machin/queue/*.to_be_sent

C'est le comportement par défaut de bash (aucune idée si c'est
standard). Le man de bash dit :

for i in $(ls $QUEUE/*.to_be_sent 2> /dev/null)

Hello,

Tu as eu ta réponse, par contre j'ai une remarque :


Ce cher JKB <jkb@koenigsberg.invalid> a posté :

for i in $(ls $QUEUE/*.to_be_sent 2> /dev/null)

ls sert à *formatter l'affichage*, et dépend énormément de
l'environnement utilisateur (LC_ALL, LC_DATE, etc..). Il ne doit en
aucun cas être utilisé pour du parsing !!

Si vraiment tu veux utiliser un outil de type "ls", utilise plutôt
"find" :

for i in $(find $QUEUE/ -name "*.to_be_sent" 2>/dev/null)


C'est bien plus propre.

On 03/15/2012 10:27 AM, Alain Ketterlin wrote:

Trivial me direz vous. Lorsque la queue est vide, je ne devrais
obtenir aucune réponse. Raté, j'obtiens un superbe :

/home/machin/queue/*.to_be_sent

C'est le comportement par défaut de bash (aucune idée si c'est
standard). Le man de bash dit :

Il me semble que le bug est dans le comportement
différent selon que stderr est redirigé ou pas.

C'est le comportement par défaut de bash (aucune idée si c'est
standard).

>C'est le comportement par défaut de bash (aucune idée si c'est
>standard).

C'est standard au sens Posix en tout cas:

Si vraiment tu veux utiliser un outil de type "ls", utilise plutà ´t
"find" :

for i in $(find $QUEUE/ -name "*.to_be_sent" 2>/dev/null)

C'est bien plus propre.