View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000367 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2011-01-06 23:30 | 2024-06-11 08:53 |
| 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.readonly | ||||
| Section | readonly | ||||
| Page Number | 2352 | ||||
| Line Number | 74359 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000367:0000675 | ||||
| Summary | 0000367: interaction between readonly, export, getopts, and read | ||||
| Description | It was pointed out on the bash list that bash silently ignores failure to modify a variable when using the read utility with a variable marked readonly, and that this should be treated as an error because it is a form of data loss. However, the existing wording for readonly only talks about interactions with unset, rather than covering all standard utilities that can modify variables in the current environment. http://lists.gnu.org/archive/html/bug-bash/2011-01/msg00007.html http://lists.gnu.org/archive/html/bug-bash/2011-01/msg00011.html In fact, it is provable that several shells diagnose failure to modify a readonly variable while using export by terminating a non-interactive shell: $ ksh -c 'readonly foo; export foo=a; echo $?' || echo aborted, $? ksh: line 1: foo: is read only aborted, 1 $ bash --posix -c 'readonly foo; export foo=a; echo $?' || echo aborted, $? bash: foo: readonly variable aborted, 1 $ bash -c 'readonly foo; export foo=a; echo $?' || echo aborting with $? bash: foo: readonly variable 1 Furthermore, in discussing the issue, David Korn pointed out (off-list) that the current getopts and read specifications are ambiguous between normal end of options/input and an error: "How does a script check that all options have been parsed correctly. while getopts... do ... done will terminate when a readonly variable is assigned making it appear as if all options were properly accounted for even though they have not been?" This is easy enough to fix by reserving exit status 1 for normal end of options and requiring errors to be > 1, although it doesn't necessarily agree with existing practice. I've gone ahead and made that change in my desired action, although it may require some group consensus on whether it represents a separate issue worth splitting into two bugs for different resolution schedules. There is at least one other utility that modifies a variable in the current shell environment, but I have no idea whether 'cd /tmp; readonly PWD; cd ..' should fail at the readonly phase (we already document that an implementation may reject attempts to change PWD outside of cd, and this use of readonly is roughly such an attempt), or at the cd .. phase (with the directory unchanged, because PWD cannot be altered to reflect success), or silently ignored (at which point we're back to the issue of PWD getting out of sync, raised earlier in 0000240 and 0000253). | ||||
| Desired Action | At line 74359 [XCU 2.14 readonly DESCRIPTION], change The values of variables with the readonly attribute cannot be changed by subsequent assignment, nor can those variables be unset by the unset utility. to The values of variables with the readonly attribute cannot be changed by subsequent assignment or use of the export, getopts, or read utilities, nor can those variables be unset by the unset utility. At line 74312 [XCU export EXIT STATUS], change "Zero." to 0 Successful completion. >0 An attempt was made to modify a readonly variable using a name=word operand. At line 90587 [XCU getopts DESCRIPTION], change "a return value greater than zero" to "a return value of one". At line 90595 [XCU getopts DESCRIPTION], add a sentence: An error in setting any of these variables (such as if var has previously been marked readonly) shall be considered an error of getopts processing, and shall result in a return value greater than one. At line 90671 [XCU getopts EXIT STATUS], change >0 The end of options was encountered or an error occurred. to 1 The end of options was encountered. >1 An error occurred. At line 103927 [XCU read DESCRIPTION], prior to "If it is called", insert a sentence: An error in setting any variable (such as if a var has previously been marked readonly) shall be considered an error of read processing, and shall result in a return value greater than one. At line 103977 [XCU read EXIT STATUS], change >0 End-of-file was detected or an error occurred. to 1 End-of-file was detected. >1 An error occurred. | ||||
| Tags | issue8 | ||||
| related to | 0001629 | Closed | 1003.1(2016/18)/Issue7+TC2 | Shell vs. read(2) errors on the script |
|
|
Line 74396 [XCU readonly EXIT STATUS] needs the same treatment as export, since ksh and bash agree that 'readonly v; readonly v=a; echo $?' aborts the shell. |
|
|
A further change related to 0000367:0000645 is that the first change in the desired action (line 74359) should say "export, getopts, read or readonly". The issue with PWD also affects OLDPWD, OPTIND, OPTARG and LINENO. Bizarrely, the readonly EXAMPLES section has PWD as one of the variables. |
|
|
Before line 5501 [XBD 8.1 Environment Variable Definition], add the following paragraphs: Additionally, a subset of the above variables are manipulated by shell built-in utilities outside of shell assignments. If an attempt is made to mark any of the following variables as readonly, then either the readonly command shall reject the attempt, or readonly shall succeed but the shell can still modify the variables outside of assignment context, or readonly shall succeed but use of a shell built-in that would otherwise modify such a variable shall fail. LINENO PWD OLDPWD OPTARG OPTIND Implementations may provide an implementation-defined set of additional variables which are manipulated by implementation-specific built-in utilities not defined in this standard. The readonly utility shall not reject marking these additional variables as readonly, but when marked readonly, those extension utilities shall either continue to modify the variables, or shall fail because the variable is readonly. None of the variables defined by this standard shall be in this implementation-defined set. At line 74359 [XCU 2.14 readonly DESCRIPTION], change The values of variables with the readonly attribute cannot be changed by subsequent assignment, nor can those variables be unset by the unset utility. to The values of variables with the readonly attribute cannot be changed by subsequent assignment or use of the export, getopts, readonly, or read utilities, nor can those variables be unset by the unset utility. As described in <reference to XBD 8.1>, conforming applications shall not request to mark a variable as readonly if it is documented as being manipulated by a shell built-in utility, as it may render those utilities unable to complete successfully. At line 74396 [XCU readonly EXIT STATUS], change "Zero." to 0 Successful completion. >0 An error occurred, such as an attempt to modify a readonly variable using a name=word operand. At line 74402 [XCU readonly EXAMPLES], change: readonly HOME PWD to: readonly HOME At line 74413 [XCU readonly RATIONALE], add a paragraph: Attempts to set the readonly attribute on certain variables, such as PWD, may have surprising results. Either readonly will reject the attempt, or the attempt will succeed but the shell will continue to alter the contents of PWD during the cd utility, or the attempt will succeed and render the cd utility inoperative (since it must not change directories if it cannot also update PWD). At line 74312 [XCU export EXIT STATUS], change "Zero." to 0 Successful completion. >0 An error occurred, such as an attempt to modify a readonly variable using a name=word operand. At line 90587 [XCU getopts DESCRIPTION], change "a return value greater than zero" to "a return value of one". At line 90595 [XCU getopts DESCRIPTION], add a sentence: An error in setting any of these variables (such as if var has previously been marked readonly) shall be considered an error of getopts processing, and shall result in a return value greater than one. At line 90671 [XCU getopts EXIT STATUS], change >0 The end of options was encountered or an error occurred. to 1 The end of options was encountered. >1 An error occurred. At line 103927 [XCU read DESCRIPTION], prior to "If it is called", insert a sentence: An error in setting any variable (such as if a var has previously been marked readonly) shall be considered an error of read processing, and shall result in a return value greater than one. At line 103977 [XCU read EXIT STATUS], change >0 End-of-file was detected or an error occurred. to 1 End-of-file was detected. >1 An error occurred. |
|
|
Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- The interaction between the readonly status and the built-ins that use read only variables needs to be documented. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes noted in 0000367:0000673 |
|
|
Interpretation proposed 15 Mar 2011 for final 30 day review |
|
|
The interpretation is now approved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-01-06 23:30 | eblake | New Issue | |
| 2011-01-06 23:30 | eblake | Status | New => Under Review |
| 2011-01-06 23:30 | eblake | Assigned To | => ajosey |
| 2011-01-06 23:30 | eblake | Name | => Eric Blake |
| 2011-01-06 23:30 | eblake | Organization | => Red Hat |
| 2011-01-06 23:30 | eblake | User Reference | => ebb.readonly |
| 2011-01-06 23:30 | eblake | Section | => readonly |
| 2011-01-06 23:30 | eblake | Page Number | => 2352 |
| 2011-01-06 23:30 | eblake | Line Number | => 74359 |
| 2011-01-06 23:30 | eblake | Interp Status | => --- |
| 2011-01-07 00:26 | eblake | Note Added: 0000645 | |
| 2011-01-07 17:15 | geoffclare | Note Added: 0000646 | |
| 2011-02-10 16:05 | eblake | Note Added: 0000673 | |
| 2011-02-17 17:04 | eblake | Note Edited: 0000673 | |
| 2011-02-17 17:10 | eblake | Note Edited: 0000673 | |
| 2011-02-17 17:14 | Don Cragun | Note Added: 0000675 | |
| 2011-02-17 17:15 | Don Cragun | Interp Status | --- => Pending |
| 2011-02-17 17:15 | Don Cragun | Final Accepted Text | => See 0000367:0000675 |
| 2011-02-17 17:15 | Don Cragun | Status | Under Review => Interpretation Required |
| 2011-02-17 17:15 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2011-02-17 17:16 | Don Cragun | Tag Attached: issue8 | |
| 2011-03-15 14:45 | ajosey | Interp Status | Pending => Proposed |
| 2011-03-15 14:45 | ajosey | Note Added: 0000703 | |
| 2011-04-26 15:10 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-26 15:10 | ajosey | Note Added: 0000766 | |
| 2020-02-14 15:16 | geoffclare | Status | Interpretation Required => Applied |
| 2023-01-30 16:45 | nick | Relationship added | related to 0001629 |
| 2024-06-11 08:53 | agadmin | Status | Applied => Closed |
