View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000559 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2012-04-26 17:17 | 2024-06-11 08:52 |
Reporter | eblake | Assigned To | ajosey | ||
Priority | normal | Severity | Objection | Type | Omission |
Status | Closed | Resolution | Accepted As Marked | ||
Name | Eric Blake | ||||
Organization | Red Hat | ||||
User Reference | ebb.arithmetic_expansion | ||||
Section | 2.6.4 | ||||
Page Number | 2310 | ||||
Line Number | 72861 | ||||
Interp Status | Approved | ||||
Final Accepted Text | 0000559:0001238 | ||||
Summary | 0000559: arithmetic expansion should honor 'set -u' | ||||
Description | The standard is silent on whether 'set -u' affects arithmetic expansion that parses an unset shell variable name. Besides, if 'x' is unset, it seems odd for 'echo $((x))' to succeed where 'echo $(($x))' fails, especially since the standard requires the two constructs to behave identically when 'x' is set to an integral value. Since the behavior of arithmetic expansion in the shell was modeled after ksh behavior, where set -u has an impact, this proposal adds that requirement. On the other hand, while at least ksh and bash error out, my testing showed that dash and zsh currently do not flag an error; forcing the requirement would require these implementations to change, so the group may instead choose to go with a solution that allows both behaviors. | ||||
Desired Action | At line 72681, after: If the shell variable x contains a value that forms a valid integer constant, then the arithmetic expansions "$((x))" and "$(($x))" shall return the same value. add a sentence: If set -u is in effect, any unset parameter in the resulting arithmetic expression shall cause the expansion to fail. | ||||
Tags | issue8 |
|
The proposed wording is too vague: it could be interpreted as applying to assignments of unset variables, e.g. $((unsetvar = setvar+1)) Also, in TC1 the description of the set -u option includes details that should apply to this case, such as "it [the shell] shall write a message to standard error and shall not execute the command containing the expansion, but for the purposes of setting the '?' special parameter and the exit status of the shell the command shall be treated as having been executed and returned an exit status of between 1 and 125 inclusive." The proposed change bypasses this by separately specifying that the effect of -u on arithmetic expansion is to "cause the expansion to fail". I suggest that instead of making a change in 2.6.4 we should update the description of set -u so that it begins: When the shell tries to expand, in a parameter expansion or an arithmetic expansion, an unset parameter other than the '@' and '*' special parameters, it shall write ... |
|
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 2359 line 74590 section set, after applying change number XCU/TC1/2008/0047 from TC1, change: When the shell tries to expand an unset parameter other than the '@' and '*' special parameters, it shall write to: When the shell tries to expand, in a parameter expansion or an arithmetic expansion, an unset parameter other than the '@' and '*' special parameters, it shall write |
|
Interpretation proposed 29 June 2012 for final 45 day review |
|
Interpretation approved 30 Aug 2012 |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-04-26 17:17 | eblake | New Issue | |
2012-04-26 17:17 | eblake | Status | New => Under Review |
2012-04-26 17:17 | eblake | Assigned To | => ajosey |
2012-04-26 17:17 | eblake | Name | => Eric Blake |
2012-04-26 17:17 | eblake | Organization | => Red Hat |
2012-04-26 17:17 | eblake | User Reference | => ebb.arithmetic_expansion |
2012-04-26 17:17 | eblake | Section | => 2.6.4 |
2012-04-26 17:17 | eblake | Page Number | => 2310 |
2012-04-26 17:17 | eblake | Line Number | => 72861 |
2012-04-26 17:17 | eblake | Interp Status | => --- |
2012-04-26 17:18 | eblake | Relationship added | related to 0000155 |
2012-04-26 17:19 | eblake | Description Updated | |
2012-04-27 08:20 | geoffclare | Note Added: 0001212 | |
2012-05-10 15:25 | geoffclare | Note Added: 0001238 | |
2012-05-10 15:26 | geoffclare | Interp Status | --- => Pending |
2012-05-10 15:26 | geoffclare | Final Accepted Text | => 0000559:0001238 |
2012-05-10 15:26 | geoffclare | Status | Under Review => Interpretation Required |
2012-05-10 15:26 | geoffclare | Resolution | Open => Accepted As Marked |
2012-05-10 15:26 | geoffclare | Tag Attached: issue8 | |
2012-05-11 08:09 | geoffclare | Relationship added | related to 0000280 |
2012-06-29 16:15 | ajosey | Interp Status | Pending => Proposed |
2012-06-29 16:15 | ajosey | Note Added: 0001288 | |
2012-08-30 09:13 | ajosey | Interp Status | Proposed => Approved |
2012-08-30 09:13 | ajosey | Note Added: 0001351 | |
2020-03-20 09:29 | geoffclare | Status | Interpretation Required => Applied |
2024-06-11 08:52 | agadmin | Status | Applied => Closed |