new user questions and issues

new user questions and issues

[Kannan Varadhan]

[-- Attachment #1: Type: text/plain, Size: 10816 bytes --]

Been a long time user of ksh, switching to try zsh.
My version:

~ 1% uname -a                                                           0:26:57
Darwin KVARADHA-M-40SH 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
~ 2% echo $ZSH_VERSION                                                  0:26:59
5.0.5
~ 3% echo $ZSH_PATCHLEVEL                                               0:27:18
zsh-5.0.5-0-g79abe00
~ 4%                                                                    0:27:23



Four Issues in this one email, sorry:
Issue #1:  Programmatic Scripting, how to?
Issue #2.  Overridden local variables get echoed?
Issue #3.  Typeset -U from within a nested function behaves unpredictably (1)
Issue #4.  Typeset -U from within a nested function really seems to get ignored (2)

Details below.  Wondering if these are known, and how to either report or address.

Thanks,

Kannan


Issue #1:  Programmatic Scripting, how to?

I would like to do the following:

for var in path infopath manpath cdpath ; do
    typeset -agU $var
    local capsvar
    capsvar=$(echo $var | tr 'a-z' 'A-Z')
    $var=( $(echo ${$capsvar} | sed 's/:/ /g') )
done

But this does not work, because ${$capsvar}  gets me a zsh: bad substitution.
Is there any way to achieve this in zsh?

Issue #2.  Overridden local variables get echoed?

~ 5% cat lib/zsh/test2                                                  9:55:52
function test2 
    print why is the previous value echoed when a local variable is 'overridden?'

    local _t2
    for _t2 in 0 1 2 ; do
        local _t3
        _t3=XXX__${_t2}__
    done
}
set -x
~ 6% autoload test2                                                     9:55:55
~ 7% test2                                                                                                                     9:56:01
+test2:1> print why is the previous value echoed when a local variable is 'overridden?'
why is the previous value echoed when a local variable is overridden?
+test2:3> local _t2
+test2:4> _t2=0
+test2:5> local _t3
+test2:6> _t3=XXX__0__
+test2:4> _t2=1
+test2:5> local _t3
_t3=XXX__0__
+test2:6> _t3=XXX__1__
+test2:4> _t2=2
+test2:5> local _t3
_t3=XXX__1__
+test2:6> _t3=XXX__2__
~ 8%                                                                    9:56:03

Issue #3.  Typeset -U from within a nested function behaves unpredictably (1)
Consider the following two functions: ap and _ap.

~ 1% cat lib/zsh/ap lib/zsh/_ap                                        10:11:21
function ap {
    local _api
    for _api in "$@" ; do
        _ap "" PATH      $_api/bin $_api/sbin
    done
}
autoload _ap
function _ap {
    local _shift _envar _enval _i
    _shift=$1 ; shift
    _envar=$1 ; shift
    : '***' EXPECT FULL PATH VARIABLE BELOW '***'
    _enval=$(eval echo \$$_envar)
}
# guarantee uniqueness
: PATH = $PATH
typeset -U PATH
~ 2%                                                                   10:11:27
~ 2%                                                                   10:11:29
~ 2% setopt KSH_AUTOLOAD                                               10:11:30
~ 3% autoload ap                                                       10:11:39
~ 4% set -x                                                            10:12:37
~ 5% ap x y                                                            10:12:39
+-zsh:7> ap x y
+ap:7> autoload _ap
+ap:1> local _api
+ap:2> _api=x
+ap:3> _ap '' PATH x/bin x/sbin
+ap:9> : PATH '=' /Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
+ap:10> typeset -U PATH
+_ap:1> local _shift _envar _enval _i
+_ap:2> _shift=''
+_ap:2> shift
+_ap:3> _envar=PATH
+_ap:3> shift
+_ap:4> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:5> _enval=+_ap:5> eval echo '$PATH'
+(eval):1> echo
+_ap:5> _enval=''
+ap:2> _api=y
+ap:3> _ap '' PATH y/bin y/sbin
+_ap:1> local _shift _envar _enval _i
+_ap:2> _shift=''
+_ap:2> shift
+_ap:3> _envar=PATH
+_ap:3> shift
+_ap:4> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:5> _enval=+_ap:5> eval echo '$PATH'
+(eval):1> echo /Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
+_ap:5> _enval=/Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
~ 6%                                                                   10:12:4

If I remove the typeset -U PATH in _ap, as:

~ 1% cat lib/zsh/_ap                                                   10:15:28
function _ap {
    local _shift _envar _enval _i
    _shift=$1 ; shift
    _envar=$1 ; shift
    : '***' EXPECT FULL PATH VARIABLE BELOW '***'
    _enval=$(eval echo \$$_envar)
}
# guarantee uniqueness
: PATH = $PATH
: typeset -U PATH
~ 2%                                                                   10:15:35
~ 2%                                                                   10:15:36
~ 2% setopt KSH_AUTOLOAD                                               10:15:36
~ 3% autoload ap                                                       10:15:40
~ 4% set -x                                                            10:15:43
~ 5% ap x y                                                            10:15:52
+-zsh:7> ap x y
+ap:7> autoload _ap
+ap:1> local _api
+ap:2> _api=x
+ap:3> _ap '' PATH x/bin x/sbin
+ap:9> : PATH '=' /Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
+ap:10> : typeset -U PATH
+_ap:1> local _shift _envar _enval _i
+_ap:2> _shift=''
+_ap:2> shift
+_ap:3> _envar=PATH
+_ap:3> shift
+_ap:4> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:5> _enval=+_ap:5> eval echo '$PATH'
+(eval):1> echo /Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
+_ap:5> _enval=/Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
+ap:2> _api=y
+ap:3> _ap '' PATH y/bin y/sbin
+_ap:1> local _shift _envar _enval _i
+_ap:2> _shift=''
+_ap:2> shift
+_ap:3> _envar=PATH
+_ap:3> shift
+_ap:4> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:5> _enval=+_ap:5> eval echo '$PATH'
+(eval):1> echo /Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
+_ap:5> _enval=/Users/kvaradha/sbin:/Users/kvaradha/bin:/opt/local/sbin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:./bin:./sbin:../bin:../sbin
~ 6%                                                                   10:15:53


Issue #4.  Typeset -U from within a nested function really seems to get ignored (2)
Consider the same two functions: ap and _ap.

~ 1% typeset -U                                                        10:30:44
~ 2% setopt KSH_AUTOLOAD                                               10:30:50
~ 3% autoload ap                                                       10:30:55
~ 4% cat lib/zsh/_ap                                                   10:30:57
function _ap {
    local _shift _envar _enval _i
    _shift=$1 ; shift
    _envar=$1 ; shift
    set -x
    for _i in "$@" ; do
        : '***' EXPECT FULL PATH VARIABLE BELOW '***'
        _enval=$(eval echo \$$_envar)
        export $_envar=$_i:$_enval
    done
    set +x
}
set -x
# guarantee uniqueness
: PATH = $PATH
typeset -U PATH
set +x
~ 5% ap x x x                                                          10:31:01
+ap:15> : PATH '=' /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+ap:16> typeset -U PATH
+ap:17> set +x
+_ap:5> _i=x/bin
+_ap:6> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:7> _enval=+_ap:7> eval echo '$PATH'
+(eval):1> echo
+_ap:7> _enval=''
+_ap:8> export 'PATH=x/bin:'
+_ap:5> _i=x/sbin
+_ap:6> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:7> _enval=+_ap:7> eval echo '$PATH'
+(eval):1> echo x/bin:
+_ap:7> _enval=x/bin:
+_ap:8> export 'PATH=x/sbin:x/bin:'
+_ap:10> set +x
+_ap:5> _i=x/bin
+_ap:6> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:7> _enval=+_ap:7> eval echo '$PATH'
+(eval):1> echo /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:7> _enval=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:8> export 'PATH=x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin'
+_ap:5> _i=x/sbin
+_ap:6> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:7> _enval=+_ap:7> eval echo '$PATH'
+(eval):1> echo x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:7> _enval=x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:8> export 'PATH=x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin'
+_ap:10> set +x
+_ap:5> _i=x/bin
+_ap:6> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:7> _enval=+_ap:7> eval echo '$PATH'
+(eval):1> echo x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:7> _enval=x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:8> export 'PATH=x/bin:x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin'
+_ap:5> _i=x/sbin
+_ap:6> : '***' EXPECT FULL PATH VARIABLE BELOW '***'
+_ap:7> _enval=+_ap:7> eval echo '$PATH'
+(eval):1> echo x/bin:x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:7> _enval=x/bin:x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
+_ap:8> export 'PATH=x/sbin:x/bin:x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin'
+_ap:10> set +x
~ 6% typeset -U                                                        10:31:12
~ 7% echo $PATH                                                        10:31:16
x/sbin:x/bin:x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
~ 8% typeset -U PATH                                                   10:31:26
~ 9% echo $PATH                                                        10:31:29
x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
~ 10% typeset -U                                                       10:31:32
PATH=x/sbin:x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
~ 11%                                                                  10:31:35

Re: new user questions and issues

[Eric Cook]

I can snipe the easier to explain ones.
On 05/06/2015 01:37 PM, Kannan Varadhan wrote:

> Issue #1:  Programmatic Scripting, how to?
> 
> I would like to do the following:
> 
> for var in path infopath manpath cdpath ; do
>     typeset -agU $var
>     local capsvar
>     capsvar=$(echo $var | tr 'a-z' 'A-Z')
>     $var=( $(echo ${$capsvar} | sed 's/:/ /g') )
> done
> 
> But this does not work, because ${$capsvar}  gets me a zsh: bad substitution.
> Is there any way to achieve this in zsh?
> 
You can use the parameter expansion flag P. ''${(P)capsvar}''

With the exception of infopath, The arrays you are trying to define are
already created and tied to the uppercase scalar parameters.
Any change made to one is reflected in the other.

echo by default interprets c string escapes, you can disable that with
the -E option.

You could avoid the command substitution with the parameter expansion
flag U ''capsvar=${(U)var}'' to change the case of the value.

$var=(...) is also an error. ''set -A $var element1 element2 ...'' will
allow you to indirectly set arrays
> Issue #2.  Overridden local variables get echoed?
> 
> ~ 5% cat lib/zsh/test2                                                  9:55:52
> function test2 
>     print why is the previous value echoed when a local variable is 'overridden?'
It actually happens when you use typeset, local, etc. on a parameter
that is already defined. You can use the option TYPESET_SILENT option to
silence it.

from the typeset section of zshbuiltins(1):
If  the  shell  option  TYPESET_SILENT  is  not  set, for each remaining
name that refers to a parameter that is set, the name and value of the
parameter are printed in the form of an assignment.  Nothing is printed
for newly-created parameters, or when any attribute flags listed below
are given along with the name.  Using `+' instead of minus to introduce
an attribute turns it off.


Pretty sure #3 and #4 is due to how typeset creates a local parameters
when used in a function. So typeset -U PATH create a new parameter
without a value, with the -U attribute.

Re: new user questions and issues

[Kannan Varadhan]

Thank you Eric.

I had worked out other ways of achieving #1, just wanted to learn if there was a good way to do it.

The others, I get.

Thanks,

Kannan

> On May 6, 2015, at 1:50 PM, Eric Cook <llua@gmx.com> wrote:
> 
> I can snipe the easier to explain ones.
> On 05/06/2015 01:37 PM, Kannan Varadhan wrote:
> 
>> Issue #1:  Programmatic Scripting, how to?
>> 
>> I would like to do the following:
>> 
>> for var in path infopath manpath cdpath ; do
>>    typeset -agU $var
>>    local capsvar
>>    capsvar=$(echo $var | tr 'a-z' 'A-Z')
>>    $var=( $(echo ${$capsvar} | sed 's/:/ /g') )
>> done
>> 
>> But this does not work, because ${$capsvar}  gets me a zsh: bad substitution.
>> Is there any way to achieve this in zsh?
>> 
> You can use the parameter expansion flag P. ''${(P)capsvar}''
> 
> With the exception of infopath, The arrays you are trying to define are
> already created and tied to the uppercase scalar parameters.
> Any change made to one is reflected in the other.
> 
> echo by default interprets c string escapes, you can disable that with
> the -E option.
> 
> You could avoid the command substitution with the parameter expansion
> flag U ''capsvar=${(U)var}'' to change the case of the value.
> 
> $var=(...) is also an error. ''set -A $var element1 element2 ...'' will
> allow you to indirectly set arrays
>> Issue #2.  Overridden local variables get echoed?
>> 
>> ~ 5% cat lib/zsh/test2                                                  9:55:52
>> function test2 
>>    print why is the previous value echoed when a local variable is 'overridden?'
> It actually happens when you use typeset, local, etc. on a parameter
> that is already defined. You can use the option TYPESET_SILENT option to
> silence it.
> 
> from the typeset section of zshbuiltins(1):
> If  the  shell  option  TYPESET_SILENT  is  not  set, for each remaining
> name that refers to a parameter that is set, the name and value of the
> parameter are printed in the form of an assignment.  Nothing is printed
> for newly-created parameters, or when any attribute flags listed below
> are given along with the name.  Using `+' instead of minus to introduce
> an attribute turns it off.
> 
> 
> Pretty sure #3 and #4 is due to how typeset creates a local parameters
> when used in a function. So typeset -U PATH create a new parameter
> without a value, with the -U attribute.

Re: new user questions and issues

[ZyX]

About local: instead of setting an option it looks like you can use

    typeset +g _t3

(`typeset +g`, `typeset` and `local` are almost equivalent, but typeset without any flags listed in documentation exhibits the same behaviour as `local`). Specifically in the example you can use

    local _t3=XXX__${_t2}__

: when there is an assignment `local` will not print previous value.



08.05.2015, 00:47, "Kannan Varadhan" <kvaradhan3@gmail.com>:
> Thank you Eric.
>
> I had worked out other ways of achieving #1, just wanted to learn if there was a good way to do it.
>
> The others, I get.
>
> Thanks,
>
> Kannan
>>  On May 6, 2015, at 1:50 PM, Eric Cook <llua@gmx.com> wrote:
>>
>>  I can snipe the easier to explain ones.
>>  On 05/06/2015 01:37 PM, Kannan Varadhan wrote:
>>>  Issue #1:  Programmatic Scripting, how to?
>>>
>>>  I would like to do the following:
>>>
>>>  for var in path infopath manpath cdpath ; do
>>>     typeset -agU $var
>>>     local capsvar
>>>     capsvar=$(echo $var | tr 'a-z' 'A-Z')
>>>     $var=( $(echo ${$capsvar} | sed 's/:/ /g') )
>>>  done
>>>
>>>  But this does not work, because ${$capsvar}  gets me a zsh: bad substitution.
>>>  Is there any way to achieve this in zsh?
>>  You can use the parameter expansion flag P. ''${(P)capsvar}''
>>
>>  With the exception of infopath, The arrays you are trying to define are
>>  already created and tied to the uppercase scalar parameters.
>>  Any change made to one is reflected in the other.
>>
>>  echo by default interprets c string escapes, you can disable that with
>>  the -E option.
>>
>>  You could avoid the command substitution with the parameter expansion
>>  flag U ''capsvar=${(U)var}'' to change the case of the value.
>>
>>  $var=(...) is also an error. ''set -A $var element1 element2 ...'' will
>>  allow you to indirectly set arrays
>>>  Issue #2.  Overridden local variables get echoed?
>>>
>>>  ~ 5% cat lib/zsh/test2                                                  9:55:52
>>>  function test2
>>>     print why is the previous value echoed when a local variable is 'overridden?'
>>  It actually happens when you use typeset, local, etc. on a parameter
>>  that is already defined. You can use the option TYPESET_SILENT option to
>>  silence it.
>>
>>  from the typeset section of zshbuiltins(1):
>>  If  the  shell  option  TYPESET_SILENT  is  not  set, for each remaining
>>  name that refers to a parameter that is set, the name and value of the
>>  parameter are printed in the form of an assignment.  Nothing is printed
>>  for newly-created parameters, or when any attribute flags listed below
>>  are given along with the name.  Using `+' instead of minus to introduce
>>  an attribute turns it off.
>>
>>  Pretty sure #3 and #4 is due to how typeset creates a local parameters
>>  when used in a function. So typeset -U PATH create a new parameter
>>  without a value, with the -U attribute.

Re: new user questions and issues

[Bart Schaefer]

Most of this has been answered already, throwing one extra remark.

On May 6, 10:37am, Kannan Varadhan wrote:
}
} Issue #2.  Overridden local variables get echoed?

The tidbit that no one has explicitly mentioned is that "local" et al.
has function scope, so it makes no sense to declare something "local"
inside a loop body.  (In an if/else, it could make sense, as long as
the if/else is not itself inside a loop, but the variables declared
there will persist beyond the "fi".)

If you for some reason need a declaration to be local to a loop, use
an anonymous function context like this:

    local _t2
    for _t2 in 0 1 2 ; do
      function {
        local _t3
        _t3=XXX__${_t2}__
      }
    done

Re: new user questions and issues

[Kannan Varadhan]

Well, ok, that is interesting.

The reason to declare local is to be tight and explicit about variable scope.  I have been bitten with other shells in which variables are visible far outside where I would expect, leading to unexpected side effects.  The most egregious is with loop control variables for me.

What I really desire is that the variable not be inherited by or visible to any called functions.

Kannan


> On May 10, 2015, at 10:02 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> Most of this has been answered already, throwing one extra remark.
> 
> On May 6, 10:37am, Kannan Varadhan wrote:
> }
> } Issue #2.  Overridden local variables get echoed?
> 
> The tidbit that no one has explicitly mentioned is that "local" et al.
> has function scope, so it makes no sense to declare something "local"
> inside a loop body.  (In an if/else, it could make sense, as long as
> the if/else is not itself inside a loop, but the variables declared
> there will persist beyond the "fi".)
> 
> If you for some reason need a declaration to be local to a loop, use
> an anonymous function context like this:
> 
>    local _t2
>    for _t2 in 0 1 2 ; do
>      function {
>        local _t3
>        _t3=XXX__${_t2}__
>      }
>    done
> 

Re: new user questions and issues

[Bart Schaefer]

On May 11, 10:43am, Kannan Varadhan wrote:
}
} What I really desire is that the variable not be inherited by or
} visible to any called functions.

That's pretty much never going to work.  The shell parameter space uses
dynamic scoping starting from the process environment on down; a scope
can explicitly replace a name from its surrounding scope, but can't
conceal that name from scopes upon which it calls.

In fact because shell functions can only accept arguments and can only
return exit status, dynamically scoped variables are the only way to
share data from a called function.  (Except stdin and stdout, of course,
but then you're dealing with separate processes, not merely scopes.)

Yes, ksh plays some games with this by allowing a nameref to be passed
as an argument.