Problème étrange de redirection avec gnumake

J'ai un système dans lequel je crée un makefile et qui fonctionne parfaitement sous Mac OS X. Quand je l'exécute sous Linux, j'ai un problème étrange. J'ai réussi à réduire mon makefile à un exemple très simple:Problème étrange de redirection avec gnumake

 
    compile: 
     gcc -o prog *.c &> compile__ 

    chm: 
     chmod u=rwx,g=rwx,o= prog 

    both0: 
     gcc -o prog *.c &> compile__ ; \ 
     chmod u=rwx,g=rwx,o= prog 

    both1: 
     gcc -o prog *.c ; \ 
     chmod u=rwx,g=rwx,o= prog

L'idée est de compiler un fichier, puis de modifier ses permissions. Si j'exécute la séquence de commande:

 
    make compile 
    make chm

Tout fonctionne correctement. Toutefois, si j'Execute:

 
    make both0

je reçois le message:

 
    chmod: cannot access `prog': No such file or directory

et les autorisations ne sont pas modifiés. D'autre part, si j'Execute:

 
    make both1

les autorisations sont modifiées de manière appropriée. La seule différence est la redirection "&> compile__" sous both0 que j'ai supprimé pour both1.

Des idées?

Source

2011-04-14 Tsf

J'ai oublié de mentionner que je lance gnumake version 3.81 sous Ubuntu Linux. – Tsf

Fonctionne pour moi: CentOS version 5.4 (Final); GNU Make 3.81; gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46); Bonjour c; –

Je l'ai testé sur un autre Linux: Fedora version 9 (Sulphur) et le même GNU Make 3.81. Aucun problème! Il semble ne se produire que sous mon installation: Ubuntu 10.04.2 LTS, noyau 2.6.32-30. – Tsf

&> compile__

est pas une redirection portable. En bash, il redirige à la fois l'erreur standard et la sortie standard, ce que je suppose être votre intention. D'autres obus sont susceptibles de faire différentes choses avec. En particulier, dash arrière-plans la commande (le &), et redirige sortie standard (le > compile__). Le chmod est exécuté avant la fin de la compilation et crée prog. La redirection de l'erreur standard et de la sortie standard peut être effectuée de manière portative avec cc -o prog *.c > compile__ 2>&1.

(Pourquoi at-il fonctionne sur Mac? Peut-être un autre shell qui interprète &> différemment, possible le compilateur d'ouvrir le fichier plus tôt, peut-être une condition de course qui sort un peu différemment.)

Source

2011-04-14 22:56:27 wnoise

Dans bash, '' &> ''redirige stdout et stderr vers le même fichier; il n'a pas d'effet d'arrière-plan. –

Les trois systèmes que j'ai testés (Mac OS, Fedora et Ubuntu) utilisent le même GNU Bash, donc ils ne devraient pas se comporter différemment. – Tsf

Make utilise le système/bin/sh, qui peut ne pas être bash. Les systèmes Ubuntu utilisent généralement "dash" pour/bin/sh. Dash fait en effet de l'arrière-plan, et exécute une commande vide redirigeant vers "compile__" @Tsf: humourne-moi et essaie de passer à '> compile__ 2> & 1', la manière standard de faire cette redirection. – wnoise

Une solution alternative consiste à spécifier le shell pour GNU make à utiliser. Section 5.3.1 du manuel a des informations à ce sujet. Par exemple, les éléments suivants

export SHELL=`which bash`

Dans un Makefile semble se Gnu Faites 3.8.1 sur Ubuntu/Debian pour choisir bash comme la coquille.

D'autres problèmes sont les différences dans le comportement de tous les shell de haut-, comme echo, printf, test, etc. Options Esoteric à ces peuvent mystérieusement de haut- échouer lorsqu'il est exécuté sous make sur les systèmes Debian .

Source

2013-06-11 16:45:51

Problème étrange de redirection avec gnumake

Répondre

Questions connexes