RE: Problems with gmake and pipefail. make doesn't give up.
On Wed, 2007-06-20 at 17:32 +0200, Erwin Waterlander wrote: > I compiled bash 3.2 locally. When I set > SHELL=/home/waterlan/src/bash-3.2/bash -e -o pipefail everything > works as expected. So the problem must be in the AT&T sh. As far as I know, ksh doesn't support pipefail. If so, it's not a "problem" in that shell; the problem is you're trying to use a bash-specific extension (pipefail option) in a shell other than bash. Personally, I would be very unhappy to run across a makefile that was built to only work with bash and no other shell. I realize it's messy to handle errors from early commands in pipelines, but it IS possible to do in standard sh without using extensions. Regardless, at least if you set SHELL in the makefile to bash it will be clear what's required so that's a good thing. Cheers! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Problems with gmake and pipefail. make doesn't give up.
Hi, I compiled bash 3.2 locally. When I set SHELL=/home/waterlan/src/bash-3.2/bash -e -o pipefail everything works as expected. So the problem must be in the AT&T sh. -- Erwin Waterlander From: Erwin Waterlander Sent: Wed 6/20/2007 16:46 To: bug-make@gnu.org Subject: Problems with gmake and pipefail. make doesn't give up. Hi, I have a problem that gnu make doesn't give up after an error in a command in a pipe. I have attached a simple example. I run a command (ls) and the output is piped to command 'tee' to send the output of 'ls' to a file and stdout. Normally the shell returns the exit code of the last command in a pipe. In this case it is tee, which returns 0 even if 'ls' fails. Therefore I set the shell option "-o pipefail" so that the last non-zero return code of a command in a pipe is returned. But gnu-make still continues after a failing 'ls adsfafa' command. When I echo the exit code ($?) you can see that it is non-zero. How can I make that gnu-make stops after the first failing ls command? Here is the output when I type make: echo SHELL=/bin/ksh -e -o pipefail SHELL=/bin/ksh -e -o pipefail ls > ls.log ;echo $? 0 ls adsfafa | tee -i ls.log ls: adsfafa: No such file or directory ls adsfafa | tee -i ls.log ;echo $? ls: adsfafa: No such file or directory 1 ls b | tee -i ls.log ls: b: No such file or directory I used shell /bin/ksh, which is on our system "sh (AT&T Labs Research) 1993-12-28". I you want to test this with "bash" you need version 3 to have support for the -o pipefail option. We don't have bash 3 on our system, only bash version 2.05. I tried gnu-make version 3.81 -- Erwin Waterlander ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Problems with gmake and pipefail. make doesn't give up.
Hi,
I have a problem that gnu make doesn't give up after an error in a command in a
pipe. I have attached a simple example.
I run a command (ls) and the output is piped to command 'tee' to send the
output of 'ls' to a file and stdout. Normally the shell returns the exit code
of the last command in a pipe. In this case it is tee, which returns 0 even if
'ls' fails. Therefore I set the shell option "-o pipefail" so that the last
non-zero return code of a command in a pipe is returned.
But gnu-make still continues after a failing 'ls adsfafa' command. When I echo
the exit code ($?) you can see that it is non-zero. How can I make that
gnu-make stops after the first failing ls command?
Here is the output when I type make:
echo SHELL=/bin/ksh -e -o pipefail
SHELL=/bin/ksh -e -o pipefail
ls > ls.log ;echo $?
0
ls adsfafa | tee -i ls.log
ls: adsfafa: No such file or directory
ls adsfafa | tee -i ls.log ;echo $?
ls: adsfafa: No such file or directory
1
ls b | tee -i ls.log
ls: b: No such file or directory
I used shell /bin/ksh, which is on our system "sh (AT&T Labs Research)
1993-12-28". I you want to test this with "bash" you need version 3 to have
support for the -o pipefail option. We don't have bash 3 on our system, only
bash version 2.05.
I tried gnu-make version 3.81
--
Erwin Waterlander
SHELL=/bin/ksh -e -o pipefail
ls :
echo SHELL=${SHELL}
ls > ls.log ;echo $$?
ls adsfafa | tee -i ls.log
ls adsfafa | tee -i ls.log ;echo $$?
ls b | tee -i ls.log
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On Wednesday 20 June 2007, Paul Smith wrote: > the variable being defined. In fact nothing is parsed inside a > define. I'm not sure, from your message, if this is what you feel is > the surprising behavior; Right - that's what surprised me. i assumed that comments were skipped during the initial read-in of the makefile, regardless of their context. The behaviour does make sense once one learns that define is parsed as a literal. That also explains why i can't use if/endif inside a define. > to me it seems exactly the way things should > work. Think of a define as kind of like single-quoted strings in the > shell: no special characters are evaluated. Agreed - i hadn't considered defines to be literals. Thanks again for the detailed explanation! :) PS: it might interest some list readers to know that i recently forked a copy of O'Reilly's "Managing Projects with GNU Make" and am steadily updating it: http://www.wanderinghorse.net/computing/make/ If anyone out there is interested in contributing to the book, please feel free to get in touch. -- - [EMAIL PROTECTED] http://www.wanderinghorse.net signature.asc Description: This is a digitally signed message part. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On Wednesday 20 June 2007, Philip Guenther wrote: > On 6/19/07, Stephan Beal <[EMAIL PROTECTED]> wrote: > Okay, so you've defined a variable, 'bogo', whose value consists of > two lines, the first of which has a '#' as its first non-whitespace > character. It isn't a comment at that point, it's just a line with a > leading '#'. i see. That makes perfect sense, actually. My intuition told me that comments are skipped at an earlier parsing phase (e.g., filtered out long before the 'define'd item is called), but obviously that's not the case. > (Then there are comments in the commands for rules, where if they're > indented with a tab then make sees them as normal parts of the > commands and passes them to the shell...which then will often ignore > them based on *its* rules.) The book "Managin Projects with GNU Make" demonstrates using that as an intesting test/debugging feature instead of using 'echo': foo: # MAKEFILE_LIST=$(MAKEFILE_LIST) Thanks for the clarification! :) -- - [EMAIL PROTECTED] http://www.wanderinghorse.net signature.asc Description: This is a digitally signed message part. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On Tue, 2007-06-19 at 20:50 +0200, Stephan Beal wrote: > When a $(warning) or $(error) is inside a 'define', it is evaluated > even if it is part of a comment. Others have responded with all the info but I'm not sure everyone understood it. There are two factors at work here. First, note that make does not do comment processing inside a define statement. If you add a "#" inside a define, then that literal character "#" (plus the rest of the line) is present in the value of the variable being defined. In fact nothing is parsed inside a define. I'm not sure, from your message, if this is what you feel is the surprising behavior; to me it seems exactly the way things should work. Think of a define as kind of like single-quoted strings in the shell: no special characters are evaluated. Second, note that comment characters IN COMMAND SCRIPTS are not interpreted by make as make comments, either. That is this: foo: # bar is a target "foo" with a comment after it and no command script, while this: foo: # bar is a target "foo" with a command script of "# bar", which passed to the shell as normal and may or may not end up being a comment in the shell. So, when you put a variable $(foo) in a command script (preceded by a TAB) and it's expanded, the expanded value is not parsed for make comments. The "#" and following text is kept. Then, of course, before make invokes the shell it expands the script, and when that happens the $(warning ...) or $(info ...) or whatever else is evaluated. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?
On Tue, Jun 19, 2007 at 08:50:32PM +0200, Stephan Beal wrote: > Hi, Makers! > > i just discovered a Make behaviour which really surprises me. While that > in itself is nothing new ;), this one certainly violates the principal > of least astonishment: > > When a $(warning) or $(error) is inside a 'define', it is evaluated even > if it is part of a comment. A demonstration: > > [EMAIL PROTECTED]:~/cvs/www.t5$ make --version > GNU Make 3.81 > ... > > Input file to reproduce problem: > #!/usr/bin/make -f > ## > default: all > define bogo ># $(warning this should not be evaluated here: (bogo $(1))) >abc := $(1) > endef On the other hand I would have been suprised if make supported having comments between define/endef. So in several cases I have used define/endef to avoid the need to quote "#". Or in other words if "#" suddenly becomes a comment inside define/endef some Makefile's will break. Sam ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
