Austin Group Defect Tracker

Aardvark Mark IV

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
0001168 [1003.1(2008)/Issue 7] Shell and Utilities Editorial Error 2017-10-31 17:05 2019-02-04 16:14
Reporter nico View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
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.
Attached Files

- Relationships
child of 0000537Closedajosey for set -e, compound commands and functions case should be clarified 

-  Notes
(0003877)
nico (reporter)
2017-10-31 17:13

 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.
(0003878)
nick (manager)
2017-10-31 18:33
edited on: 2017-10-31 18:43

 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.
(0004239)
nick (manager)
2019-02-04 16:13
edited on: 2019-02-04 16:14

 Note: 0001168 states "Without existing implementation practice, this group is unwilling to invent a new requirement. As noted in Note: 0001135 and Note: 0001138, authors of existing compliant shells are reluctant to add this feature." This has not changed.

- Issue History
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 17:14 nico Issue Monitored: nico
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

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