Il me semble me souvenir que test ! avait parfois des problemes, mais lesquels? Est-ce que
if [ ! -f "$file" -o -s "$file" ] ; then ... fi
a des problemes? Lesquels, pour quels shells? Je suis sur que "$file" n'a pas une expansion vide si ca joue.
C'est:
if ! [ -f ...
et "-o" qui ont des problemes.
Je ne crois pas qu'il y ait de shell Bourne-like qui prenne ce "!" pour de l'history expansion.
if [ ! -f "$file" ] || [ -s "$file" ]; then
Sinon ca peut foirer si $file vaut = ou ) par exemple.
$ file="=" bash -c '[ ! -f "$file" -o -s "$file" ]' bash: line 0: [: too many arguments
-- Stéphane
Jean-Marc Bourguet
Stephane Chazelas writes:
2005-02-21, 16:41(+01), Jean-Marc Bourguet:
Il me semble me souvenir que test ! avait parfois des problemes, mais lesquels? Est-ce que
if [ ! -f "$file" -o -s "$file" ] ; then ... fi
a des problemes? Lesquels, pour quels shells? Je suis sur que "$file" n'a pas une expansion vide si ca joue.
C'est:
if ! [ -f ...
Ok.
et "-o" qui ont des problemes.
Je ne crois pas qu'il y ait de shell Bourne-like qui prenne ce "!" pour de l'history expansion.
if [ ! -f "$file" ] || [ -s "$file" ]; then
Sinon ca peut foirer si $file vaut = ou ) par exemple.
Ok, c'est donc pas un probleme pour moi ($file est en fait fabrique par un makefile avec de la substitution, il aura toujours un suffixe bien connu). J'essaierai de me souvenir de ca pour les autres contextes.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Il me semble me souvenir que test ! avait parfois des problemes, mais
lesquels? Est-ce que
if [ ! -f "$file" -o -s "$file" ] ; then
...
fi
a des problemes? Lesquels, pour quels shells? Je suis sur que
"$file" n'a pas une expansion vide si ca joue.
C'est:
if ! [ -f ...
Ok.
et "-o" qui ont des problemes.
Je ne crois pas qu'il y ait de shell Bourne-like qui prenne ce
"!" pour de l'history expansion.
if [ ! -f "$file" ] || [ -s "$file" ]; then
Sinon ca peut foirer si $file vaut = ou ) par exemple.
Ok, c'est donc pas un probleme pour moi ($file est en fait fabrique
par un makefile avec de la substitution, il aura toujours un suffixe
bien connu). J'essaierai de me souvenir de ca pour les autres
contextes.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Il me semble me souvenir que test ! avait parfois des problemes, mais lesquels? Est-ce que
if [ ! -f "$file" -o -s "$file" ] ; then ... fi
a des problemes? Lesquels, pour quels shells? Je suis sur que "$file" n'a pas une expansion vide si ca joue.
C'est:
if ! [ -f ...
Ok.
et "-o" qui ont des problemes.
Je ne crois pas qu'il y ait de shell Bourne-like qui prenne ce "!" pour de l'history expansion.
if [ ! -f "$file" ] || [ -s "$file" ]; then
Sinon ca peut foirer si $file vaut = ou ) par exemple.
Ok, c'est donc pas un probleme pour moi ($file est en fait fabrique par un makefile avec de la substitution, il aura toujours un suffixe bien connu). J'essaierai de me souvenir de ca pour les autres contextes.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Stephane Chazelas
2005-02-22, 13:11(+01), Jean-Marc Bourguet: [...]
if [ ! -f "$file" ] || [ -s "$file" ]; then
Sinon ca peut foirer si $file vaut = ou ) par exemple.
Ok, c'est donc pas un probleme pour moi ($file est en fait fabrique par un makefile avec de la substitution, il aura toujours un suffixe bien connu). J'essaierai de me souvenir de ca pour les autres contextes. [...]
Bizarre comme facon de penser. Pourquoi utiliser la forme foireuse ET se poser la question de savoir si elle peut foirer plutot que d'utiliser la forme non foireuse l'esprit tranquille ?
"[" devient fiable si on suit une poignee de regles simples:
- Une seule condition par invocation de "[": [ -n "$a" ] && [ "$a" = "$b" ] au lieu de [ -n "$a" -a "$a" = "$b" ] - Toujours mettre les variables entre quotes. Ca ne s'applique pas qu'a "[" d'ailleurs. Le cas le plus connu est [ -n $var ] qui est vrai meme quand $var est vide (parce que [ -n ] est vrai), mais il y a des problemes quelque soit l'operateur (a cause du "word splitting" et de la "filename generation"). - utiliser les operateurs arithmetiques pour les nombres et literaux pour les chaines: [ "$month" -le 12 ], [ "$LOGNAME" = root ] Meme si [ "$i" = 2 ] et [ "$i" -eq 2 ] ont de grandes chances de fonctionner aussi bien (a part que 02 vaut aussi 2), le deuxieme a l'interet de reporter une erreur si $i ne contient pas un nombre entier. - utiliser [ "x$A" = "x$B" ]. Ce n'est pas necessaire pour les shells POSIX, mais meme des shells censés etre POSIX echouent dans certaines situation. - Les operateurs -e, -nt, -ot, -N, -L, -h, >, <, ne sont pas portables. -e, -h et -L sont POSIX toutefois. -h et -L sont raisonablement portables.
Accessoirement: - se rappeler que [ -f "$file" ] ne fait pas que tester si un fichier existe. Il teste aussi que c'est un fichier regulier (ou un lien symbolique vers un fichier regulier) Il renverra false sur un repertoire. Il renverra aussi false si file est un fichier regulier mais que "[" n'a pas le moyen de le determiner. - [ -e "$file" ], en plus de n'etre pas portable, renverra false si file est un lien symbolique si le fichier qu'il pointe n'est pas accessible (ou inexistant). Lui preferer ls -d -- "$file" ou mieux si on veut creer le fichier par la suite: utiliser set -C - si [ -x "$file" ] renvoie true, ca veut juste dire que l'utilisateur qui excute "[" a les permissions d'execution. Un autre utilisateur ne les aura pas forcement, $file peut etre un repertoire ou un fichier non-executable qui se trouve juste avoir des droits d'executions (comme les fichiers sur un filesystem msdos).
-- Stéphane
2005-02-22, 13:11(+01), Jean-Marc Bourguet:
[...]
if [ ! -f "$file" ] || [ -s "$file" ]; then
Sinon ca peut foirer si $file vaut = ou ) par exemple.
Ok, c'est donc pas un probleme pour moi ($file est en fait fabrique
par un makefile avec de la substitution, il aura toujours un suffixe
bien connu). J'essaierai de me souvenir de ca pour les autres
contextes.
[...]
Bizarre comme facon de penser. Pourquoi utiliser la
forme foireuse ET se poser la question de savoir si elle peut
foirer plutot que d'utiliser la forme non foireuse l'esprit
tranquille ?
"[" devient fiable si on suit une poignee de regles simples:
- Une seule condition par invocation de "[":
[ -n "$a" ] && [ "$a" = "$b" ] au lieu de
[ -n "$a" -a "$a" = "$b" ]
- Toujours mettre les variables entre quotes. Ca ne s'applique
pas qu'a "[" d'ailleurs. Le cas le plus connu est [ -n $var ]
qui est vrai meme quand $var est vide (parce que [ -n ] est
vrai), mais il y a des problemes quelque soit l'operateur (a
cause du "word splitting" et de la "filename generation").
- utiliser les operateurs arithmetiques pour les nombres et
literaux pour les chaines: [ "$month" -le 12 ],
[ "$LOGNAME" = root ]
Meme si [ "$i" = 2 ] et [ "$i" -eq 2 ] ont de grandes chances
de fonctionner aussi bien (a part que 02 vaut aussi 2), le
deuxieme a l'interet de reporter une erreur si $i ne contient
pas un nombre entier.
- utiliser [ "x$A" = "x$B" ]. Ce n'est pas necessaire pour les
shells POSIX, mais meme des shells censés etre POSIX echouent
dans certaines situation.
- Les operateurs -e, -nt, -ot, -N, -L, -h, >, <, ne sont pas
portables. -e, -h et -L sont POSIX toutefois. -h et -L sont
raisonablement portables.
Accessoirement:
- se rappeler que [ -f "$file" ] ne fait pas que tester si un
fichier existe. Il teste aussi que c'est un fichier regulier
(ou un lien symbolique vers un fichier regulier) Il renverra
false sur un repertoire. Il renverra aussi false si file est
un fichier regulier mais que "[" n'a pas le moyen de le
determiner.
- [ -e "$file" ], en plus de n'etre pas portable, renverra false
si file est un lien symbolique si le fichier qu'il pointe
n'est pas accessible (ou inexistant). Lui preferer
ls -d -- "$file" ou mieux si on veut creer le fichier par la
suite: utiliser set -C
- si [ -x "$file" ] renvoie true, ca veut juste dire que
l'utilisateur qui excute "[" a les permissions d'execution. Un
autre utilisateur ne les aura pas forcement, $file peut etre
un repertoire ou un fichier non-executable qui se trouve juste
avoir des droits d'executions (comme les fichiers sur un
filesystem msdos).
Sinon ca peut foirer si $file vaut = ou ) par exemple.
Ok, c'est donc pas un probleme pour moi ($file est en fait fabrique par un makefile avec de la substitution, il aura toujours un suffixe bien connu). J'essaierai de me souvenir de ca pour les autres contextes. [...]
Bizarre comme facon de penser. Pourquoi utiliser la forme foireuse ET se poser la question de savoir si elle peut foirer plutot que d'utiliser la forme non foireuse l'esprit tranquille ?
"[" devient fiable si on suit une poignee de regles simples:
- Une seule condition par invocation de "[": [ -n "$a" ] && [ "$a" = "$b" ] au lieu de [ -n "$a" -a "$a" = "$b" ] - Toujours mettre les variables entre quotes. Ca ne s'applique pas qu'a "[" d'ailleurs. Le cas le plus connu est [ -n $var ] qui est vrai meme quand $var est vide (parce que [ -n ] est vrai), mais il y a des problemes quelque soit l'operateur (a cause du "word splitting" et de la "filename generation"). - utiliser les operateurs arithmetiques pour les nombres et literaux pour les chaines: [ "$month" -le 12 ], [ "$LOGNAME" = root ] Meme si [ "$i" = 2 ] et [ "$i" -eq 2 ] ont de grandes chances de fonctionner aussi bien (a part que 02 vaut aussi 2), le deuxieme a l'interet de reporter une erreur si $i ne contient pas un nombre entier. - utiliser [ "x$A" = "x$B" ]. Ce n'est pas necessaire pour les shells POSIX, mais meme des shells censés etre POSIX echouent dans certaines situation. - Les operateurs -e, -nt, -ot, -N, -L, -h, >, <, ne sont pas portables. -e, -h et -L sont POSIX toutefois. -h et -L sont raisonablement portables.
Accessoirement: - se rappeler que [ -f "$file" ] ne fait pas que tester si un fichier existe. Il teste aussi que c'est un fichier regulier (ou un lien symbolique vers un fichier regulier) Il renverra false sur un repertoire. Il renverra aussi false si file est un fichier regulier mais que "[" n'a pas le moyen de le determiner. - [ -e "$file" ], en plus de n'etre pas portable, renverra false si file est un lien symbolique si le fichier qu'il pointe n'est pas accessible (ou inexistant). Lui preferer ls -d -- "$file" ou mieux si on veut creer le fichier par la suite: utiliser set -C - si [ -x "$file" ] renvoie true, ca veut juste dire que l'utilisateur qui excute "[" a les permissions d'execution. Un autre utilisateur ne les aura pas forcement, $file peut etre un repertoire ou un fichier non-executable qui se trouve juste avoir des droits d'executions (comme les fichiers sur un filesystem msdos).
