standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag)

[Mark D. Baushke]

The following reply was made to PR standards/66357; it has been noted by GNATS.

From: "Mark D. Baushke" <mdb at juniper.net>
To: harti at FreeBSD.ORG
Cc: FreeBSD-gnats-submit at FreeBSD.ORG,
	"Simon J. Gerraty" <sjg at crufty.net>
Subject: Re: standards/66357: make POSIX conformance problem ('sh -e' & '+' command-line flag) 
Date: Tue, 25 May 2004 12:22:10 -0700

 Harti Brandt <novo at cs.tu-berlin.de> writes:
 
 > [CC's removed]
 > 
 > [Sorry for the delay, I just discovered that this is still in my mailbox].
 > 
 > On Mon, 10 May 2004, Mark D. Baushke wrote:
 > 
 > > Harti Brandt <novo at cs.tu-berlin.de> writes:
 > >
 > > > On Fri, 7 May 2004, Mark D. Baushke wrote:
 > > >
 > > > >
 > > > > >Number:         66357
 > > > > >Category:       standards
 > > > > >Synopsis:       make POSIX conformance problem ('sh -e' & '+' command-line)
 > > ...
 > > > > >Description:
 > > > > Background:
 > > > >
 > > > > POSIX 1003.2-1997 states that each makefile command line is processed
 > > > > as if given to system(3) (see URL
 > > > > http://www.opengroup.org/onlinepubs/009695399/utilities/make.html)
 > > > >
 > > > > POSIX 1003.1-2004 (as well as older versions of the standard) states
 > > > > that system() does not use the "sh -e" command to exit immediately if
 > > > > any untested command fails in non-interactive mode. (see URL
 > > > > http://www.opengroup.org/onlinepubs/009695399/functions/system.html)
 > > ...
 > > >
 > > > The 'sh -e' servers a purpose if you have a more
 > > > complicated shell line say a loop. Without -e make will
 > > > not stop even if there is an error in an inner command of
 > > > a shell loop, while with -e it will exit. I'd say that not
 > > > using -e is a posix-bug, not a feature and, in fact, there
 > > > has been thoughts on the austin group mailing list to
 > > > review this.
 > >
 > > If you have any particular URLs for those austin group
 > > mailing list threads, I would be interested in reading them.
 > > I tried to do a quick google search and did not meet with
 > > success to finding such a discussion.
 > 
 > I'm currently moving jobs and have no access to my link-list, but
 > you should be able to find the mailing lists on the opengroup web page.
 > I know that they are not easy to find - watch for Austing Group.
 > 
 > >
 > > > I'd think even if we remove the -e in the posix case, we
 > > > must retain it in the non-posix case.
 > >
 > > fwiw: I have found the 'sh -e' feature to be fragile and
 > > more likely to do the wrong thing in a complicated action
 > > rule especially across multiple platforms.
 > 
 > The big problem is things like
 > 
 > HDRS=a.h b.h c.h
 > 
 > install:
 >  	for i in $(HDRS) ; do cp $$i /dest ; done
 >
 > If one of the cp's fail, make should abort. That is possible only when
 > doing sh -e. Otherwise a failing cp will just go by unnoticed.
 
 If the POSIX user wants your semantics, doing
 
 install:
 	for i in $(HDRS) ; do cp $$i /dest || exit 1; done
 
 should work and is much more explicit about when and how a failure
 should occur.
  
 > What kind of fragility did you see?
 
 Typically, this has been with projects that use POSIX make programs and
 have fairly non-trivial actions for a given rule. Something like this:
 
 failed=0; all=0; xfail=0; xpass=0; skip=0;  srcdir=../../lib; export srcdir;  list='test-getdate.sh';  if test -n "$list"; then  for tst in $list; do  if test -f ./$tst; then dir=./;  elif test -f $tst; then dir=;  else dir="../../lib/"; fi;  if  ${dir}$tst; then  all=`expr $all + 1`;  case "  " in  *" $tst "*)  xpass=`expr $xpass + 1`;  failed=`expr $failed + 1`;  echo "XPASS: $tst";  ;;  *)  echo "PASS: $tst";  ;;  esac;  elif test $? -ne 77; then  all=`expr $all + 1`;  case "  " in  *" $tst "*)  xfail=` expr $xfail + 1`;  echo "XFAIL: $tst";  ;;  *)  failed=`expr $failed + 1`;  echo "FAIL: $tst";  ;;  esac;  else  skip=`expr $skip + 1`;  echo "SKIP: $tst";  fi;  done;  if test "$failed" -eq 0; then  if test "$xfail" -eq 0; then  banner="All $all tests passed";  else  banner="All $all tests behaved as expected ($xfail expected failures)";  fi;  else  if test "$xpass" -eq 0; then  banner="$failed of $all tests failed";  else  banner="$failed of $all tests did not behave as 
 e!
  xpected ($xpass unexpected passes)";  fi;  fi;  dashes="$banner";  skipped="";  if test "$skip" -ne 0; then  skipped="($skip tests were not run)";  test `echo "$skipped" | wc -c` -gt `echo "$banner" | wc -c` &&  dashes="$skipped";  fi;  report="";  if test "$failed" -ne 0 && test -n "bug-LIST at LIST.org"; then  report="Please report to bug-LIST at LIST.org";  test `echo "$report" | wc -c` -gt `echo "$banner" | wc -c` &&  dashes="$report";  fi;  dashes=`echo "$dashes" | sed s/./=/g`;  echo "$dashes";  echo "$ba nner";  test -n "$skipped" && echo "$skipped";  test -n "$report" && echo "$report";  echo "$dashes";  test "$failed" -eq 0;  else :; fi
 
 which the automake folks had used in one of their templates.
 
 > > I also wonder if you will also have time to consider how to
 > > deal with a .POSIX: setting in a Makefile after sys.mk has
 > > already apparently been read in and processed including a
 > > number of .if defined(%POSIX) macros settings being done
 > > already before the first line of the user's Makefile is
 > > processed...
 > 
 > There is a long way to get our make POSIX compliant. I think this should
 > be done very careful step by step. I have already one change in the pipe
 > for three months now (standards/57295) - the problem is not to break large
 > numbers of ports, so I really don't want to comnment on the %POSIX stuff
 > atm. Perhaps it would be best to open another PR for this so we don't mix
 > different things.
 
 Okay, I'll try to report it sometime next week (after the holiday).
 
 > > I look forward to learning what FreeBSD will do.
 > 
 > I'll try to move our make in the POSIX direction, but, as I said this will
 > take some time because make is a very central utility to the system.
 > 
 > Let me first get the above PR finished, the I will move on to this one.
 > 
 > harti
 
 With regard to 57295, I was under the impression that .MAKEFLAGS was not
 part of the POSIX standard, but that MAKEFLAGS is. I believe that the
 suggested patch modifies the .MAKEFLAGS variable... Of course, the other
 interesting problem is that there are still '#ifdef POSIX' fragments
 laying around in the /usr/src/usr.bin/make tree to confuse the issue.
 
 I do understand it may take time to get this stuff fixed, but I do think
 it is a good design goal.
 
 	Thank you,
 	-- Mark