 Relationships |
||||||
|
||||||
| Anonymous | Login | 2024-09-16 22:19 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Type | Date Submitted | Last Update | ||
| 0000984 | [1003.1(2013)/Issue7+TC1] Shell and Utilities | Objection | Enhancement Request | 2015-09-11 13:53 | 2024-06-11 09:02 | ||
| Reporter | geoffclare | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted | ||||
| Status | Closed | ||||||
| Name | Geoff Clare | ||||||
| Organization | The Open Group | ||||||
| User Reference | |||||||
| Section | m4 | ||||||
| Page Number | 2902 | ||||||
| Line Number | 95756-95758 | ||||||
| Interp Status | --- | ||||||
| Final Accepted Text | Implement the desired action. | ||||||
| Summary | 0000984: m4exit(0) after an error should result in non-zero exit status | ||||||
| Description |
Implementations differ in the exit status of m4 when m4exit(0) is called after an error has occurred. For TC2 this is being made explicitly unspecified via 0000964. However, for Issue 8 a non-zero exit should be specified because exiting with zero status hides the fact that an error occurred from shell scripts that check the exit status of m4. |
||||||
| Desired Action |
On page 2902 line 95756-95758, after applying bug 964 change: If the first argument is zero or no argument is specified, and an error has previously occurred (for example, a file operand that could not be opened), it is unspecified whether the exit status is zero or non-zero. to: If the first argument is zero or no argument is specified, and an error has previously occurred (for example, a file operand that could not be opened), the exit status shall be non-zero. On page 2905 line 95905 add a new paragraph to the RATIONALE section: Earlier versions of this standard allowed the exit status to be either zero or non-zero when <tt>m4exit(0)</tt> is called after an error has occurred. Exiting with zero status is now disallowed as this hides the fact that an error occurred from shell scripts that check the exit status of m4. |
||||||
| Tags | issue8 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
||||||
|
||||||
|
Notes |
|
|
(0002826) shware_systems (reporter) 2015-09-11 15:16 |
Please change to: ...the exit status shall be the non-zero code representing the error detected. It is implementation-defined whether a diagnostic is written to stderr that an override of the error return was attempted, as an aid to debugging. Leaving it as simply non-zero means returning 1 in all cases would be conforming, but the code for "file can't be opened" might be 27. While as is only pass/fail logic in scripts is portable, for implementation-specific scripts recovery code will need the number assigned by the implementation, imo. |
|
(0003278) joerg (reporter) 2016-06-30 16:35 |
Which m4 implementation behaves the way requested by the desired actions for this bug? Solaris m4 does not seem to behave this way and gm4 also does not behave this way. |
|
(0003280) geoffclare (manager) 2016-07-01 08:39 |
GNU m4 behaves that way. See Note: 0002763 |
|
(0003286) joerg (reporter) 2016-07-05 09:48 |
printf 'bye\nm4exit(0)' | POSIXLY_CORRECT=1 gm4 nosuch -; echo $? gm4: nosuch: No such file or directory bye 0 I cannot repeat your claim. So my conclusion is that there is no implementation that behaves like the proposal and the proposal is in conflict with other UNIX behavior. The shell e.g. exits with the last exit code if you omit the "exit" parameter. false exit does e.g. cause the shell to exit with a non-zero exit code while false exit 0 causes the shell to exit with a zero exit code. An non-zero exit code from m4exit(0) is highly confusing and cannot be accepted. |
|
(0003287) geoffclare (manager) 2016-07-05 10:07 |
I can reproduce Eric's result on a Debian "Jessie" system: $ m4 --version | head -n 1 m4 (GNU M4) 1.4.17 $ printf 'bye\nm4exit(0)' | POSIXLY_CORRECT=1 m4 nosuch -; echo $? m4: cannot open `nosuch': No such file or directory bye 1 Presumably Eric used an up-to-date Red Hat system. Your "gm4" whatever that is, does not behave the same as current versions of GNU m4. Your comparison of m4 with the shell is not relevant because the situation being addressed here for m4 cannot happen in the shell (because the shell does not accept multiple command_file operands). |
|
(0003288) nick (manager) 2016-07-07 02:17 edited on: 2016-07-07 02:18 |
I agree Geoff; in addition, git blame on GNU m4 tells me the Eric knows the answer better than anyone (he was the committer for this: 2006-07-27 Eric Blake <ebb9@byu.net>)! |
|
(0003289) joerg (reporter) 2016-07-07 11:59 edited on: 2016-07-07 11:59 |
I did check GNU m4 1.4.2 and if a sub-minor release introduces such an incompatible change, this does not look like a good idea to follow. Let me again give the reason, why the proposal is not acceptable: - it prevents controllable behavior. - calling m4exit (without a parameter) to return with the error state is sufficient - permitting to call m4exit(0) or whatever value keeps the control in the hands of the programmer. |
|
(0003290) geoffclare (manager) 2016-07-07 14:50 |
Having control in the circumstance in question is of no use to the programmer because the programmer has no way of finding out whether a file-not-found error has previously occurred in order to decide whether calling m4exit(0) would be appropriate. Therefore your proposed alternative would simply result in m4exit(0) being something that should never be called. Existing GNU m4 programs that call it would need to be changed to call m4exit() with no parameter. You seem to be the only person to whom "the proposal is not acceptable". Everyone else on the 30th June conference call was happy to accept it. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2015-09-11 13:53 | geoffclare | New Issue | |
| 2015-09-11 13:53 | geoffclare | Name | => Geoff Clare |
| 2015-09-11 13:53 | geoffclare | Organization | => The Open Group |
| 2015-09-11 13:53 | geoffclare | Section | => m4 |
| 2015-09-11 13:53 | geoffclare | Page Number | => 2902 |
| 2015-09-11 13:53 | geoffclare | Line Number | => 95756-95758 |
| 2015-09-11 13:53 | geoffclare | Interp Status | => --- |
| 2015-09-11 13:54 | geoffclare | Relationship added | related to 0000964 |
| 2015-09-11 15:16 | shware_systems | Note Added: 0002826 | |
| 2016-06-30 16:23 | Don Cragun | Final Accepted Text | => Implement the desired action. |
| 2016-06-30 16:23 | Don Cragun | Status | New => Resolved |
| 2016-06-30 16:23 | Don Cragun | Resolution | Open => Accepted |
| 2016-06-30 16:23 | Don Cragun | Tag Attached: issue8 | |
| 2016-06-30 16:35 | joerg | Note Added: 0003278 | |
| 2016-07-01 08:39 | geoffclare | Note Added: 0003280 | |
| 2016-07-05 09:48 | joerg | Note Added: 0003286 | |
| 2016-07-05 10:07 | geoffclare | Note Added: 0003287 | |
| 2016-07-07 02:17 | nick | Note Added: 0003288 | |
| 2016-07-07 02:18 | nick | Note Edited: 0003288 | |
| 2016-07-07 11:59 | joerg | Note Added: 0003289 | |
| 2016-07-07 11:59 | joerg | Note Edited: 0003289 | |
| 2016-07-07 14:50 | geoffclare | Note Added: 0003290 | |
| 2020-04-08 15:37 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:02 | agadmin | Status | Applied => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
