View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000257 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2010-05-25 11:22 | 2013-04-16 13:06 |
| Reporter | geoffclare | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | make | ||||
| Page Number | 2913 | ||||
| Line Number | 95706 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000257: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 | ||||
|
|
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. |
|
|
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. |
|
|
(Response to 0000257: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. |
|
|
"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! |
|
|
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. |
|
|
Comments/objections on the proposed interpretation are due by 31 Aug 2010 |
| 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 0000257: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 | |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
