Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001806 [Issue 8 drafts] Shell and Utilities Editorial Clarification Requested 2024-02-02 22:53 2024-02-13 22:55
Reporter calestyo View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version Draft 4
Name Christoph Anton Mitterer
User Reference
Section Shell Command Language
Page Number 2571
Line Number 83916, ff.
Final Accepted Text
Summary 0001806: ambiguous description of which attribtes `unset` unsets in case of readonly attribute being set
Description Hey.

Lines 83916 to 83918 say:
> The unset utility shall unset each variable or function
> definition specified by name that does not have the
> readonly attribute and remove any attributes other than
> readonly that have been given to name (see Section 2.15
> export and readonly).

I'd interpret this as:

- Unless readonly is set, it unsets the variable/value (clearly).

- But IMO it's not absolutely clear what it does to attributes:
  "and remove any attributes other than readonly"
  would strictly speaking mean:
  - it does not unset readonly
  - it DOES unset any other attributes (i.e. export)

Those shells that I could test, behaved how one would expect, i.e. once readonly is set, unset cannot modify the variable (neither it's value, nor ANY of its attributes).

Desired Action If the above assumption is correct, then:

Change lines 83916 to 83918 to:

The unset utility shall unset each variable or function definition specified by name that does not have the readonly attribute. If name is unset it shall further remove any attributes that have been given to it (see Section 2.15 export and readonly), unless it has the readonly attribute.

The subclause ", unless it has the readonly attribute" could in principle also be omitted, but makes it perhaps clearer.


btw: There is no specification, whether unset shall continue trying with further names, if one readonly is encountered.
Not sure if that's left open by intention.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
larryv (reporter)
2024-02-03 00:30

You may want to read 0001075 for some of the thinking behind the current wording.
mirabilos (reporter)
2024-02-13 20:10

Huh, this looks indeed like a bug introduced by 1075.

Specifically, the comment by joerg, which I read as “the bourne shell first checks if the variable is readonly; if so, it errors; if not, it unsets the content and removes all attributes”, and which corresponds to my reading, was misinterpreted.

And when I start a jsh to test it, I get…

$ foo=bar
$ export foo
$ env | grep foo
$ readonly foo
$ env | grep foo
$ unset foo; echo $?
foo: is read only
$ echo $?
$ env | grep foo

… which supports my reading, and calestyo’s expected behaviour.
mirabilos (reporter)
2024-02-13 20:25

How about something like this (I *think* there are no possible
other causes of “could not be unset” than it being readonly any


Each variable or function specified by name that does not have the
readonly attribute (see Section 2.15 export and readonly) shall be
unset and have all of its attributes removed.

If -v is specified, name refers to a variable name and the shell
shall unset it and remove it from the environment.

If -f is specified, name refers to a function and the shell shall
unset the function definition.

If neither -f nor -v is specified, name refers to a variable; if
a variable by that name does not exist, it is unspecified whether
a function by that name, if any, shall be unset.

Unsetting a variable or function that was not previously set shall
not be considered an error and does not cause the shell to abort.



    0 All name operands were successfully unset or not set.
   >0 At least one name was readonly and could not be unset.
calestyo (reporter)
2024-02-13 22:48

Well, from a recent curiosity I've had brought up on help-bash, and where I personally would have thought that the wording/intention and thus order of respectively context in which things should be made was rather clear, I learned again that wordings may be interpreted quite differently and unless something is most definitely specified, people will interpret it to their likings (which of course includes myself).

So I think whatever we write in the end, it should be 100% clear what happens:

- unsetting means: (trying) to unset an already set variable with or without attributes as well as trying to unset a not set variable which has however attributes

- No error, unless the unsetting fails for which ever reason (like the attribute readonly being set or an invalid identifier being used) especially not in the case when it's tried to unset a variable (with a valid identifier) that is not set, regardless of whether or not it has attributes (other than readonly) set

- Once the readonly attribute readonly is set, the set state of the variable, its value and all of it's attributes are no more changeable. This implies, that unsetting such variable would in no way change it (including none of it's attributes), but also that one cannot e.g. first set the readonly attribute on an unset variable, and later on set it once.

I think the latter is not really 100% clear by the current wording of the readonly built-in, which says:
"The values of variables with the readonly attribute cannot be changed by subsequent assignment, nor can those variables be unset by the unset utility."
=> IMO that "change value" could be interpreted as "it only affects variables which have a value / are set, because if the variable is not yet set (but has already the readonly attriute, setting it then, doesn't really change the value, or does it?

- Not sure whether the standard should say anything with respect to "local" variables (which it does not cover). Can one "re-define" a readonly variable at a local scope? Should that left be an implementation decision, or would allowing that already break the intentions behind readonly?

- What happens if unset fails for one variable. Will it still try the others before it returns non-zero? Is that unspecified?
calestyo (reporter)
2024-02-13 22:55

And I just noticed: The last case could in principle also be: if it would fail for at least one variable, none are unset.

- Issue History
Date Modified Username Field Change
2024-02-02 22:53 calestyo New Issue
2024-02-02 22:53 calestyo Name => Christoph Anton Mitterer
2024-02-02 22:53 calestyo Section => Shell Command Language
2024-02-02 22:53 calestyo Page Number => 2571
2024-02-02 22:53 calestyo Line Number => 83916, ff.
2024-02-03 00:30 larryv Note Added: 0006647
2024-02-13 20:10 mirabilos Note Added: 0006653
2024-02-13 20:25 mirabilos Note Added: 0006654
2024-02-13 22:48 calestyo Note Added: 0006655
2024-02-13 22:55 calestyo Note Added: 0006656

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