logger le stderr et stdout un script dans le syslog
18 réponses
Francois Lafont
Bonsoir à tous,
Avec la commande shell « echo message | logger -t tag », je peux mettre
dans un script un message dans le syslog de ma Debian. Mais est-il possible
de faire en sorte de mettre dans le syslog _tout_ ce que pourra afficher mon
script via stderr et stdout plutôt que d'utiliser la commande logger au coup
par coup ?
Par ailleurs, mon script utilise /bin/sh et donc j'aimerais éviter les basheries
si possible. Est-ce possible de faire ça ?
J'ignore comment (d'où ma question ici) mais ne puis-je pas lancer en arrière
plan la commande logger au tout début de mon script puis ensuite faire en sorte
que le script balance stdout et stderr dans le flux d'entrée du process logger ?
Bonjour, Le 28/07/2016 à 18:23, Nicolas George a écrit dans le message <579a318e$0$19760$ :
Je n'ai pas ce comportement.
Étrange. Quel protocole as-tu utilisé exactement pour tester ?
% cat t.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' % sh t.sh; echo $? A 1 tr est bien exécuté mais la dernière commande ici est « false » qui provoque l'interruption immédiate du script. C'est conforme à la description du set -e dans SUSv4 : -e When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit. -- Benoit Izac
Bonjour,
Le 28/07/2016 à 18:23, Nicolas George a écrit dans le message
<579a318e$0$19760$426a74cc@news.free.fr> :
Je n'ai pas ce comportement.
Étrange. Quel protocole as-tu utilisé exactement pour tester ?
% cat t.sh
#!/bin/sh
set -e
{
echo 'a'
false
echo 'b'
} | tr '[a-z]' '[A-Z]'
% sh t.sh; echo $?
A
1
tr est bien exécuté mais la dernière commande ici est « false » qui
provoque l'interruption immédiate du script. C'est conforme à la
description du set -e dans SUSv4 :
-e
When this option is on, if a simple command fails for any of the
reasons listed in Consequences of Shell Errors or returns an exit
status value >0, and is not part of the compound list following
a while, until, or if keyword, and is not a part of an AND or OR
list, and is not a pipeline preceded by the ! reserved word, then
the shell shall immediately exit.
Bonjour, Le 28/07/2016 à 18:23, Nicolas George a écrit dans le message <579a318e$0$19760$ :
Je n'ai pas ce comportement.
Étrange. Quel protocole as-tu utilisé exactement pour tester ?
% cat t.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' % sh t.sh; echo $? A 1 tr est bien exécuté mais la dernière commande ici est « false » qui provoque l'interruption immédiate du script. C'est conforme à la description du set -e dans SUSv4 : -e When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit. -- Benoit Izac
Nicolas George
Benoit Izac , dans le message , a écrit :
tr est bien exécuté mais la dernière commande ici est « false » qui provoque l'interruption immédiate du script.
Et le code de retour est bien 1. Ton message confirme mes explications. Pourquoi disais-tu le contraire ?
Benoit Izac , dans le message <87bn1hk9c5.fsf@izac.org>, a écrit :
tr est bien exécuté mais la dernière commande ici est « false » qui
provoque l'interruption immédiate du script.
Et le code de retour est bien 1. Ton message confirme mes explications.
Pourquoi disais-tu le contraire ?
tr est bien exécuté mais la dernière commande ici est « false » qui provoque l'interruption immédiate du script.
Et le code de retour est bien 1. Ton message confirme mes explications. Pourquoi disais-tu le contraire ?
Francois Lafont
Bonsoir, On 28/07/2016 18:41, Nicolas George wrote:
Et le code de retour est bien 1. Ton message confirme mes explications. Pourquoi disais-tu le contraire ?
Et bien là je ne comprends pas ta remarque Nicolas et j'ajoute que je ne pige pas non plus l'exemple de Benoît car je n'ai pas la même chose que lui (voir ci-dessous). Concernant ta remarque ci-dessus, tu disais que « le code de retour d'un pipeline est le code de retour de sa dernière commande » ce qui me semble exact. Mais Benoît, lui, il obtient 1 comme valeur de retour dans son exemple ce qui voudrait donc dire que sa commande "tr" retourne 1. Ce serait curieux, non ? C'est d'autant plus curieux que, si je reprends l'exemple de Benoît, perso je n'ai pas la même chose que lui : ~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' ~$ /tmp/test.sh ; echo $? A 0 Moi j'ai 0 comme valeur de retour ce qui me semble plus en cohérence avec l'idée que « le code de retour d'un pipeline est le code de retour de sa dernière commande ». Bref, je ne comprends pas : 1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe, 2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur ma Wheezy va dans ton sens). Bref, je suis perdu là. ;) NB: Je suis sous Debian Wheezy et /bin/sh correspond chez moi à /bin/dash version 0.5.7-3. -- François Lafont
Bonsoir,
On 28/07/2016 18:41, Nicolas George wrote:
Et le code de retour est bien 1. Ton message confirme mes explications.
Pourquoi disais-tu le contraire ?
Et bien là je ne comprends pas ta remarque Nicolas et j'ajoute que je ne pige
pas non plus l'exemple de Benoît car je n'ai pas la même chose que lui (voir
ci-dessous).
Concernant ta remarque ci-dessus, tu disais que « le code de retour
d'un pipeline est le code de retour de sa dernière commande » ce qui me
semble exact. Mais Benoît, lui, il obtient 1 comme valeur de retour dans
son exemple ce qui voudrait donc dire que sa commande "tr" retourne 1.
Ce serait curieux, non ?
C'est d'autant plus curieux que, si je reprends l'exemple de Benoît, perso je
n'ai pas la même chose que lui :
~$ cat /tmp/test.sh
#!/bin/sh
set -e
{
echo 'a'
false
echo 'b'
} | tr '[a-z]' '[A-Z]'
~$ /tmp/test.sh ; echo $?
A
0
Moi j'ai 0 comme valeur de retour ce qui me semble plus en cohérence avec
l'idée que « le code de retour d'un pipeline est le code de retour de sa
dernière commande ».
Bref, je ne comprends pas :
1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors
que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur
ma Wheezy va dans ton sens).
Bref, je suis perdu là. ;)
NB: Je suis sous Debian Wheezy et /bin/sh correspond chez moi à /bin/dash
version 0.5.7-3.
Bonsoir, On 28/07/2016 18:41, Nicolas George wrote:
Et le code de retour est bien 1. Ton message confirme mes explications. Pourquoi disais-tu le contraire ?
Et bien là je ne comprends pas ta remarque Nicolas et j'ajoute que je ne pige pas non plus l'exemple de Benoît car je n'ai pas la même chose que lui (voir ci-dessous). Concernant ta remarque ci-dessus, tu disais que « le code de retour d'un pipeline est le code de retour de sa dernière commande » ce qui me semble exact. Mais Benoît, lui, il obtient 1 comme valeur de retour dans son exemple ce qui voudrait donc dire que sa commande "tr" retourne 1. Ce serait curieux, non ? C'est d'autant plus curieux que, si je reprends l'exemple de Benoît, perso je n'ai pas la même chose que lui : ~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' ~$ /tmp/test.sh ; echo $? A 0 Moi j'ai 0 comme valeur de retour ce qui me semble plus en cohérence avec l'idée que « le code de retour d'un pipeline est le code de retour de sa dernière commande ». Bref, je ne comprends pas : 1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe, 2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur ma Wheezy va dans ton sens). Bref, je suis perdu là. ;) NB: Je suis sous Debian Wheezy et /bin/sh correspond chez moi à /bin/dash version 0.5.7-3. -- François Lafont
Benoit Izac
Bonjour, Le 28/07/2016 à 19:48, Francois Lafont a écrit dans le message <579a455f$0$26260$ :
Bref, je ne comprends pas : 1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
Parce qu'il n'a pas exécuté exactement qu'il a donné en exemple...
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur ma Wheezy va dans ton sens).
Oui, c'est confus, reprenons. Comme l'indiquait Nicolas, le code de retour est bien 0 lorsque l'on pipe dans cat (c'est ce que tu constates). Dans mon test, j'avais ajouté quelques trucs après le « {...} | cat » pour voir si ça continuais mais en fait ça tombait sur un « false » derrière d'où le retour 1. Donc effectivement, lorsque l'on pipe, le code de retour est celui de la dernière commande. Bref, faire un test vite fait à cinq heures du mat avant de partir au boulot est une mauvaise idée. Refaire le même test après un journée de boulot où tu es parti tôt est tout autant inutile. Désolé pour le bruit, je vais me reposer. -- Benoit Izac
Bonjour,
Le 28/07/2016 à 19:48, Francois Lafont a écrit dans le message
<579a455f$0$26260$426a74cc@news.free.fr> :
Bref, je ne comprends pas :
1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
Parce qu'il n'a pas exécuté exactement qu'il a donné en exemple...
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors
que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur
ma Wheezy va dans ton sens).
Oui, c'est confus, reprenons. Comme l'indiquait Nicolas, le code de
retour est bien 0 lorsque l'on pipe dans cat (c'est ce que tu
constates). Dans mon test, j'avais ajouté quelques trucs après le
« {...} | cat » pour voir si ça continuais mais en fait ça tombait sur
un « false » derrière d'où le retour 1.
Donc effectivement, lorsque l'on pipe, le code de retour est celui de la
dernière commande.
Bref, faire un test vite fait à cinq heures du mat avant de partir au
boulot est une mauvaise idée. Refaire le même test après un journée de
boulot où tu es parti tôt est tout autant inutile. Désolé pour le bruit,
je vais me reposer.
Bonjour, Le 28/07/2016 à 19:48, Francois Lafont a écrit dans le message <579a455f$0$26260$ :
Bref, je ne comprends pas : 1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
Parce qu'il n'a pas exécuté exactement qu'il a donné en exemple...
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur ma Wheezy va dans ton sens).
Oui, c'est confus, reprenons. Comme l'indiquait Nicolas, le code de retour est bien 0 lorsque l'on pipe dans cat (c'est ce que tu constates). Dans mon test, j'avais ajouté quelques trucs après le « {...} | cat » pour voir si ça continuais mais en fait ça tombait sur un « false » derrière d'où le retour 1. Donc effectivement, lorsque l'on pipe, le code de retour est celui de la dernière commande. Bref, faire un test vite fait à cinq heures du mat avant de partir au boulot est une mauvaise idée. Refaire le même test après un journée de boulot où tu es parti tôt est tout autant inutile. Désolé pour le bruit, je vais me reposer. -- Benoit Izac
Francois Lafont
Bonsoir, On 28/07/2016 21:20, Benoit Izac wrote:
1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
Parce qu'il n'a pas exécuté exactement qu'il a donné en exemple...
Ah ok.
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur ma Wheezy va dans ton sens).
Oui, c'est confus, reprenons. Comme l'indiquait Nicolas, le code de retour est bien 0 lorsque l'on pipe dans cat (c'est ce que tu constates). Dans mon test, j'avais ajouté quelques trucs après le « {...} | cat » pour voir si ça continuais mais en fait ça tombait sur un « false » derrière d'où le retour 1.
Ok.
Donc effectivement, lorsque l'on pipe, le code de retour est celui de la dernière commande. Bref, faire un test vite fait à cinq heures du mat avant de partir au boulot est une mauvaise idée. Refaire le même test après un journée de boulot où tu es parti tôt est tout autant inutile. Désolé pour le bruit, je vais me reposer.
Pas de souci, ça arrive et ça n'enlève rien à la qualité globale de tes interventions sur ce forum de news. Maintenant tout est clair... ou presque. ;) Je constate un truc un peu curieux du coup : ~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' echo fin ~$ /tmp/test.sh; echo $? A fin Perso, je trouve ça curieux car : - d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0, on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté. - mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté (du fait que la commande pipe « { ... } | tr ... » possède comme valeur de retour celle de tr. Du coup, c'est bizarre dans cette exemple on a un « set -e » qui fait qu'une partie du job, non ? Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant pas le cas sauf erreur. -- François Lafont
Bonsoir,
On 28/07/2016 21:20, Benoit Izac wrote:
1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
Parce qu'il n'a pas exécuté exactement qu'il a donné en exemple...
Ah ok.
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors
que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur
ma Wheezy va dans ton sens).
Oui, c'est confus, reprenons. Comme l'indiquait Nicolas, le code de
retour est bien 0 lorsque l'on pipe dans cat (c'est ce que tu
constates). Dans mon test, j'avais ajouté quelques trucs après le
« {...} | cat » pour voir si ça continuais mais en fait ça tombait sur
un « false » derrière d'où le retour 1.
Ok.
Donc effectivement, lorsque l'on pipe, le code de retour est celui de la
dernière commande.
Bref, faire un test vite fait à cinq heures du mat avant de partir au
boulot est une mauvaise idée. Refaire le même test après un journée de
boulot où tu es parti tôt est tout autant inutile. Désolé pour le bruit,
je vais me reposer.
Pas de souci, ça arrive et ça n'enlève rien à la qualité globale de tes
interventions sur ce forum de news.
Maintenant tout est clair... ou presque. ;)
Je constate un truc un peu curieux du coup :
~$ cat /tmp/test.sh
#!/bin/sh
set -e
{
echo 'a'
false
echo 'b'
} | tr '[a-z]' '[A-Z]'
echo fin
~$ /tmp/test.sh; echo $?
A
fin
Perso, je trouve ça curieux car :
- d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0,
on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit
avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté.
- mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car
le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté
(du fait que la commande pipe « { ... } | tr ... » possède comme valeur de
retour celle de tr.
Du coup, c'est bizarre dans cette exemple on a un « set -e » qui fait qu'une
partie du job, non ?
Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant
pas le cas sauf erreur.
1. comment Benoît peut avoir 1 comme valeur de retour avec son pipe,
Parce qu'il n'a pas exécuté exactement qu'il a donné en exemple...
Ah ok.
2. ni ta remarque disant que l'exemple de Benoît va dans ton sens alors que pour moi ce n'est pas le cas (en revanche ce que je constate moi sur ma Wheezy va dans ton sens).
Oui, c'est confus, reprenons. Comme l'indiquait Nicolas, le code de retour est bien 0 lorsque l'on pipe dans cat (c'est ce que tu constates). Dans mon test, j'avais ajouté quelques trucs après le « {...} | cat » pour voir si ça continuais mais en fait ça tombait sur un « false » derrière d'où le retour 1.
Ok.
Donc effectivement, lorsque l'on pipe, le code de retour est celui de la dernière commande. Bref, faire un test vite fait à cinq heures du mat avant de partir au boulot est une mauvaise idée. Refaire le même test après un journée de boulot où tu es parti tôt est tout autant inutile. Désolé pour le bruit, je vais me reposer.
Pas de souci, ça arrive et ça n'enlève rien à la qualité globale de tes interventions sur ce forum de news. Maintenant tout est clair... ou presque. ;) Je constate un truc un peu curieux du coup : ~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' echo fin ~$ /tmp/test.sh; echo $? A fin Perso, je trouve ça curieux car : - d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0, on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté. - mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté (du fait que la commande pipe « { ... } | tr ... » possède comme valeur de retour celle de tr. Du coup, c'est bizarre dans cette exemple on a un « set -e » qui fait qu'une partie du job, non ? Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant pas le cas sauf erreur. -- François Lafont
Lucas Levrel
Le 28 juillet 2016, Francois Lafont a écrit :
Maintenant tout est clair... ou presque. ;) Je constate un truc un peu curieux du coup : ~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' echo fin ~$ /tmp/test.sh; echo $? A fin
Je n'ai pas le temps de faire l'exemple minimal demandé par Benoît, mais je dois être dans une situation similaire car la commande qui foire est dans un for à l'intérieur de la liste { }. Je suppose donc que le foirage a interrompu l'itération en cours mais que le for a continué son œuvre...
Perso, je trouve ça curieux car : - d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0, on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté. - mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté (du fait que la commande pipe « { ... } | tr ... » possède comme valeur de retour celle de tr. Du coup, c'est bizarre dans cette exemple on a un « set -e » qui fait qu'une partie du job, non ? Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant pas le cas sauf erreur.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 28 juillet 2016, Francois Lafont a écrit :
Maintenant tout est clair... ou presque. ;)
Je constate un truc un peu curieux du coup :
~$ cat /tmp/test.sh
#!/bin/sh
set -e
{
echo 'a'
false
echo 'b'
} | tr '[a-z]' '[A-Z]'
echo fin
~$ /tmp/test.sh; echo $?
A
fin
Je n'ai pas le temps de faire l'exemple minimal demandé par Benoît, mais
je dois être dans une situation similaire car la commande qui foire est
dans un for à l'intérieur de la liste { }. Je suppose donc que le foirage
a interrompu l'itération en cours mais que le for a continué son œuvre...
Perso, je trouve ça curieux car :
- d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0,
on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit
avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté.
- mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car
le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté
(du fait que la commande pipe « { ... } | tr ... » possède comme valeur de
retour celle de tr.
Du coup, c'est bizarre dans cette exemple on a un « set -e » qui fait qu'une
partie du job, non ?
Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant
pas le cas sauf erreur.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Maintenant tout est clair... ou presque. ;) Je constate un truc un peu curieux du coup : ~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' echo fin ~$ /tmp/test.sh; echo $? A fin
Je n'ai pas le temps de faire l'exemple minimal demandé par Benoît, mais je dois être dans une situation similaire car la commande qui foire est dans un for à l'intérieur de la liste { }. Je suppose donc que le foirage a interrompu l'itération en cours mais que le for a continué son œuvre...
Perso, je trouve ça curieux car : - d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0, on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté. - mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté (du fait que la commande pipe « { ... } | tr ... » possède comme valeur de retour celle de tr. Du coup, c'est bizarre dans cette exemple on a un « set -e » qui fait qu'une partie du job, non ? Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant pas le cas sauf erreur.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Francois Lafont , dans le message <579a6304$0$3331$, a écrit :
~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' echo fin ~$ /tmp/test.sh; echo $? A fin Perso, je trouve ça curieux car : - mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté (du fait que la commande pipe « { ... } | tr ... » possède comme valeur de retour celle de tr.
Du point de vue du script, tout le premier bloc est une seule commande, de l'accolade à la fin de tr.
- d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0, on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté.
Mais le set -e est toujours en effet dans le bloc entre accolades, qui constitue un sous-script dont l'exécution est interrumpue.
Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant pas le cas sauf erreur.
La sémantique des accolades est bien de ne pas lancer de sous-shell. Mais chaque membre d'un pipeline est dans un sous-shell. Ça ne pourrait pas marcher sinon. Donc les accolades ne lancent pas un sous-sous-shell, mais sont bien déjà exécutées dans un sous-shell. (Remarque : avec zsh, le dernier élément du pipeline est lancé dans le shell actuel si possible. Ça permet des constructions du genre « command | read x » qui ne marcheraient pas sinon.
Francois Lafont , dans le message
<579a6304$0$3331$426a34cc@news.free.fr>, a écrit :
~$ cat /tmp/test.sh
#!/bin/sh
set -e
{
echo 'a'
false
echo 'b'
} | tr '[a-z]' '[A-Z]'
echo fin
~$ /tmp/test.sh; echo $?
A
fin
Perso, je trouve ça curieux car :
- mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car
le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté
(du fait que la commande pipe « { ... } | tr ... » possède comme valeur de
retour celle de tr.
Du point de vue du script, tout le premier bloc est une seule commande, de
l'accolade à la fin de tr.
- d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0,
on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit
avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté.
Mais le set -e est toujours en effet dans le bloc entre accolades, qui
constitue un sous-script dont l'exécution est interrumpue.
Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant
pas le cas sauf erreur.
La sémantique des accolades est bien de ne pas lancer de sous-shell. Mais
chaque membre d'un pipeline est dans un sous-shell. Ça ne pourrait pas
marcher sinon. Donc les accolades ne lancent pas un sous-sous-shell, mais
sont bien déjà exécutées dans un sous-shell.
(Remarque : avec zsh, le dernier élément du pipeline est lancé dans le shell
actuel si possible. Ça permet des constructions du genre
« command | read x » qui ne marcheraient pas sinon.
Francois Lafont , dans le message <579a6304$0$3331$, a écrit :
~$ cat /tmp/test.sh #!/bin/sh set -e { echo 'a' false echo 'b' } | tr '[a-z]' '[A-Z]' echo fin ~$ /tmp/test.sh; echo $? A fin Perso, je trouve ça curieux car : - mais d'un autre côté, le « set -e » ne fait pas son boulot complètement car le script ne s'arrête pas définitivement vu que le "echo fin" est exécuté (du fait que la commande pipe « { ... } | tr ... » possède comme valeur de retour celle de tr.
Du point de vue du script, tout le premier bloc est une seule commande, de l'accolade à la fin de tr.
- d'un côté j'ai le « set -e » qui dit « dès qu'une commande retourne x != 0, on arrête le script » et _d'une_ _certaine_ _manière_ c'est ce qui se produit avec le « false » qui fait que le « echo 'b' » n'est jamais exécuté.
Mais le set -e est toujours en effet dans le bloc entre accolades, qui constitue un sous-script dont l'exécution est interrumpue.
Ou alors je dois voir le { ... } comme un sous-shell mais ce n'est pourtant pas le cas sauf erreur.
La sémantique des accolades est bien de ne pas lancer de sous-shell. Mais chaque membre d'un pipeline est dans un sous-shell. Ça ne pourrait pas marcher sinon. Donc les accolades ne lancent pas un sous-sous-shell, mais sont bien déjà exécutées dans un sous-shell. (Remarque : avec zsh, le dernier élément du pipeline est lancé dans le shell actuel si possible. Ça permet des constructions du genre « command | read x » qui ne marcheraient pas sinon.
Francois Lafont
Bonjour, On 29/07/2016 00:40, Nicolas George wrote:
La sémantique des accolades est bien de ne pas lancer de sous-shell. Mais chaque membre d'un pipeline est dans un sous-shell. Ça ne pourrait pas marcher sinon. Donc les accolades ne lancent pas un sous-sous-shell, mais sont bien déjà exécutées dans un sous-shell.
Ok, merci beaucoup. C'était ça qui me manquait. La partie { ... } est exécutée dans un sous shell _à_ _cause_ de la présence du pipe et ce sous shell est bien interrompu à cause du "set -e". Mais au niveau du script courant, la commande « { ... } | tr .... », elle, renvoie bien 0 et le script courant peut continuer. Tout se tient. Merci encore Nicolas pour toutes ces explications très claires. -- François Lafont
Bonjour,
On 29/07/2016 00:40, Nicolas George wrote:
La sémantique des accolades est bien de ne pas lancer de sous-shell. Mais
chaque membre d'un pipeline est dans un sous-shell. Ça ne pourrait pas
marcher sinon. Donc les accolades ne lancent pas un sous-sous-shell, mais
sont bien déjà exécutées dans un sous-shell.
Ok, merci beaucoup. C'était ça qui me manquait. La partie { ... } est exécutée
dans un sous shell _à_ _cause_ de la présence du pipe et ce sous shell est bien
interrompu à cause du "set -e". Mais au niveau du script courant, la commande
« { ... } | tr .... », elle, renvoie bien 0 et le script courant peut continuer.
Tout se tient.
Merci encore Nicolas pour toutes ces explications très claires.
Bonjour, On 29/07/2016 00:40, Nicolas George wrote:
La sémantique des accolades est bien de ne pas lancer de sous-shell. Mais chaque membre d'un pipeline est dans un sous-shell. Ça ne pourrait pas marcher sinon. Donc les accolades ne lancent pas un sous-sous-shell, mais sont bien déjà exécutées dans un sous-shell.
Ok, merci beaucoup. C'était ça qui me manquait. La partie { ... } est exécutée dans un sous shell _à_ _cause_ de la présence du pipe et ce sous shell est bien interrompu à cause du "set -e". Mais au niveau du script courant, la commande « { ... } | tr .... », elle, renvoie bien 0 et le script courant peut continuer. Tout se tient. Merci encore Nicolas pour toutes ces explications très claires. -- François Lafont
