View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001168 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2017-10-31 17:05 | 2019-02-04 16:14 |
| Reporter | nico | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Error |
| Status | Closed | Resolution | Rejected | ||
| Name | Nicolas Williams | ||||
| Organization | Cryptonector LLC | ||||
| User Reference | |||||
| Section | 2.14 | ||||
| Page Number | 2358 | ||||
| Line Number | 74545-74548 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0001168: Issue #537 wrongly decided | ||||
| Description | Issue #537 was wrongly decided. That sub-shells and functions do not introduce a new dynamic context where errexit is re-enabled (if it had been enabled prior to a conditional expression in which the subshell or function is being evaluated with errexit disabled) is a disaster. Merely documenting this is certainly better than nothing. But adding a new errexit2 that does the right thing would be much better. | ||||
| Desired Action | Add errexit2 or errexitnesting (or pick a better name) that has nesting semantics. | ||||
| Tags | No tags attached. | ||||
|
|
Dave Korn is reported in http://austingroupbugs.net/view.php?id=537#c1135 to have replied "[i]f this feature is really needed, which I doubt, ...". Well, this feature is very much needed. Without it one has to never count on errexit being enabled in functions, instead checking every command. Bad: set -e f () { do_something; do_something_else; } if f; then ...; else ...; fi Good: f () { if do_comething; then true; else return $?; fi; if do_something_else; then true; else return $?; fi; } if f; then ...; else ...; fi This style is precisely what set -e is about avoiding! Why even have set -e if it cannot be safely used as intended? I understand that existing shells all implement the same behavior for set -e. There may well be shell scripts that intentionally depend on current errexit semantics (although it seems unlikely). Therefore a new option may be needed. But not having any way to obtain nesting errexit behavior is bad because current errexit semantics are a terrible footgun: many users will not realize that set -e does not do what they think it must. |
|
|
Please note the requirements for new material in Austin SD/6 (https://opengroup.org/austin/docs/austin_sd6.txt): =============================================================================== New Work Items From time to time, a defect report may propose new work items that are outside the scope of maintenance of the Austin Group specifications. This section addresses how these are handled. The Austin Group is not a development body for new material apart from integration issues arising from the merger of the approved standards that were the Base documents into the revision. The Austin Group expects to take a similar approach for a future revision. Thus if a defect report raises the possibility of new interfaces for inclusion, the standard response will be that it is out of scope for either a TC or Interpretation, and that if the new material were to meet the some criteria it may be considered for inclusion in a future revision subject to the agreed scope determined at that time, although there is no guarantee. The recommended criteria for development of new interfaces to enable them to be considered for inclusion in a future revision are as follows: 1.There must be a written specification that has undergone a formal consensus based approval process and is suitable for inclusion. Parties interested in submitting new work items through one of the three organizations within the Austin Group (The Open Group, IEEE, ISO/IEC) should contact the appropriate Organizational Representative for further information and advice on how each organization handles new work items. Submissions from other organizations will also be considered. Items 2 through 4 below apply to all submissions regardless of origin. 2.There must be an implementation, preferably a reference implementation. 3.The specification must be "sponsored" by one of three organizations (The Open Group, IEEE, ISO/IEC) within the Austin Group, i.e. they would support and champion its inclusion. 4.Submitters must provide an outline plan of the editing instructions to merge the document with the Austin Group specifications, and assistance to the Austin Group editors as required to complete the merger. For an example, see https://collaboration.opengroup.org/platform/single_unix_specification/protected/mailarch.php?soph=N&action=show&archive=austin-group-l&num=434 [^] or https://collaboration.opengroup.org/sophocles/mailarch.php?soph=Y&action=show&archive=austin-group-l&num=434 [^] ============================================================================== This proposal does not meet any of the requirements of that document. There is no written specification. There is no implementation that you have made us aware of. There is no sponsor organization. There are no editing instructions. Please ensure that ALL of these criteria are met (or at very least 3 out of 4!). An implementation is the most important of these. |
|
|
0000537:0001168 states "Without existing implementation practice, this group is unwilling to invent a new requirement. As noted in 0000537:0001135 and 0000537:0001138, authors of existing compliant shells are reluctant to add this feature." This has not changed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-10-31 17:05 | nico | New Issue | |
| 2017-10-31 17:05 | nico | Status | New => Under Review |
| 2017-10-31 17:05 | nico | Assigned To | => ajosey |
| 2017-10-31 17:05 | nico | Name | => Nicolas Williams |
| 2017-10-31 17:05 | nico | Organization | => Cryptonector LLC |
| 2017-10-31 17:05 | nico | Section | => 2.14 |
| 2017-10-31 17:05 | nico | Page Number | => 2358 |
| 2017-10-31 17:05 | nico | Line Number | => 74545-74548 |
| 2017-10-31 17:13 | nico | Note Added: 0003877 | |
| 2017-10-31 18:33 | nick | Note Added: 0003878 | |
| 2017-10-31 18:43 | nick | Note Edited: 0003878 | |
| 2019-02-04 16:07 | nick | Relationship added | child of 0000537 |
| 2019-02-04 16:13 | nick | Note Added: 0004239 | |
| 2019-02-04 16:13 | nick | Note Edited: 0004239 | |
| 2019-02-04 16:14 | nick | Note Edited: 0004239 | |
| 2019-02-04 16:14 | nick | Interp Status | => --- |
| 2019-02-04 16:14 | nick | Status | Under Review => Closed |
| 2019-02-04 16:14 | nick | Resolution | Open => Rejected |
