(sans les guillemets ca ne fait pas pareil ? sleep 86400 || exit $? ) [...]
Non, ommettre les quotes autour d'une variable est l'operateur split+glob en shell.
Ceci dit, dans ce cas précis, $? est un nombre, donc split+glob ne changeront rien dessus. Mais on est d'accord qu'il faut prendre et garder les bonnes habitudes !
Ca depend de la valeur courante de $IFS.
Meme si IFS est vide et que le globbing est desactivé (par set -f), il faut en general quoter les variables pour le cas ou la variable est vide.
Exemple typique:
[ -z $var ]
Renvoie toujours "vrai". Parce que quand $var est vide, ca devient
'[' '-z' ']' (true) au lieu de '[' '-z' '' ']' (false)
(sans les guillemets ca ne fait pas pareil ? sleep 86400 || exit $? )
[...]
Non, ommettre les quotes autour d'une variable est l'operateur
split+glob en shell.
Ceci dit, dans ce cas précis, $? est un nombre, donc split+glob ne
changeront rien dessus. Mais on est d'accord qu'il faut prendre et
garder les bonnes habitudes !
Ca depend de la valeur courante de $IFS.
Meme si IFS est vide et que le globbing est desactivé (par set
-f), il faut en general quoter les variables pour le cas ou la
variable est vide.
Exemple typique:
[ -z $var ]
Renvoie toujours "vrai". Parce que quand $var est vide, ca
devient
'[' '-z' ']' (true)
au lieu de
'[' '-z' '' ']' (false)
(sans les guillemets ca ne fait pas pareil ? sleep 86400 || exit $? ) [...]
Non, ommettre les quotes autour d'une variable est l'operateur split+glob en shell.
Ceci dit, dans ce cas précis, $? est un nombre, donc split+glob ne changeront rien dessus. Mais on est d'accord qu'il faut prendre et garder les bonnes habitudes !
Ca depend de la valeur courante de $IFS.
Meme si IFS est vide et que le globbing est desactivé (par set -f), il faut en general quoter les variables pour le cas ou la variable est vide.
Exemple typique:
[ -z $var ]
Renvoie toujours "vrai". Parce que quand $var est vide, ca devient
'[' '-z' ']' (true) au lieu de '[' '-z' '' ']' (false)
Donc: [ -z "$var" ]
-- Stéphane
Thomas
In article , Stephane CHAZELAS wrote:
2008-06-10, 16:58(+02), Thomas: [...]
sleep 86400 || exit "$?"
(sans les guillemets ca ne fait pas pareil ? sleep 86400 || exit $? ) [...]
Non, ommettre les quotes autour d'une variable est l'operateur split+glob en shell.
printf '%s' $var C'est comme si par exemple en perl tu ecrivais:
$_ = $var; print for map {glob} split;
je connais pas perl
mais tu veux dire que si $? contenait des espaces, exit se retrouverais avec plusieurs arguments qu'il ne saurait pas traiter ? :-)
effectivement, dans ce contexte, il y a peu de chances que ça arrive, mais je suis d'accord avec Matthieu ;-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <slrng4t7eb.lp4.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> wrote:
2008-06-10, 16:58(+02), Thomas:
[...]
sleep 86400 || exit "$?"
(sans les guillemets ca ne fait pas pareil ? sleep 86400 || exit $? )
[...]
Non, ommettre les quotes autour d'une variable est l'operateur
split+glob en shell.
printf '%s' $var
C'est comme si par exemple en perl tu ecrivais:
$_ = $var;
print for map {glob} split;
je connais pas perl
mais tu veux dire que si $? contenait des espaces, exit se retrouverais
avec plusieurs arguments qu'il ne saurait pas traiter ? :-)
effectivement, dans ce contexte, il y a peu de chances que ça arrive,
mais je suis d'accord avec Matthieu ;-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
(sans les guillemets ca ne fait pas pareil ? sleep 86400 || exit $? ) [...]
Non, ommettre les quotes autour d'une variable est l'operateur split+glob en shell.
printf '%s' $var C'est comme si par exemple en perl tu ecrivais:
$_ = $var; print for map {glob} split;
je connais pas perl
mais tu veux dire que si $? contenait des espaces, exit se retrouverais avec plusieurs arguments qu'il ne saurait pas traiter ? :-)
effectivement, dans ce contexte, il y a peu de chances que ça arrive, mais je suis d'accord avec Matthieu ;-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Stephane CHAZELAS
2008-06-10, 18:14(+02), Thomas: [...]
printf '%s' $var C'est comme si par exemple en perl tu ecrivais:
$_ = $var; print for map {glob} split;
je connais pas perl
L'idee est que le contenu de $var est d'abord decoupé suivant les characteres contenus dans $IFS. Et ensuite, pour chaque mot resultant, le "globbing" est operé. C'est a dire qu'un mot qui serait *x* serait transformé en la liste des fichiers du repertoire courant dont le nom contient x.
mais tu veux dire que si $? contenait des espaces, exit se retrouverais avec plusieurs arguments qu'il ne saurait pas traiter ? :-)
effectivement, dans ce contexte, il y a peu de chances que ça arrive, mais je suis d'accord avec Matthieu ;-)
espaces, tabulation et newline (et NUL pour zsh) avec la valeur par default de $IFS, mais si $IFS a ete modifié auparavent dans ton script ca peut etre n'importe quoi. Si tu ecris "exit $?", ca veut dire que ton bout de code ne peut pas etre transporté dans un autre contexte ou $IFS pourrait contenir des chiffres.
Et si, dans un mois ou un an, tu modifies ton script et rajoutes IFS=0, ca va indirectement casser ton script.
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
C'est mon avis, et tu peux constater que beaucoup ne pretent pas trop d'attention a ces considerations.
-- Stéphane
2008-06-10, 18:14(+02), Thomas:
[...]
printf '%s' $var
C'est comme si par exemple en perl tu ecrivais:
$_ = $var;
print for map {glob} split;
je connais pas perl
L'idee est que le contenu de $var est d'abord decoupé suivant
les characteres contenus dans $IFS. Et ensuite, pour chaque mot
resultant, le "globbing" est operé. C'est a dire qu'un mot qui
serait *x* serait transformé en la liste des fichiers du
repertoire courant dont le nom contient x.
mais tu veux dire que si $? contenait des espaces, exit se retrouverais
avec plusieurs arguments qu'il ne saurait pas traiter ? :-)
effectivement, dans ce contexte, il y a peu de chances que ça arrive,
mais je suis d'accord avec Matthieu ;-)
espaces, tabulation et newline (et NUL pour zsh) avec la valeur
par default de $IFS, mais si $IFS a ete modifié auparavent dans
ton script ca peut etre n'importe quoi. Si tu ecris "exit $?",
ca veut dire que ton bout de code ne peut pas etre transporté
dans un autre contexte ou $IFS pourrait contenir des chiffres.
Et si, dans un mois ou un an, tu modifies ton script et rajoutes
IFS=0, ca va indirectement casser ton script.
Mais, au dela des considerations pratiques, ecrire exit $? est
incorrect, car ca ne fait pas de sens de demander au shell de
splitter $? (et faire du globbing dessus).
C'est mon avis, et tu peux constater que beaucoup ne pretent pas
trop d'attention a ces considerations.
printf '%s' $var C'est comme si par exemple en perl tu ecrivais:
$_ = $var; print for map {glob} split;
je connais pas perl
L'idee est que le contenu de $var est d'abord decoupé suivant les characteres contenus dans $IFS. Et ensuite, pour chaque mot resultant, le "globbing" est operé. C'est a dire qu'un mot qui serait *x* serait transformé en la liste des fichiers du repertoire courant dont le nom contient x.
mais tu veux dire que si $? contenait des espaces, exit se retrouverais avec plusieurs arguments qu'il ne saurait pas traiter ? :-)
effectivement, dans ce contexte, il y a peu de chances que ça arrive, mais je suis d'accord avec Matthieu ;-)
espaces, tabulation et newline (et NUL pour zsh) avec la valeur par default de $IFS, mais si $IFS a ete modifié auparavent dans ton script ca peut etre n'importe quoi. Si tu ecris "exit $?", ca veut dire que ton bout de code ne peut pas etre transporté dans un autre contexte ou $IFS pourrait contenir des chiffres.
Et si, dans un mois ou un an, tu modifies ton script et rajoutes IFS=0, ca va indirectement casser ton script.
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
C'est mon avis, et tu peux constater que beaucoup ne pretent pas trop d'attention a ces considerations.
-- Stéphane
Cyrille Lefevre
Salut,
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit tout court sachant que la valeur par défaut est $? :)
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Salut,
Mais, au dela des considerations pratiques, ecrire exit $? est
incorrect, car ca ne fait pas de sens de demander au shell de
splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit
tout court sachant que la valeur par défaut est $? :)
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit tout court sachant que la valeur par défaut est $? :)
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Alain Montfranc
Cyrille Lefevre a écrit
Salut,
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit tout court sachant que la valeur par défaut est $? :)
Cordialement,
Cyrille Lefevre.
A priori pour sleep(3)
RETURN VALUE Zero if the requested time has elapsed, or the number of seconds left to sleep.
Cyrille Lefevre a écrit
Salut,
Mais, au dela des considerations pratiques, ecrire exit $? est
incorrect, car ca ne fait pas de sens de demander au shell de
splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit
tout court sachant que la valeur par défaut est $? :)
Cordialement,
Cyrille Lefevre.
A priori pour sleep(3)
RETURN VALUE
Zero if the requested time has elapsed, or the number of
seconds left to sleep.
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit tout court sachant que la valeur par défaut est $? :)
Cordialement,
Cyrille Lefevre.
A priori pour sleep(3)
RETURN VALUE Zero if the requested time has elapsed, or the number of seconds left to sleep.
Stephane CHAZELAS
2008-06-11, 02:42(+02), Cyrille Lefevre:
Salut,
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit tout court sachant que la valeur par défaut est $? :) [...]
Oui, mais l'idee est d'avoir l'information du code retour dans l'output de set -x. C'est ce que l'OP avait avant ("+ exit"), ce qui ne lui a pas permis de savoir quel etait le code retour.
Avec exit "$?", il aura "+exit 139" par example.
-- Stéphane
2008-06-11, 02:42(+02), Cyrille Lefevre:
Salut,
Mais, au dela des considerations pratiques, ecrire exit $? est
incorrect, car ca ne fait pas de sens de demander au shell de
splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit
tout court sachant que la valeur par défaut est $? :)
[...]
Oui, mais l'idee est d'avoir l'information du code retour dans
l'output de set -x. C'est ce que l'OP avait avant ("+ exit"), ce
qui ne lui a pas permis de savoir quel etait le code retour.
Mais, au dela des considerations pratiques, ecrire exit $? est incorrect, car ca ne fait pas de sens de demander au shell de splitter $? (et faire du globbing dessus).
il y a beaucoup plus simple dans le cas présent : exit tout court sachant que la valeur par défaut est $? :) [...]
Oui, mais l'idee est d'avoir l'information du code retour dans l'output de set -x. C'est ce que l'OP avait avant ("+ exit"), ce qui ne lui a pas permis de savoir quel etait le code retour.
Avec exit "$?", il aura "+exit 139" par example.
-- Stéphane
Thierry B.
--{ Alain Montfranc a plopé ceci: }--
A priori pour sleep(3)
RETURN VALUE Zero if the requested time has elapsed, or the number of seconds left to sleep.
Ah non, pas du tout, efface: ça c'est la fonction de la libc, et pas la commande sleep(1) utilisable depuis le shell.
DIAGNOSTICS The sleep utility exits with one of the following values: 0 On successful completion, or if the signal SIGALRM was received.
0 An error occurred.
-- "Les mégahertz, c'est comme la cylindrée : c'est pas parce que t'as la Renault Fuego que tu peux rouler plus vite qu'avec la Méhari sur la route des monts plots."
--{ Alain Montfranc a plopé ceci: }--
A priori pour sleep(3)
RETURN VALUE
Zero if the requested time has elapsed, or the number of
seconds left to sleep.
Ah non, pas du tout, efface: ça c'est la fonction de la libc,
et pas la commande sleep(1) utilisable depuis le shell.
DIAGNOSTICS
The sleep utility exits with one of the following values:
0 On successful completion, or if the signal SIGALRM was received.
0 An error occurred.
--
"Les mégahertz, c'est comme la cylindrée : c'est pas parce que t'as la
Renault Fuego que tu peux rouler plus vite qu'avec la Méhari sur la
route des monts plots."
RETURN VALUE Zero if the requested time has elapsed, or the number of seconds left to sleep.
Ah non, pas du tout, efface: ça c'est la fonction de la libc, et pas la commande sleep(1) utilisable depuis le shell.
DIAGNOSTICS The sleep utility exits with one of the following values: 0 On successful completion, or if the signal SIGALRM was received.
0 An error occurred.
-- "Les mégahertz, c'est comme la cylindrée : c'est pas parce que t'as la Renault Fuego que tu peux rouler plus vite qu'avec la Méhari sur la route des monts plots."
Alain Montfranc
Thierry B. a écrit
--{ Alain Montfranc a plopé ceci: }--
A priori pour sleep(3)
RETURN VALUE Zero if the requested time has elapsed, or the number of seconds left to sleep.
Ah non, pas du tout, efface: ça c'est la fonction de la libc,
Oui c'est exactement ce que je disais avec mon (3)
et pas la commande sleep(1) utilisable depuis le shell.
Ben oui, 3 est différent de 1
DIAGNOSTICS The sleep utility exits with one of the following values: 0 On successful completion, or if the signal SIGALRM was received.
0 An error occurred.
Il y a toutes les chances que le >0 soit derivé du retour de sleep(), donc que la valeur en elle meme n'ait aucune signification
Thierry B. a écrit
--{ Alain Montfranc a plopé ceci: }--
A priori pour sleep(3)
RETURN VALUE
Zero if the requested time has elapsed, or the number of
seconds left to sleep.
Ah non, pas du tout, efface: ça c'est la fonction de la libc,
Oui c'est exactement ce que je disais avec mon (3)
et pas la commande sleep(1) utilisable depuis le shell.
Ben oui, 3 est différent de 1
DIAGNOSTICS
The sleep utility exits with one of the following values:
0 On successful completion, or if the signal SIGALRM was received.
0 An error occurred.
Il y a toutes les chances que le >0 soit derivé du retour de sleep(),
donc que la valeur en elle meme n'ait aucune signification
Il y a toutes les chances que le >0 soit derivé du retour de sleep(), donc que la valeur en elle meme n'ait aucune signification [...]
En tout cas, le GNU sleep(1) ne fait pas appel a sleep(3) mais a nanosleep(2).
Le sleep(1) de Solaris 8 fait appel a sleep(3) qui fait appel a alarm(2). Et il retourne 0 si SIGALRM est recu avant la duree demandee.
-- Stéphane
Thomas
In article , Stephane CHAZELAS wrote:
2008-06-10, 16:36(+02), fx [François-Xavier Peretmere]: [...] >> sleep 86400 || exit >> >> et dans le log j'ai : >> >> + sleep 86400 >> + exit >> >> les erreurs sont loggées aussi (avec "&>") >> et apparemment il n'y en a pas
sleep 86400 || exit "$?"
devrait aussi montrer l'exit code par l'output de "set -x"
j'avais fait des fonctions du genre
se() { ssh -AC }
que j'ai mises dans mon .profile , pour pas avoir 50 minuscules scripts chacun dans un fichier
(j'aime pas trop utiliser "set -x" parce qu'apparemment on peut le mettre n'importe où et il est effectif seulement à partir de l'endroit où il est, et il me semble que c'est mieux que ce genre d'option soit globale à un script (non ?) c'est pour ça que j'aime bien mettre ça dans la 1ere ligne
mais pour ce genre de fonctions, on n'a pas le choix, c'est ça que je dois utiliser ?)
du coup, je me suis retrouvé avec le terminal qui se fermait inopinément, et pendant un moment je ne comprenais pas pourquoi :-/
mais finalement, j'aimerais le garder, parce que (en plus de l'information que ça donne) certaines fonctions ont plusieurs lignes
j'ai eu l'idée de rajouter () pour que le exit ne ferme que la parenthèse, est ce que c'est ce qu'il faut faire ? (ou est ce que c'est faire "mal" et il faut faire autrement ?)
In article <slrng4t4kf.ln1.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> wrote:
2008-06-10, 16:36(+02), fx [François-Xavier Peretmere]:
[...]
>> sleep 86400 || exit
>>
>> et dans le log j'ai :
>>
>> + sleep 86400
>> + exit
>>
>> les erreurs sont loggées aussi (avec "&>")
>> et apparemment il n'y en a pas
sleep 86400 || exit "$?"
devrait aussi montrer l'exit code par l'output de "set -x"
j'avais fait des fonctions du genre
se() {
ssh -AC amelie@192.168.1.2
}
que j'ai mises dans mon .profile , pour pas avoir 50 minuscules scripts
chacun dans un fichier
(j'aime pas trop utiliser "set -x" parce qu'apparemment on peut le
mettre n'importe où et il est effectif seulement à partir de l'endroit
où il est,
et il me semble que c'est mieux que ce genre d'option soit globale à un
script (non ?)
c'est pour ça que j'aime bien mettre ça dans la 1ere ligne
mais pour ce genre de fonctions, on n'a pas le choix, c'est ça que je
dois utiliser ?)
du coup, je me suis retrouvé avec le terminal qui se fermait
inopinément, et pendant un moment je ne comprenais pas pourquoi :-/
mais finalement, j'aimerais le garder, parce que (en plus de
l'information que ça donne) certaines fonctions ont plusieurs lignes
j'ai eu l'idée de rajouter () pour que le exit ne ferme que la
parenthèse, est ce que c'est ce qu'il faut faire ?
(ou est ce que c'est faire "mal" et il faut faire autrement ?)
2008-06-10, 16:36(+02), fx [François-Xavier Peretmere]: [...] >> sleep 86400 || exit >> >> et dans le log j'ai : >> >> + sleep 86400 >> + exit >> >> les erreurs sont loggées aussi (avec "&>") >> et apparemment il n'y en a pas
sleep 86400 || exit "$?"
devrait aussi montrer l'exit code par l'output de "set -x"
j'avais fait des fonctions du genre
se() { ssh -AC }
que j'ai mises dans mon .profile , pour pas avoir 50 minuscules scripts chacun dans un fichier
(j'aime pas trop utiliser "set -x" parce qu'apparemment on peut le mettre n'importe où et il est effectif seulement à partir de l'endroit où il est, et il me semble que c'est mieux que ce genre d'option soit globale à un script (non ?) c'est pour ça que j'aime bien mettre ça dans la 1ere ligne
mais pour ce genre de fonctions, on n'a pas le choix, c'est ça que je dois utiliser ?)
du coup, je me suis retrouvé avec le terminal qui se fermait inopinément, et pendant un moment je ne comprenais pas pourquoi :-/
mais finalement, j'aimerais le garder, parce que (en plus de l'information que ça donne) certaines fonctions ont plusieurs lignes
j'ai eu l'idée de rajouter () pour que le exit ne ferme que la parenthèse, est ce que c'est ce qu'il faut faire ? (ou est ce que c'est faire "mal" et il faut faire autrement ?)
