f() { local -ar path=(/bin); };f gives an error

f() { local -ar path=(/bin); };f gives an error

[Stephane Chazelas]

FYI,

someone reported this on unix.stackexchange.com:
https://unix.stackexchange.com/questions/407125/why-cant-i-define-a-readonly-variable-named-path-in-zsh

Which looks like a bug:

$ zsh -c 'f() { local -ar path=(/bin); }; f'
f: read-only variable: path
$ /zsh --version
zsh 5.4.2-dev-0 (x86_64-unknown-linux-gnu)

See also the answer there by someone would did some investigation already.

-- 
Stephane

Re: f() { local -ar path=(/bin); };f gives an error

[Eric Cook]

On 11/26/2017 06:21 PM, Stephane Chazelas wrote:
> FYI,
> 
> someone reported this on unix.stackexchange.com:
> https://unix.stackexchange.com/questions/407125/why-cant-i-define-a-readonly-variable-named-path-in-zsh
> 
> Which looks like a bug:
> 
> $ zsh -c 'f() { local -ar path=(/bin); }; f'
> f: read-only variable: path
> $ /zsh --version
> zsh 5.4.2-dev-0 (x86_64-unknown-linux-gnu)
> 
> See also the answer there by someone would did some investigation already.
> 
() { local -har path=(/foo); typeset -p path }
typeset -ar path=( /foo )

-h     Hide: only useful for special  parameters  (those  marked
       `<S>' in the table in zshparam(1)), and for local parame‐
       ters with the same name as a  special  parameter...

Re: f() { local -ar path=(/bin); };f gives an error

[Stephane Chazelas]

2017-11-26 18:28:17 -0500, Eric Cook:
> On 11/26/2017 06:21 PM, Stephane Chazelas wrote:
> > FYI,
> > 
> > someone reported this on unix.stackexchange.com:
> > https://unix.stackexchange.com/questions/407125/why-cant-i-define-a-readonly-variable-named-path-in-zsh
> > 
> > Which looks like a bug:
> > 
> > $ zsh -c 'f() { local -ar path=(/bin); }; f'
> > f: read-only variable: path
> > $ /zsh --version
> > zsh 5.4.2-dev-0 (x86_64-unknown-linux-gnu)
> > 
> > See also the answer there by someone would did some investigation already.
> > 
> () { local -har path=(/foo); typeset -p path }
> typeset -ar path=( /foo )
> 
> -h     Hide: only useful for special  parameters  (those  marked
>        `<S>' in the table in zshparam(1)), and for local parame‐
>        ters with the same name as a  special  parameter...

Thanks.

But that creates a non-special local "path" variable.

The issue here is that when you're trying to make $path (the
special array variable tied to $PATH) readonly (with a value)
locally in a function, that doesn't work.

it also doesn't work with the scalar variant:

() { local -r PATH=/foo; }

same goes with the $cdpath/$CDPATH variable.

-- 
Stephane

Re: f() { local -ar path=(/bin); };f gives an error

[Eric Cook]

On 11/27/2017 03:17 PM, Stephane Chazelas wrote:
> 
> Thanks.
> 
> But that creates a non-special local "path" variable.
> 
> The issue here is that when you're trying to make $path (the
> special array variable tied to $PATH) readonly (with a value)
> locally in a function, that doesn't work.
> 

That wasn't really asked by your original link. While not common, people do
ask in #zsh why after attempting to use an local (non-readonly)
variable named path to reference an filename or something, they can no longer
execute commands. Using typeset's -h option to hide the special attribute allows
them to do so, so setting it `42' like in the stackexchange link would work
without breaking other stuff.

But to actually allow what you are now asking, I'll defer to someone else.

Re: f() { local -ar path=(/bin); };f gives an error

[Bart Schaefer]

> On 11/27/2017 03:17 PM, Stephane Chazelas wrote:
>>
>> The issue here is that when you're trying to make $path (the
>> special array variable tied to $PATH) readonly (with a value)
>> locally in a function, that doesn't work.

Something a little weird happens with order-of-operations for tied parameters:

f() { local -ar path; PATH=foo; echo $path }

Note there's no error there, $path is changed by the assignment to
$PATH even though the array is read-only.  The reverse also works; you
have to make both parameters read-only to prevent changing either one
by assignment to the other.

f() { path=(/bin); local -r path PATH; ... }  # achieves the desired effect

Re: f() { local -ar path=(/bin); };f gives an error

[Bart Schaefer]

On Mon, Nov 27, 2017 at 1:34 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> f() { path=(/bin); local -r path PATH; ... }  # achieves the desired effect

Of course there's a missing "local" before the first assignment there.
Sorry about that.

Re: f() { local -ar path=(/bin); };f gives an error

[Stephane Chazelas]

2017-11-27 13:34:05 -0800, Bart Schaefer:
> > On 11/27/2017 03:17 PM, Stephane Chazelas wrote:
> >>
> >> The issue here is that when you're trying to make $path (the
> >> special array variable tied to $PATH) readonly (with a value)
> >> locally in a function, that doesn't work.
> 
> Something a little weird happens with order-of-operations for tied parameters:
> 
> f() { local -ar path; PATH=foo; echo $path }
> 
> Note there's no error there, $path is changed by the assignment to
> $PATH even though the array is read-only.  The reverse also works; you
> have to make both parameters read-only to prevent changing either one
> by assignment to the other.
> 
> f() { path=(/bin); local -r path PATH; ... }  # achieves the desired effect

Wouldn't we want to propagate the "readonly" attribute to the
"tied" variable when the other one is made "readonly"?

There are other combinations that don't work so well like:

$ zsh -c 'typeset -Z3 -T A a; a=1; echo $A'
001
$ zsh -c 'typeset -T A a; typeset -Z3 A; a=(2 3); echo $a'
2 3
$ zsh -c 'typeset -T A a; typeset -Z3 A; A=1; echo $a'
1

-U is OK (often used with $PATH).

Would be worth going through all the combinations that one may
want to use and clarify which ones are legal which ones are not.

Having typeset return an error when two exclusive options are
used together (like typeset -iT (documented), typeset -ai (not))
would be helpful.

(why not allowing -i/-F/-Z... and most other scalar flags for
arrays and hashes btw?)

-- 
Stephane.