Re: var=$( typeset "$1" ) ... not within a function.

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 2022-10-20 19:25, Bart Schaefer wrote:

> ... but the same command from within a script or function gives:
> > typeset -g -T CDPATH cdpath=(  )
> The -g is because typeset -p is supposed to be outputting a command
> that can be sent back through "eval".  If you were to execute that
> typeset without the -g when inside a function, you would create a new
> local CDPATH variable.  The -g makes sure you are still referencing
> the global.
It's a bit awkward.  When I'm clearly looking for information, not 
trying to 'do' anything I'd expect that the information is the 
information.  But I sorta see what  you mean, if the output is taken as 
the input to an 'eval' then ... well I dunno, but it ends up giving 
different answers to the same question.
> > ... and if I scan the entire output of "$ typeset -p" and look for
> > 'CDPATH' I get:
> >
> > typeset -T CDPATH cdpath=(  )
> > typeset -aT CDPATH cdpath=(  )
> The first one is the (incorrect) assignment for $CDPATH.
> The second one is the (correct) assignment for $cdpath.
> These are "tied" variables (the -T) meaning that if you change either
> one of them, the other also changes.

So then there is logic to having them on the same line, but no logic to 
having two separate lines, that's progress.

My specific little goal here is of little concern to the list but just 
in case anyone is interested in why I'm flogging this, one of my 
wrappers is designed to give you every possible usage of an identifier, 
be it a variable of any flavor, an alias, executable, builtin ... 
whatever else it might possibly be of interest to the shell. So it uses 
all the half dozen or so tools that might have something to say.  But it 
is designed to be case sensitive or not and to use wildcards.  But when 
it comes to the parameters (variables?) 'printenv' is always case 
sensitive and doesn't take wildcards but 'typeset' is never case 
sensitive and does take wildcards.  'set' doesn't have internal filters 
at all.  So, to add case sensitivity to the output of typeset I just run 
it thru a 'sed' for filtering and colorizing (which you can't see below 
of course).  So, if I want to know if, case insensitively, what "*path*" 
might mean to the shell: (the command is called 'i' for 'information):

$ . i; i "*path*"

EXACT search of the environment for "*path*" ...
No exact match found.

Case INsensitive WILD search for all variables matching: "*path*"

typeset -g -T CDPATH cdpath = (  )
typeset -g -T FPATH fpath = ( /usr/local/share/zsh/site-functions ...
typeset -g -T MAILPATH mailpath = (  )
typeset -g -T MANPATH manpath = (  )
typeset -g -T MODULE_PATH module_path = ( /usr/lib/x86_64-linux-g ...
export -T PATH path = ( . /aWorking/Zsh/System /aWorking/Bin /usr ...
export XDG_SEAT_PATH = /org/freedesktop/DisplayManager/Seat0
export XDG_SESSION_PATH = /org/freedesktop/DisplayManager/Session ...
typeset -g -aT CDPATH cdpath = (  )
typeset -g -aT FPATH fpath = ( /usr/local/share/zsh/site-function ...
typeset -g -aT MAILPATH mailpath = (  )
typeset -g -aT MANPATH manpath = (  )
typeset -g -aT MODULE_PATH module_path = ( /usr/lib/x86_64-linux- ...
typeset -g -aT PATH path = ( . /aWorking/Zsh/System /aWorking/Bin ...
typeset -aU ppath = ( /aWorking/Zsh/Source/Wk /aWorking/Zsh/Syste ...

Searching the path for unexecutable scripts or text files:
None found.

Searching for alias, function, builtin, or executable script or binary 
on the path:
Found 20 match(es):

(1)TYPE: _absolute_command_paths is an autoload shell function:

(2)TYPE: _canonical_paths is an autoload shell function:

(3)TYPE: _cygpath is an autoload shell function:

(4)TYPE: _path_commands is an autoload shell function:

(5)TYPE: _path_files is an autoload shell function:

(6)TYPE: _systemd-path is an autoload shell function:

(7)TYPE: _tracepath is an autoload shell function:

(8)TYPE: path is a shell function from miscfunctions:

(9)TYPE: dpkg-realpath is /usr/bin/dpkg-realpath:
CONTENT: EXECUTABLE SCRIPT

(10)TYPE: dpkg-realpath is /bin/dpkg-realpath -> /usr/bin/dpkg-realpath:
CONTENT: EXECUTABLE SCRIPT

(11)TYPE: grub-mkrelpath is /usr/bin/grub-mkrelpath:
CONTENT: EXECUTABLE UNKNOWN

(12)TYPE: grub-mkrelpath is /bin/grub-mkrelpath -> /usr/bin/grub-mkrelpath:
CONTENT: EXECUTABLE UNKNOWN

(13)TYPE: manpath is /usr/bin/manpath:
CONTENT: EXECUTABLE UNKNOWN

(14)TYPE: manpath is /bin/manpath -> /usr/bin/manpath:
CONTENT: EXECUTABLE UNKNOWN

(15)TYPE: pathchk is /usr/bin/pathchk:
CONTENT: EXECUTABLE UNKNOWN

(16)TYPE: pathchk is /bin/pathchk -> /usr/bin/pathchk:
CONTENT: EXECUTABLE UNKNOWN

(17)TYPE: realpath is /usr/bin/realpath:
CONTENT: EXECUTABLE UNKNOWN

(18)TYPE: realpath is /bin/realpath -> /usr/bin/realpath:
CONTENT: EXECUTABLE UNKNOWN

(19)TYPE: systemd-path is /usr/bin/systemd-path:
CONTENT: EXECUTABLE UNKNOWN

(20)TYPE: systemd-path is /bin/systemd-path -> /usr/bin/systemd-path:
CONTENT: EXECUTABLE UNKNOWN

=========================================

You'll all find it grotesque overkill but to me it's one stop shopping 
for whatever "*path*" might happen to be.  But notice the double finds 
above when 'typeset' is filtered thru sed:

typeset -g -T CDPATH cdpath = (  )
typeset -g -aT CDPATH cdpath = (  )

... it's just a bit annoying and it looks like Bart agrees it's a bug so 
that will be cured and of course '-aT' is correct.  (If case sensitivity 
was built in to typeset I'd not have to bother with the sed filter at 
all.  Seems to me that since we already have the use of wildcards there, 
case sensitivity would be a natural enhancement.  Dunno, maybe '-M' ... 
capital M means wildcards plus case sensitive.)

> ... and while I'm whining I notice that 'set' never does anything like:
> > "CDPATH cdpath", it puts them on separate lines.  Dunno, couldn't they
> > have separate values?
> No, they can't.  One is a colon-separated string and the other is an
> array, but they always track one another.

Understood.  So they really should be on the same line.  So then the 
questionable output would be from 'set' which shows them separately as 
tho they were strangers.  Mind, set doesn't output any type information 
at all so maybe that's OK.