Derrière ce sujet un rien provocateur ce cache une question toute bête :
$ cd /tmp
$ cat > Makefile
all:
@false; true;
^D
$ make
*** Error code 1
Stop in /tmp.
$ gmake
$
Résumons : une ligne de commande, dans le Makefile, ne semble pas
être équivalente à "sh -c 'la ligne de commande'" mais est apparement
interpreté d'une facon bizarre...
Question : pourquoi une ligne de commande n'est-elle pas équivalente à
une seule ligne de commande lancée dans un seul shell, dont make ne
regarderait que le code d'erreur global (et pas tous les codes d'erreurs
intermédiaires) ? Est-ce par pure méchanceté, ou est-ce un moyen
détourné de faire l'apologie de gnumake ? :-)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
cedric
C'est bon, je viens de faire man sh et j'ai trouvé.
Comme je le pensais, il s'agit donc bien de quelquechose d'ingénieux : lancer sh avec l'option -e pour éviter qu'une commande dont l'erreur n'est pas "catchée" entraine une gross katasstroff.
Merci à moi même pour cette réponse rapide et précise.
C'est bon, je viens de faire man sh et j'ai trouvé.
Comme je le pensais, il s'agit donc bien de quelquechose d'ingénieux :
lancer sh avec l'option -e pour éviter qu'une commande dont l'erreur
n'est pas "catchée" entraine une gross katasstroff.
Merci à moi même pour cette réponse rapide et précise.
C'est bon, je viens de faire man sh et j'ai trouvé.
Comme je le pensais, il s'agit donc bien de quelquechose d'ingénieux : lancer sh avec l'option -e pour éviter qu'une commande dont l'erreur n'est pas "catchée" entraine une gross katasstroff.
Merci à moi même pour cette réponse rapide et précise.
espie
In article <40f28bcf$0$26954$, cedric wrote:
Derrière ce sujet un rien provocateur ce cache une question toute bête :
$ cd /tmp $ cat > Makefile all: @false; true; ^D $ make *** Error code 1
Stop in /tmp. $ gmake $
Résumons : une ligne de commande, dans le Makefile, ne semble pas être équivalente à "sh -c 'la ligne de commande'" mais est apparement interpreté d'une facon bizarre...
Question : pourquoi une ligne de commande n'est-elle pas équivalente à une seule ligne de commande lancée dans un seul shell, dont make ne regarderait que le code d'erreur global (et pas tous les codes d'erreurs intermédiaires) ? Est-ce par pure méchanceté, ou est-ce un moyen détourné de faire l'apologie de gnumake ? :-)
Essaie plutot sh -e -c 'la ligne de commande'.
C'est de la mechancete, mais pas pure du tout. Un fragment de shell qui lance des commandes intermediaires qui echouent autrement que dans des tests merite de se gauffrer dans les grandes largeurs.
Ca evite de rechercher trois cents lignes plus loin pourquoi ca marche pas, alors que c'est une bete commande intermediaire qui a plante.
Accessoirement, au moins sous OpenBSD, il y a un petit bug dans notre shell (ksh) qui fait que deux/trois constructions qui devraient passer ne fonctionnent pas.
En particulier, le test classique false && true fonctionne tout seul, mais foire dans une boucle.
In article <40f28bcf$0$26954$626a14ce@news.free.fr>,
cedric <rixed@happyleptic.NOSPAM.org> wrote:
Derrière ce sujet un rien provocateur ce cache une question toute bête :
$ cd /tmp
$ cat > Makefile
all:
@false; true;
^D
$ make
*** Error code 1
Stop in /tmp.
$ gmake
$
Résumons : une ligne de commande, dans le Makefile, ne semble pas
être équivalente à "sh -c 'la ligne de commande'" mais est apparement
interpreté d'une facon bizarre...
Question : pourquoi une ligne de commande n'est-elle pas équivalente à
une seule ligne de commande lancée dans un seul shell, dont make ne
regarderait que le code d'erreur global (et pas tous les codes d'erreurs
intermédiaires) ? Est-ce par pure méchanceté, ou est-ce un moyen
détourné de faire l'apologie de gnumake ? :-)
Essaie plutot sh -e -c 'la ligne de commande'.
C'est de la mechancete, mais pas pure du tout. Un fragment de shell qui
lance des commandes intermediaires qui echouent autrement que dans des
tests merite de se gauffrer dans les grandes largeurs.
Ca evite de rechercher trois cents lignes plus loin pourquoi ca marche
pas, alors que c'est une bete commande intermediaire qui a plante.
Accessoirement, au moins sous OpenBSD, il y a un petit bug dans notre shell
(ksh) qui fait que deux/trois constructions qui devraient passer ne
fonctionnent pas.
En particulier, le test classique
false && true
fonctionne tout seul, mais foire dans une boucle.
Derrière ce sujet un rien provocateur ce cache une question toute bête :
$ cd /tmp $ cat > Makefile all: @false; true; ^D $ make *** Error code 1
Stop in /tmp. $ gmake $
Résumons : une ligne de commande, dans le Makefile, ne semble pas être équivalente à "sh -c 'la ligne de commande'" mais est apparement interpreté d'une facon bizarre...
Question : pourquoi une ligne de commande n'est-elle pas équivalente à une seule ligne de commande lancée dans un seul shell, dont make ne regarderait que le code d'erreur global (et pas tous les codes d'erreurs intermédiaires) ? Est-ce par pure méchanceté, ou est-ce un moyen détourné de faire l'apologie de gnumake ? :-)
Essaie plutot sh -e -c 'la ligne de commande'.
C'est de la mechancete, mais pas pure du tout. Un fragment de shell qui lance des commandes intermediaires qui echouent autrement que dans des tests merite de se gauffrer dans les grandes largeurs.
Ca evite de rechercher trois cents lignes plus loin pourquoi ca marche pas, alors que c'est une bete commande intermediaire qui a plante.
Accessoirement, au moins sous OpenBSD, il y a un petit bug dans notre shell (ksh) qui fait que deux/trois constructions qui devraient passer ne fonctionnent pas.
En particulier, le test classique false && true fonctionne tout seul, mais foire dans une boucle.
cedric
Marc Espie wrote:
C'est de la mechancete, mais pas pure du tout. Un fragment de shell qui lance des commandes intermediaires qui echouent autrement que dans des tests merite de se gauffrer dans les grandes largeurs.
Le shell qui me posait problème faisait ca :
@find machin1 machin2 ERR=$$? if [ $ERR ... ] etc...
Je n'osais pas trop insister pour que l'on utilise un style plus direct lorsqu'on travaille en shell. Maintenant, j'ai un argument-massue ;)
Marc Espie wrote:
C'est de la mechancete, mais pas pure du tout. Un fragment de shell qui
lance des commandes intermediaires qui echouent autrement que dans des
tests merite de se gauffrer dans les grandes largeurs.
Le shell qui me posait problème faisait ca :
@find machin1 machin2
ERR=$$?
if [ $ERR ... ] etc...
Je n'osais pas trop insister pour que l'on utilise un style plus direct
lorsqu'on travaille en shell. Maintenant, j'ai un argument-massue ;)
C'est de la mechancete, mais pas pure du tout. Un fragment de shell qui lance des commandes intermediaires qui echouent autrement que dans des tests merite de se gauffrer dans les grandes largeurs.
Le shell qui me posait problème faisait ca :
@find machin1 machin2 ERR=$$? if [ $ERR ... ] etc...
Je n'osais pas trop insister pour que l'on utilise un style plus direct lorsqu'on travaille en shell. Maintenant, j'ai un argument-massue ;)
