Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000257 [1003.1(2008)/Issue 7] Shell and Utilities Objection Error 2010-05-25 11:22 2013-04-16 13:06
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section make
Page Number 2913
Line Number 95706
Interp Status Approved
Final Accepted Text See Note: 0000428
Summary 0000257: make should not use the shell -e option when errors are ignored
Description The description of make states that it always executes the shell with
the -e option:

    "The execution line shall then be executed by a shell as if it
    were passed as the argument to the system() interface, except that
    the shell -e option shall also be in effect."

This does not match existing practice, which is that the shell's -e
option is only used by make if errors are not being ignored. If errors
are being ignored because of the -i option, a '-' command prefix, or
a .IGNORE special target then the command is executed without -e.
Desired Action Change

    except that the shell -e option shall also be in effect.

to

    except that if errors are not being ignored then the shell -e
    option shall also be in effect. If errors are being ignored for
    the command (as a result of the -i option, a '-' command prefix,
    or a .IGNORE special target), the shell -e option shall not be in
    effect.
Tags tc1-2008
Attached Files

- Relationships

-  Notes
(0000428)
Don Cragun (manager)
2010-06-03 15:49

Interpretation response
------------------------
The standard states commands run by make always use the shell -e option, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
This does not match historic practice.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the changes suggested in the Desired Action above.
(0000471)
eblake (manager)
2010-07-28 14:27

Paul Smith raised an interesting point on the GNU make list, which probably entails that we should revisit the wording of the interpretation response:

If your makefile is written to expect that it's invoked with -e, then
allowing the user to turn that off simply by passing -i on the make
command line seems incredibly dangerous!

Suppose you have a makefile like this:

    PREFIX = /foo

    clean: ; [ "$(PREFIX)" != "" ]; rm -rf $(PREFIX)/*

You are relying on the behavior of -e to cause the rule to exit when the
condition is not met, so that you don't wipe out your entire root
partition.

Now someone comes along and runs "make -i", and voila! Instant
devastation.

Yes, of course this is a contrived example but it's not hard to imagine
perfectly legitimate situations where this would be bad. In the new
POSIX model where -e is expected, you have to anticipate that makefile
recipes will be written to make use of that fact (otherwise why bother?)
and simply turning off that flag on the command line seems really
horrible.

I can see it could be useful when starting a command with "-"; in that
case the person actually writing the command made a conscious decision
that they wanted to disable -e when they wrote the recipe.
(0000472)
geoffclare (manager)
2010-07-28 15:01

(Response to Note: 0000471)
The proposed changes just make the standard match long standing
existing practice. I.e. the situation Paul Smith describes is already
the case; POSIX is not creating the situation by making this change.

It might be worth adding something to APPLICATION USAGE warning about
not relying on -e being in effect.
(0000473)
psmith (developer)
2010-07-28 16:04

"Long standing existing practice" except by those implementations of make, such as GNU make (one of the most widely used, and around since the 1980's), which adhere to the expressly-stated requirements in previous versions of the standard (no -e at all) that were summarily tossed in this latest version of POSIX, you mean? ;-)

If we're going to recommend not relying on -e being in effect, why require it to be there in the first place? Maybe it would be better to declare it an implementation option (whether the -e is provided or not); at least makefile authors would know what they're up against--and implementations that were previously conformant, like GNU make, would still conform, rather than suddenly no longer being standard and facing a painful choice of either not conforming, or breaking backwards-compatibility with an enormous corpus of existing makefiles.

Is there a charter or something where I can learn what the goals of the group are, and what the principles are for making decisions? Is it only to standardize existing practice as determined by "the majority of implementations"? Or is it acceptable to decline to require behaviors which appear to be problematic?

Thanks!
(0000474)
ajosey (manager)
2010-07-28 16:19

Details on the scope of the Austin Group, and its procedures for decision making are available from the Austin Group web page.

http://www.opengroup.org/austin/papers/backgrounder.html [^]
http://www.opengroup.org/austin/docs/austin_112r3.txt [^]
http://www.opengroup.org/austin/docs/austin_14r2.pdf [^]

The last of these details the consensus process for contentious items.
(0000517)
ajosey (manager)
2010-07-30 09:45

Comments/objections on the proposed interpretation are due by 31 Aug 2010

- Issue History
Date Modified Username Field Change
2010-05-25 11:22 geoffclare New Issue
2010-05-25 11:22 geoffclare Status New => Under Review
2010-05-25 11:22 geoffclare Assigned To => ajosey
2010-05-25 11:22 geoffclare Name => Geoff Clare
2010-05-25 11:22 geoffclare Organization => The Open Group
2010-05-25 11:22 geoffclare Section => make
2010-05-25 11:22 geoffclare Page Number => 2913
2010-05-25 11:22 geoffclare Line Number => 95706
2010-05-25 11:22 geoffclare Interp Status => ---
2010-06-03 15:49 Don Cragun Note Added: 0000428
2010-06-03 15:50 Don Cragun Interp Status --- => Pending
2010-06-03 15:50 Don Cragun Final Accepted Text => See Note: 0000428
2010-06-03 15:50 Don Cragun Status Under Review => Interpretation Required
2010-06-03 15:50 Don Cragun Resolution Open => Accepted
2010-07-28 14:27 eblake Note Added: 0000471
2010-07-28 15:01 geoffclare Note Added: 0000472
2010-07-28 16:04 psmith Note Added: 0000473
2010-07-28 16:19 ajosey Note Added: 0000474
2010-07-30 09:45 ajosey Interp Status Pending => Proposed
2010-07-30 09:45 ajosey Note Added: 0000517
2010-09-03 06:22 ajosey Interp Status Proposed => Approved
2010-09-24 16:06 geoffclare Tag Attached: tc1-2008
2011-12-07 23:25 dwheeler Issue Monitored: dwheeler
2013-04-16 13:06 ajosey Status Interpretation Required => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker