On Thu, May 26, 2022, at 10:39 PM, Christoph Anton Mitterer via austin-group-l 
at The Open Group wrote:
> 2) The draft 2.1 says on page 2398 line 77766:
>
>    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.14 export and readonly).
>
> To me that behaviour would seem quite odd ... and it doesn't match the
> behaviour of at least bash and dash.
>
>
> What the text currently says is:
> `unset` unsets each var/function that is not readonly...
> AND (with no further restriction)
> removes all attributes other then readonly
> (that is: whether or not the var is readonly).
>
> So that means:
>    export var=foo
>    readonly var
>    unset -v var
> as per description, should leave var set (with value "foo"), should
> leave the readonly attribute... but should remove the export attribute.

Seems that ksh93u+, mksh R59c, and yash 2.52 don't follow this
interpretation either.


> 3) It's IMO not fully clear whether a readonly variable is allowed to
> have other attributes added (or cleared - see (2)).
>
> On page 2376, line 76926 says:
>    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.
>   
> and in fact, it seems to work with bash/dash to first mark a var
> readonly (whether it's set or not) and then mark it as export.
>
> But still, given that the other way round seems to not work... it could
> IMO deserve further clarification... and maybe emphasis, too, as
> allowing to add further attributes is actually a bit contradicting the
> read-only property, as it may change the behaviour.

At a minimum, bash 5.1.16, ksh93u+, mksh R59c, dash 0.5.11.5, and
yash 2.52 already allow exporting an existing readonly variable.
If the standard ought to clarify anything, it's that the results
of this action are unspecified.


-- 
vq

  • shell variab... Christoph Anton Mitterer via austin-group-l at The Open Group
    • Re: she... Lawrence Velázquez via austin-group-l at The Open Group

Reply via email to