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
0000367 [1003.1(2008)/Issue 7] Shell and Utilities Objection Omission 2011-01-06 23:30 2024-06-11 08:53
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
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 Note: 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
Attached Files

- Relationships
related to 0001629Closed 1003.1(2016/18)/Issue7+TC2 Shell vs. read(2) errors on the script 

-  Notes
(0000645)
eblake (manager)
2011-01-07 00:26

 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.
(0000646)
geoffclare (manager)
2011-01-07 17:15

 A further change related to Note: 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.
(0000673)
eblake (manager)
2011-02-10 16:05
edited on: 2011-02-17 17:10

 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.
(0000675)
Don Cragun (manager)
2011-02-17 17:14

 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 Note: 0000673
(0000703)
ajosey (manager)
2011-03-15 14:45

 Interpretation proposed 15 Mar 2011 for final 30 day review
(0000766)
ajosey (manager)
2011-04-26 15:10

 The interpretation is now approved.

- Issue History
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 Note: 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

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