test -d

bonjour :-)


avant je faisait
test -d sauvegardes/ && cd sauvegardes/
pour aller dans le dossier seulement si il existe,

et comme un *** j'ai transformé ca en
test -d sauvegardes/ && mkdir sauvegardes/
ce qui est faux, ici, c'est que tu cree le repertoire

sauvegardes s'il existe !

les alternatives possibles sont :

test -d sauvegardes || mkdir sauvegardes
test ! -d sauvegardes && mkdir sauvegardes
mkdir -p sauvegarde || exit

personnellement, je préfère la dernière.

à propos des 2 premières solutions, pour être pédantique,
il faudrait faire qqc comme :

test ! -e sauvegardes -a ! -d sauvegardes && mkdir sauvegardes

car si sauvegardes est un fichier, test -d sauvegardes sera
faux et mkdir sauvegardes ne fonctionnera pas. test -e sauvegardes
permet de s'assurer que sauvegardes n'existe pas, qu'il s'agisse
d'un fichier ou d'un répertoire.

plus de précision ici à propos de test :

http://www.opengroup.org/onlinepubs/000095399/utilities/test.html

et la en ce qui concerne mkdir -p :

http://www.opengroup.org/onlinepubs/000095399/utilities/mkdir.html

cd sauvegardes/
pour creer le dossier si il existe pas

quand au cd, il est vrai qu'il est préférable de faire un
cd sauvegardes || exit
comme le précise Stéphane, surtout si tu fais des rm derrière.
imagine que le cd n'a pas fonctionné...
tu fais les rm ou il ne faut pas :(

Regards, Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.

2007-07-19, 02:29(+02), Cyrille Lefevre:
[...]

test ! -e sauvegardes -a ! -d sauvegardes && mkdir sauvegardes

car si sauvegardes est un fichier, test -d sauvegardes sera
faux et mkdir sauvegardes ne fonctionnera pas. test -e sauvegardes
permet de s'assurer que sauvegardes n'existe pas, qu'il s'agisse
d'un fichier ou d'un répertoire.
[...]

Mais pas d'un lien.

test -e sauvegardes

peut renvoyer false si sauvegardes existe mais est un lien
symbolique vers un fichier qui n'existe pas ou qui se trouve
dans un repertoire pour lequel on n'a pas le "search" access.

Donc, pour etre vraiment pedantique, ca serait plutot

[ ! -e sauvegardes ] && [ ! -h sauvegardes ] && mkdir sauvegardes

ou mieux:

ls -d sauvegardes > /dev/null 2>&1 || mkdir sauvegardes

--
Stéphane

In article <469a9af0$0$26382$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

On ne doit presque jamais tester avant de
faire quelque chose : on essaie de faire, et on regarde si ça a marché.

si j'ai bien compris c'est avec " || exit" que ça se fait ?
si il y a le moindre pb, ça arrête le script ?

génial :-)
en fait, il faudrait que j'en étale partout dans mes scripts, pour que
ça s'arrête des qu'il y a un pb ? :-)
est ce que vous me le recommandez ?

L'autre solution ouvre la porte à des race conditions.

c'est quoi cette race là ? :-D

--
j'agis contre l'assistanat, je travaille dans une SCOP !

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:

In article <469a9af0$0$26382$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

On ne doit presque jamais tester avant de
faire quelque chose : on essaie de faire, et on regarde si ça a marché.

si j'ai bien compris c'est avec " || exit" que ça se fait ?
si il y a le moindre pb, ça arrête le script ?

génial :-)
en fait, il faudrait que j'en étale partout dans mes scripts, pour que
ça s'arrête des qu'il y a un pb ? :-)

Il y a aussi "set -e" en début de script, qui dit au script de
s'arrêter à la première commande qui renvoie autre chose que 0. Mais
c'est un coup à avoir le script qui s'arrête à un endroit où on ne
voulait pas si on ne fait pas attention.

est ce que vous me le recommandez ?

Pas forcément partout, mais quand il y a une action importante qui
peut échouer, oui, c'est important.

J'ai un copain qui a exécuté sur son compte un script qui commençait
grosso-modo par

cd ~/un-repertoire/
rm -fr *

(script fait par un autre copain, qui lui avait un répertoire qui
s'appelait ~/un-repertoire).

Je te laisse imaginer ce qui s'est passé ;-).

L'autre solution ouvre la porte à des race conditions.

c'est quoi cette race là ? :-D

« race-condition » (condition de course ?), c'est quand un truc pas
prévu peut se produire si l'environnement du processus fait quelque
chose à un instant précis. Typiquement, du code genre

if (je peux faire un truc) {
faire le truc en question;
}

Il est tout à fait possible que le teste renvoie vrai, et qu'un
instant plus tard, finalement, ça ne soit plus possible.

--
Matthieu

In article <f7mb8i$58q$1@talisker.lacave.net>,
Cyrille Lefevre <cyrille.lefevre-news%nospam@laposte.net.invalid>
wrote:

avant je faisait
test -d sauvegardes/ && cd sauvegardes/
pour aller dans le dossier seulement si il existe,

et comme un *** j'ai transformé ca en
test -d sauvegardes/ && mkdir sauvegardes/
ce qui est faux, ici, c'est que tu cree le repertoire

sauvegardes s'il existe !

mkdir -p sauvegarde || exit

super, cette option -p :-)))
justement, j'avais plusieurs séquences comme la précédente à la suite,
parce que j'avais à faire des dossiers en cascade :-)

merci bcp :-)

cd sauvegardes/

quand au cd, il est vrai qu'il est préférable de faire un
cd sauvegardes || exit
comme le précise Stéphane, surtout si tu fais des rm derrière.
imagine que le cd n'a pas fonctionné...
tu fais les rm ou il ne faut pas :(

:-)

--
j'agis contre l'assistanat, je travaille dans une SCOP !

In article <slrnf9jsl8.58g.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote:

2007-07-15, 11:53(+02), Thomas:
[...]

avant je faisait
test -d sauvegardes/ && cd sauvegardes/
pour aller dans le dossier seulement si il existe,

et comme un *** j'ai transformé ca en
test -d sauvegardes/ && mkdir sauvegardes/
cd sauvegardes/
pour creer le dossier si il existe pas

(avec
#!/bin/sh -
)


pendant que j'essaye de reparer mes ****ries,
est ce que qqn peut m'indiquer comment on inverse le test svp ?

Je te suggere plutot:

mkdir sauvegardes 2> /dev/null
cd sauvegardes || exit

"2>" c'est pour rediriger toutes les sorties, pour qu'on ne voit rien
s'afficher quoi qu'il arrive ? c'est pas "&>" ?

Note que mentionner "/bin/sh" n'est pas assez pour decrire quel
shell tu utilises. Ca peut etre un sh POSIX, mais ca peut aussi
etre un sh Bourne comme dans les tres vieux systemes ou les
systemes qui l'ont laissé la pour backward compatibility (comme
Solaris). Pour avoir un sh POSIX, il est parfois preferable
d'omettre la ligne "#! ..." (qui n'est pas POSIX).

ah bon ??
il y a très longtemps on m'a dit le contraire :
je ne mettais rien du tout, et on m'a dit qu'il fallait mieux mettre
"#!/bin/sh -" au début des scripts (pour être bien sur de .... je ne
sais plus)

et donc si on met *rien du tout*, c'est plus (+) portable ?

Le Bourne shell ne connait pas la syntaxe ! cmd.

?

--
j'agis contre l'assistanat, je travaille dans une SCOP !

2007-09-03, 15:31(+02), Thomas:
[...]

mkdir sauvegardes 2> /dev/null
cd sauvegardes || exit

"2>" c'est pour rediriger toutes les sorties, pour qu'on ne voit rien
s'afficher quoi qu'il arrive ? c'est pas "&>" ?

Pour rediriger les erreurs. Le fd 2 d'un process est sa sortie
d'erreur, le fd 1 sa sortie standard. cmd > file est un
raccourci pour cmd 1> file, cmd &> file est un raccourci
non-standard pour cmd 1> file 2>&1.

Note que mentionner "/bin/sh" n'est pas assez pour decrire quel
shell tu utilises. Ca peut etre un sh POSIX, mais ca peut aussi
etre un sh Bourne comme dans les tres vieux systemes ou les
systemes qui l'ont laissé la pour backward compatibility (comme
Solaris). Pour avoir un sh POSIX, il est parfois preferable
d'omettre la ligne "#! ..." (qui n'est pas POSIX).

ah bon ??
il y a très longtemps on m'a dit le contraire :
je ne mettais rien du tout, et on m'a dit qu'il fallait mieux mettre
"#!/bin/sh -" au début des scripts (pour être bien sur de .... je ne
sais plus)

et donc si on met *rien du tout*, c'est plus (+) portable ?
[...]

En principe oui, a condition d'eviter que le premier caractere
du fichier ne soit pas un "#".

Mais bon, ca ne garantit pas non-plus d'avoir un shell POSIX, ca
garantit d'avoir un shell POSIX que si celui qui execute le
script est "en environnement POSIX" qui n'est pas tres
clairement defini.

Le mieux en pratique, meme si ce n'est pas /standard/ est
peut-etre d'adapter le #! /path/to/sh - pour chaque systeme sur
lequel on veut porter le script (par exemple, #!
/usr/xpg4/bin/sh - sous Solaris, et #! /bin/sh - sur la plupart
des autres). Se posera ensuite le probleme de la definition de
PATH (qui par defaut sur certains systemes ne pointe pas vers
les outils standard (Solaris encore)).

--
Stéphane

comme souvent je continue à poser des questions, celles qui me viennent
en lisant les réponses,
mais c'est pas très important (si t'as mieux à faire ... :-) )


In article <slrnfdomr0.d6k.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote:

2007-09-03, 15:31(+02), Thomas:
[...]

mkdir sauvegardes 2> /dev/null
cd sauvegardes || exit

"2>" c'est pour rediriger toutes les sorties, pour qu'on ne voit rien
s'afficher quoi qu'il arrive ? c'est pas "&>" ?

Pour rediriger les erreurs. Le fd 2 d'un process est sa sortie
d'erreur, le fd 1 sa sortie standard. cmd > file est un
raccourci pour cmd 1> file, cmd &> file est un raccourci
non-standard pour cmd 1> file 2>&1.

merci :-)

et donc "2>&1" veut dire qu'on veut rediriger le fd 2 au même endroit
que le fd 1 ? :-)

Note que mentionner "/bin/sh" n'est pas assez pour decrire quel
shell tu utilises. Ca peut etre un sh POSIX, mais ca peut aussi
etre un sh Bourne comme dans les tres vieux systemes ou les
systemes qui l'ont laissé la pour backward compatibility (comme
Solaris). Pour avoir un sh POSIX, il est parfois preferable
d'omettre la ligne "#! ..." (qui n'est pas POSIX).

ah bon ??
il y a très longtemps on m'a dit le contraire :
je ne mettais rien du tout, et on m'a dit qu'il fallait mieux mettre
"#!/bin/sh -" au début des scripts (pour être bien sur de .... je ne
sais plus)

et donc si on met *rien du tout*, c'est plus (+) portable ?
[...]

En principe oui, a condition d'eviter que le premier caractere
du fichier ne soit pas un "#".

il faut que le 1er caractère soit "#" ?

Mais bon, ca ne garantit pas non-plus d'avoir un shell POSIX, ca
garantit d'avoir un shell POSIX que si celui qui execute le
script est "en environnement POSIX" qui n'est pas tres
clairement defini.

une question que j'ai oublié de poser, c'est :
si on indique rien, comment ça décide avec quel shell ça va exécuter le
script ??

Le mieux en pratique, meme si ce n'est pas /standard/ est
peut-etre d'adapter le #! /path/to/sh - pour chaque systeme sur
lequel on veut porter le script (par exemple, #!
/usr/xpg4/bin/sh - sous Solaris, et #! /bin/sh - sur la plupart
des autres).

ok merci :-)
je vais donc continuer avec "#!/bin/sh -"

de toutes façons, pour l'instant j'exécute mes scripts que sur mac ...

Se posera ensuite le probleme de la definition de
PATH (qui par defaut sur certains systemes ne pointe pas vers
les outils standard (Solaris encore)).

ah oui, ça c'est un autre pb, et en ce qui me concerne qui n'est pas tjr
simple quand on passe d'un mac à l'autre ...

--
j'agis contre l'assistanat, je travaille dans une SCOP !

In article <vpqejhfewgs.fsf@bauges.imag.fr>,
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:

In article <469a9af0$0$26382$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

On ne doit presque jamais tester avant de
faire quelque chose : on essaie de faire, et on regarde si ça a marché.

si j'ai bien compris c'est avec " || exit" que ça se fait ?
si il y a le moindre pb, ça arrête le script ?

génial :-)
en fait, il faudrait que j'en étale partout dans mes scripts, pour que
ça s'arrête des qu'il y a un pb ? :-)

Il y a aussi "set -e" en début de script, qui dit au script de
s'arrêter à la première commande qui renvoie autre chose que 0. Mais
c'est un coup à avoir le script qui s'arrête à un endroit où on ne
voulait pas si on ne fait pas attention.

est ce que vous me le recommandez ?

Pas forcément partout, mais quand il y a une action importante qui
peut échouer, oui, c'est important.

je voulais dire, partout sauf quand on sait que l'action va retourner
une erreur et que c'est normal


j'ai mis ça dans mon ~/.profile :
cd dossier || exit
du coup, quand le dossier n'existe pas, quand j'ouvre le terminal la
fenêtre se referme aussitôt

en fait, là si ça ne marche pas on n'a pas besoin d'action particulière,
donc il suffit de faire
cd dossier 2> /dev/null
?

J'ai un copain qui a exécuté sur son compte un script qui commençait
grosso-modo par

cd ~/un-repertoire/
rm -fr *

(script fait par un autre copain, qui lui avait un répertoire qui
s'appelait ~/un-repertoire).

Je te laisse imaginer ce qui s'est passé ;-).

ah ben si ça supprime que les fichiers marqués comme étant en langue
française, c'est deja ça ;-)
(moi j'ai l'habitude d'écrire "rm -Rf", "république française" ça a plus
de gueule :-D )

L'autre solution ouvre la porte à des race conditions.

c'est quoi cette race là ? :-D

« race-condition » (condition de course ?), c'est quand un truc pas
prévu peut se produire si l'environnement du processus fait quelque
chose à un instant précis. Typiquement, du code genre

if (je peux faire un truc) {
faire le truc en question;
}

Il est tout à fait possible que le teste renvoie vrai, et qu'un
instant plus tard, finalement, ça ne soit plus possible.

merci :-)

--
j'agis contre l'assistanat, je travaille dans une SCOP !

2007-09-05, 02:11(+02), Thomas:
[...]

Pour rediriger les erreurs. Le fd 2 d'un process est sa sortie
d'erreur, le fd 1 sa sortie standard. cmd > file est un
raccourci pour cmd 1> file, cmd &> file est un raccourci
non-standard pour cmd 1> file 2>&1.

merci :-)

et donc "2>&1" veut dire qu'on veut rediriger le fd 2 au même endroit
que le fd 1 ? :-)

Oui. Attention, > file 2>&1 n'est pas la meme chose que > file
2> file. Le premier ouvre un seul /flux/ en ecriture vers le
fichier qui est assigné a la fois au fd 1 et 2, le deuxieme
ouvre 2 flux separes. Dans le deuxieme cas, ce que la commande
ecrirait sur ses file descriptors 1 et 2 se chevaucheraient.

[...]

En principe oui, a condition d'eviter que le premier caractere
du fichier ne soit pas un "#".

il faut que le 1er caractère soit "#" ?

Non, desolé pour le cafouillage des negations. Si le premier
caractère est "#" et que l'on essaie de lancer le script depuis
un shell csh, certaines versions de csh (mais aussi de sh sur
certains vieux systemes) executeront le script avec csh. Raison
historique. Donc eviter le "#".

Mais bon, ca ne garantit pas non-plus d'avoir un shell POSIX, ca
garantit d'avoir un shell POSIX que si celui qui execute le
script est "en environnement POSIX" qui n'est pas tres
clairement defini.

une question que j'ai oublié de poser, c'est :
si on indique rien, comment ça décide avec quel shell ça va exécuter le
script ??

C'est a la discretion de l'outil qui executera le script. En
environnement POSIX, un outil POSIX utilisera un shell POSIX, un
outil Unix utilisera un shell Unix (si disponible, qui sera par
consequent POSIX aussi).

Si le script est executé au moyen des fonctions C execp,
execl... la bibliotheque C fera appel a un shell POSIX.

Certains shells POSIX executeront le script dans un fils sans
meme faire de exec*().

Malheureusement, il y a toujours Solaris pour faire bande a
part. Il y a encore beaucoup d'outils qui sous Solaris
utiliseront "/bin/sh" (qui n'est pas POSIX) pour executer le
script. Le execp() de Solaris utilise aussi /bin/sh par defaut
si on ne passe pas d'obscures options de compilation specifiques
pour qu'il se comporte POSIXement.

Les appels systemes execve() qui sont appele par les execp() et
companies, euh, par contre ne savent pas executer des scripts de
cette facon.


--
Stéphane