zsh-users
 help / color / mirror / code / Atom feed
* path PATH
@ 2023-01-20 21:57 Ray Andrews
  2023-01-20 22:20 ` Bart Schaefer
  2023-01-21  5:47 ` Lawrence Velázquez
  0 siblings, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-20 21:57 UTC (permalink / raw)
  To: Zsh Users

$ echo $path
. /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin

$ echo $PATH
.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin

$ typeset -p path
typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

$ typeset -p PATH
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

... looks like typeset doesn't want to show the real contents of $PATH.  
As I understand it, the '-T' switch links two arrays that have different 
names but the same content.  Is this an exception? Might hafta be, 
because I know that the two are linked even tho they format 
differently.  Still one should be able to view $PATH 'honestly' no?




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-20 21:57 path PATH Ray Andrews
@ 2023-01-20 22:20 ` Bart Schaefer
  2023-01-21  2:23   ` Ray Andrews
  2023-01-21  5:47 ` Lawrence Velázquez
  1 sibling, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-20 22:20 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

Have you completely forgotten the lengthy thread (Subject: "typeset
-p" inconsistency) that we had the first week of last November?


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-20 22:20 ` Bart Schaefer
@ 2023-01-21  2:23   ` Ray Andrews
  2023-01-21  6:11     ` Lawrence Velázquez
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-21  2:23 UTC (permalink / raw)
  To: zsh-users


On 2023-01-20 14:20, Bart Schaefer wrote:
> Have you completely forgotten the lengthy thread (Subject: "typeset
> -p" inconsistency) that we had the first week of last November?
>
Not completely, but perhaps some detail.  It was one of those things 
that swamped me with too much to learn too quickly. Anyway, all the 
other '-T' arrays show identical content for either version, only 'PATH 
path' has this issue AFAICT.  And only PATH path is reported as 'export 
-T' (as well as 'typeset -g -aT', but all the '-T' arrays have double 
entries tho only PATH path has that unique 2nd version).

$ typeset -p | grep --color=always -- '^export -T'
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

... so it is unique.  Anyway it's a small thing but I'm wondering why 
only the one 'version' is ever shown.  If it was covered, pardon, I've 
forgotten that.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-20 21:57 path PATH Ray Andrews
  2023-01-20 22:20 ` Bart Schaefer
@ 2023-01-21  5:47 ` Lawrence Velázquez
  1 sibling, 0 replies; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-21  5:47 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Jan 20, 2023, at 4:57 PM, Ray Andrews wrote:
> As I understand it, the '-T' switch links two arrays that have different 
> names but the same content.

No, "typeset -T" ties an array to a scalar, which is synthesized
by joining the array's values with a separator character.

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21  2:23   ` Ray Andrews
@ 2023-01-21  6:11     ` Lawrence Velázquez
  2023-01-21 15:18       ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-21  6:11 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Jan 20, 2023, at 9:23 PM, Ray Andrews wrote:
> And only PATH path is reported as 'export 
> -T' (as well as 'typeset -g -aT', but all the '-T' arrays have double 
> entries tho only PATH path has that unique 2nd version).
>
> $ typeset -p | grep --color=always -- '^export -T'
> export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
> /usr/local/bin /usr/sbin /usr/bin )
>
> ... so it is unique.

No, that just means that PATH is the only global scalar that has
been tied and exported.  If you tie and export additional ones
they'll show up too.

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21  6:11     ` Lawrence Velázquez
@ 2023-01-21 15:18       ` Ray Andrews
  2023-01-21 15:25         ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-21 15:18 UTC (permalink / raw)
  To: zsh-users

On 2023-01-20 22:11, Lawrence Velázquez wrote:
>
>> ... so it is unique.
> No, that just means that PATH is the only global scalar that has
> been tied and exported.  If you tie and export additional ones
> they'll show up too.
>
But if it is the only one then it is unique.  I didn't suggest that the 
same situation might not be applied to another parameter, only that it 
has not been.  It just served as a possible clue as to why no variation 
of 'typeset' will show you:


3 /aWorking/Zsh/Source/Wk 0 $ echo $PATH
.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin

> No, "typeset -T" ties an array to a scalar, which is synthesized
by joining the array's values with a separator character.

Now that you mention it, $PATH is a scalar ... hasta be because there's no spaces.  But all the others display as arrays, so that's where I went wrong there. But 'PATH path' always displays as an array too.  It still seems to be an anomaly. So then if we had other tied scalars they too would only display as arrays?  Anyway, perhaps this just isn't worth worrying about, $PATH is a special case (I think) because as you say it's 'synthesized' via the joining of members with the colon vs. the space.

I dislike exceptions and special cases but perhaps this one is unavoidable.  (Obviously the way $PATH works is by now fundamental, but I can't help wondering why a space separated array wouldn't work, like $path.  IOW, given $path, why do we need $PATH at all?)  Nevermind, I'm inclined to fret about things like this, it's not important I'd just like typeset to show me $PATH as it really is not pretend that's it's identical to $path when it isn't.  Accuracy matters no? :

$ set | grep -i "^path"
PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin
path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin )

... In fact I'm trying to write a function that will show me *both* the type of all variables (typeset) *and* their accurate values (set).  I've got it nailed down except for $PATH and the one exception bothers me. But life is one big exception.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 15:18       ` Ray Andrews
@ 2023-01-21 15:25         ` Roman Perepelitsa
  2023-01-21 16:21           ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-21 15:25 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023 at 4:18 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-20 22:11, Lawrence Velázquez wrote:
> >
> >> ... so it is unique.
> > No, that just means that PATH is the only global scalar that has
> > been tied and exported.  If you tie and export additional ones
> > they'll show up too.

PATH isn't special. Here:

    % export -T FOO foo=( bar baz )
    % typeset -p FOO
    export -T FOO foo=( bar baz )

The output of `typeset -p` is a command that you can evaluate to set
the parameter to its current value.

Do you see that everything works as intended? If not, what do you
think `typeset -p FOO` should output here? Keep in mind that it must
be a command that you can evaluate to set the parameter to its current
value.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 15:25         ` Roman Perepelitsa
@ 2023-01-21 16:21           ` Ray Andrews
  2023-01-21 16:38             ` Roman Perepelitsa
  2023-01-21 16:48             ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-21 16:21 UTC (permalink / raw)
  To: zsh-users


On 2023-01-21 07:25, Roman Perepelitsa wrote:
> PATH isn't special. Here:

I understand.  One could create other variables that show as 'export -T 
...' but this is not actually done in the raw shell, so PATH is unique 
even if not 'special' as you use the word.  However it is 'special' in 
that 'typeset -p PATH' does not show it's accurate value.  I suspect 
that, as Lawrence said, it's because PATH is an internally created 
modification of path, it's a scalar created from an array.  So FOO is 
all fine, but PATH has a certain specialness -- no other tied parameter 
has one 'version' different from the other.  This might be unfixable in 
as much as 'typeset -p' displays information via a sort of re-creation 
(as Bart explained a few months ago) -- which seems very strange to me 
but what do I know?  IOW typeset *itself* might not even 'know' that 
PATH != path, all it knows is that the two are tied and that PATH points 
to path.  It does not know that PATH is then modified. Stalemate.  It 
bugs me but thereyago.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 16:21           ` Ray Andrews
@ 2023-01-21 16:38             ` Roman Perepelitsa
  2023-01-21 16:54               ` Ray Andrews
  2023-01-21 16:48             ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-21 16:38 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023 at 5:21 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> One could create other variables that show as 'export -T
> ...' but this is not actually done in the raw shell, so PATH is unique
> even if not 'special' as you use the word.

I'm not sure what you are trying to say here. PATH has a unique name,
yes, but it behaves like any other parameter. In particular, `typeset
-p` works on PATH the same way as on any other parameter. Perhaps you
want `typeset -p` to work differently for PATH? In other words, do you
want PATH to be special?

> However it is 'special' in that 'typeset -p PATH' does not show
> it's accurate value.

`typeset -p PATH` does show the precise and accurate value of PATH.
It's so precise and accurate that you can literally evaluate the
output to obtain exactly the same state of PATH in another shell.

The job of `typeset -p` is to tell you precisely and accurately what a
certain parameter is. The output of `typeset -p PATH` achieves that.
There is no hidden "real" value that it doesn't show. It shows every
bit of information related to PATH.

Consider this snippet:

    % typeset foo=$'1\n2'
    % print -r -- $foo
    1
    2
    % typeset -p foo
    typeset foo=$'1\n2'

Is `typeset -p` also not printing the "real" value of the parameter here?

I'll ask again: what do you think should be the output of `typeset -p PATH`?

Roman.

P.S.

I think you perceive some difference between PATH and FOO from my
previous email. There isn't any. There are some tools (commands and
builtins) whose *behavior* depends on PATH, but that doesn't imply
anything special about the parameter itself.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 16:21           ` Ray Andrews
  2023-01-21 16:38             ` Roman Perepelitsa
@ 2023-01-21 16:48             ` Bart Schaefer
  1 sibling, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-21 16:48 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

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

On Sat, Jan 21, 2023 at 8:21 AM Ray Andrews <rayandrews@eastlink.ca> wrote:

>
> I suspect
> that, as Lawrence said, it's because PATH is an internally created
> modification of path, it's a scalar created from an array.  So FOO is
> all fine, but PATH has a certain specialness -- no other tied parameter
> has one 'version' different from the other.
>

The definition of a tied parameter is that one of the pair is a scalar
string with an internal delimiter defaulting to a colon, and the other is
an array of the delimited values.  There's nothing magic about PATH in this
respect.

[-- Attachment #2: Type: text/html, Size: 910 bytes --]

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 16:38             ` Roman Perepelitsa
@ 2023-01-21 16:54               ` Ray Andrews
  2023-01-21 17:01                 ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-21 16:54 UTC (permalink / raw)
  To: zsh-users


On 2023-01-21 08:38, Roman Perepelitsa wrote:
> `typeset -p PATH` does show the precise and accurate value of PATH.

3 /aWorking/Zsh/Source/Wk 1 $ set | grep  "^PATH"
PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin

3 /aWorking/Zsh/Source/Wk 1 $ typeset -p PATH
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 16:54               ` Ray Andrews
@ 2023-01-21 17:01                 ` Roman Perepelitsa
  2023-01-21 18:53                   ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-21 17:01 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023 at 5:54 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-21 08:38, Roman Perepelitsa wrote:
> > `typeset -p PATH` does show the precise and accurate value of PATH.
>
> 3 /aWorking/Zsh/Source/Wk 1 $ set | grep  "^PATH"
> PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin
>
> 3 /aWorking/Zsh/Source/Wk 1 $ typeset -p PATH
> export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin
> /usr/local/bin /usr/sbin /usr/bin )

Can you elaborate? Do you believe that these two commands should have
identical output?

Does it bother you that in the following snippet the last two commands
also don't have identical output?

    % export -i8 BAR=42

    % typeset -p BAR
    export -i8 BAR=42

    % env | grep BAR
    BAR=8#52

These are different commands and they have different output. Neither
shows the "true" or "real" value of the parameter. `typeset -p` shows
exactly and precisely what a zsh parameter is, while `env` shows the
environment.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 17:01                 ` Roman Perepelitsa
@ 2023-01-21 18:53                   ` Ray Andrews
  2023-01-21 19:09                     ` Roman Perepelitsa
  2023-01-21 20:19                     ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-21 18:53 UTC (permalink / raw)
  To: zsh-users


On 2023-01-21 09:01, Roman Perepelitsa wrote:
>
>> 3 /aWorking/Zsh/Source/Wk 1 $ set | grep  "^PATH"
>> PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin
>>
>> 3 /aWorking/Zsh/Source/Wk 1 $ typeset -p PATH
>> export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin
>> /usr/local/bin /usr/sbin /usr/bin )
> Can you elaborate? Do you believe that these two commands should have
> identical output?
Yes.  Both would seem to be displaying values.  And in every case except 
PATH, that is exactly what happens.
>
> Does it bother you that in the following snippet the last two commands
> also don't have identical output?
>
>      % export -i8 BAR=42
>
>      % typeset -p BAR
>      export -i8 BAR=42
>
>      % env | grep BAR
>      BAR=8#52
>
> These are different commands and they have different output. Neither
> shows the "true" or "real" value of the parameter. `typeset -p` shows
> exactly and precisely what a zsh parameter is, while `env` shows the
> environment.

That's a bit Byzantine isn't it?  If 'env' displays the base of the 
number whereas typeset displays the command by which the base was 
forced, no I don't think that's a genuine comparison.  It's nothing the 
same as PATH displaying with spaces when in fact it has colons.  In your 
example one clearly anticipates the other; it's actually the same 
information just formatted differently.

Bart:

 > The definition of a tied parameter is that one of the pair is a 
scalar string with an internal delimiter defaulting to a colon, and the 
other is an array of the delimited values.  There's nothing magic about 
PATH in this respect.

Ah!  So now we're barking up the same tree.  But ... all the other tied 
parameters look like merely the same array with two different names.  
Have I made the wrong pattern?

...

Yes, I have:  set | grep FPATH  ... and what do I see but colons!

NUTS!  All the others, there's only one element so there's no chance for 
the colons to show up :(  they define as arrays, but there's actually 
just the one element so that's where I lost the scent.  I get it.  Many 
thanks.  So PATH is indeed unique but it isn't special :)




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 18:53                   ` Ray Andrews
@ 2023-01-21 19:09                     ` Roman Perepelitsa
  2023-01-21 20:50                       ` Ray Andrews
  2023-01-21 20:19                     ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-21 19:09 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023 at 7:54 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> It's nothing the same as PATH displaying with spaces when in fact it
> has colons.

Is the number 42 "in fact" 8#52?

When you type `typeset -p PATH` you are asking zsh "what exactly is
PATH parameter" and zsh answers *this* question precisely and
accurately. When you type `printenv PATH`, you are asking "what is the
value of PATH environment variable" and you get the answer to *this*
question precisely and accurately. The two answers aren't the same
because the questions aren't the same. Both answers are correct for
the respective questions and they would be nonsense if the questions
were swapped.

I gotta say, in pretty much every thread where you asked a question
I'm left wondering whether you understood what I was saying. From my
point of view the answer is logical and in a sense obvious, but every
response I can elicit from you leaves me doubtful. Do you see that
`typeset -p PATH` prints the right answer to the question you are
asking and that any other output would have been wrong?

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 18:53                   ` Ray Andrews
  2023-01-21 19:09                     ` Roman Perepelitsa
@ 2023-01-21 20:19                     ` Bart Schaefer
  2023-01-21 20:26                       ` env arrays (was: Re: path PATH) zeurkous
  2023-01-21 21:03                       ` path PATH Ray Andrews
  1 sibling, 2 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-21 20:19 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023 at 10:54 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> NUTS!  All the others, there's only one element so there's no chance for
> the colons to show up :(  they define as arrays, but there's actually
> just the one element so that's where I lost the scent.  I get it.  Many
> thanks.  So PATH is indeed unique but it isn't special :)

It's actually the other way around; it's special (because it cannot be
un-tied) but not unique.  These scalar variables are tied, exported,
and special:

PATH
MANPATH

These scalars are tied and special but not (by default) exported:

CDPATH
FIGNORE
FPATH
MAILPATH
MODULE_PATH
PSVAR
ZSH_EVAL_CONTEXT

These all behave the same way with respect to the array value being
joined by colons to form the scalar value, and they all remain tied
even if you unset them (as in, both parts of each pair will reappear
as soon as you assign a value to either the scalar or the array).  The
reason for this tied behavior is so that the scalar parts CAN be
exported, because the environment cannot contain arrays.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* env arrays (was: Re: path PATH)
  2023-01-21 20:19                     ` Bart Schaefer
@ 2023-01-21 20:26                       ` zeurkous
  2023-01-22 17:28                         ` Bart Schaefer
  2023-01-21 21:03                       ` path PATH Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: zeurkous @ 2023-01-21 20:26 UTC (permalink / raw)
  To: Bart Schaefer, Ray Andrews; +Cc: zsh-users

On Sat, 21 Jan 2023 12:19:51 -0800, Bart Schaefer <schaefer@brasslantern.com> wrote:
> The
> reason for this tied behavior is so that the scalar parts CAN be
> exported, because the environment cannot contain arrays.

It might not be able to contain arrays, but it's possible to have it
contain array *elements*--

 % env 'blaat[0]=scaahp' 'blaat[1]=mekker' env | tail -n 2 
 blaat[0]=scaahp
 blaat[1]=mekker
 %

Can zsh work w/ such an approach? By default megets--

 % setopt KSH_ARRAYS
 % blaat[0]=scaahp
 % export 'blaat[0]'
 % env
 [...no 'blaat[0]' in there...]
 % 'blaat[0]'=scaahp
 zsh: command not found: blaat[0]=scaahp
 % export 'blaat[0]'=scaahp
 % env
 [...no 'blaat[0]' in there either...]

         --zeurkous.

-- 
Friggin' Machines!


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 19:09                     ` Roman Perepelitsa
@ 2023-01-21 20:50                       ` Ray Andrews
  2023-01-21 21:11                         ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-21 20:50 UTC (permalink / raw)
  To: zsh-users


On 2023-01-21 11:09, Roman Perepelitsa wrote:
> Is the number 42 "in fact" 8#52? 
Yes, it most certainly is -- in base 8, which is explicit.
> I gotta say, in pretty much every thread where you asked a question
> I'm left wondering whether you understood what I was saying. From my
> point of view the answer is logical and in a sense obvious

Ah, we'll that's the thing, one can misunderstand some basic premise 
which makes everything subsequent illogical.  Bart cleared this up by 
disabusing me of the idea that that a tie was just another name for 
exactly the same thing, and that *appears* to be the case.  It seemed so 
obviously the case that I didn't even ask the question.  But no!  a tie 
creates a scalar with the array elements joined by colons ... $PATH!  
But since typeset -p, in every other situation, shows you the value of a 
parameter I'm wanting the same for PATH.  I'd use set -- which shows it 
accurately with the colons -- *but* I'd also like to see the type of the 
variable besides it's value  which pushes me back to typeset -p.  So, 
there's no easy answer.  I just hafta remember that PATH, like any other 
tied param, will be a scalar created from an array and sorry, it can't 
be displayed  like that by typeset -p.    Dunno, maybe I can hack 
something together but probably not worth it.  One might wish for an 
option to set that would include type as well as value.  No typeset -p 
'recreation', just the information.  I sorta understand why typeset 
itself is not the vehicle for this since it's not by nature a 'viewer' 
but a 'creator'.

Anyway I've wasted enough of you guy's time with this.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 20:19                     ` Bart Schaefer
  2023-01-21 20:26                       ` env arrays (was: Re: path PATH) zeurkous
@ 2023-01-21 21:03                       ` Ray Andrews
  2023-01-21 21:52                         ` Lawrence Velázquez
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-21 21:03 UTC (permalink / raw)
  To: zsh-users


On 2023-01-21 12:19, Bart Schaefer wrote:
>
> It's actually the other way around; it's special (because it cannot be
> un-tied) but not unique.
It's the only one that displays as 'export -T'.  Here, anyway.
> These scalar variables are tied, exported,
> and special:
>
> PATH
> MANPATH

Here: MANPATH is: 'typeset -T' like several others.  But it's good to 
know that indeed there are special values that will be treated 
differently.  So I was right about PATH but for the wrong reason ... 
which is simply being wrong.

> The
> reason for this tied behavior is so that the scalar parts CAN be
> exported, because the environment cannot contain arrays.

Ah!  That answers my question as to what all this tie-dying is about.  I 
had no idea you can't export arrays.  Marvelous.  You know, when you 
understand why something is, then what it is becomes much easier.  The 
clouds part.



^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 20:50                       ` Ray Andrews
@ 2023-01-21 21:11                         ` Roman Perepelitsa
  0 siblings, 0 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-21 21:11 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023 at 9:51 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-21 11:09, Roman Perepelitsa wrote:
> > Is the number 42 "in fact" 8#52?
> Yes, it most certainly is -- in base 8, which is explicit.

It's a different representation for the same thing, isn't it? Neither
is the real thing or the actual value.

The same goes for "A", "\x41" and "\101". These are different
representations for the same object, with none being the object
itself. Now, when `typeset -p` prints the value of a parameter, it has
to choose some representations and there is no obvious choice, for no
representation is "the true one". In this case it so happens that the
representation for a tied parameter chosen by `typeset -p` is the
array's elements, while you would prefer to see a different
representation -- that of the scalar. Whenever you simply need to know
what a parameter is, any representation will suffice and so you use
`typeset -p`. When you need to see a specific representation, you
should not use `typeset -p` and instead arrange for your preferred
representation to be produced explicitly. In this case that could be:

    print -r -- "PATH=${(qqq)PATH}"

Or maybe you'll prefer a different quoting scheme. In any case, if you
want a specific representation, ask for that explicitly.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 21:03                       ` path PATH Ray Andrews
@ 2023-01-21 21:52                         ` Lawrence Velázquez
  2023-01-22  0:42                           ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-21 21:52 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 21, 2023, at 4:03 PM, Ray Andrews wrote:
> On 2023-01-21 12:19, Bart Schaefer wrote:
>>
>> It's actually the other way around; it's special (because it cannot be
>> un-tied) but not unique.
> It's the only one that displays as 'export -T'.  Here, anyway.

Why do you keep harping on this, despite everything we've said?
Again, the fact that your shell only has one variable that "typeset
-p" displays this way is incidental; you could create more any time
you want.

Imagine if I were trying to open some files in a text editor, but
they all looked like gibberish except one, and then I confidently
concluded that the editor must be treating that one file specially
instead of considering that maybe I had only one text file.


>> These scalar variables are tied, exported,
>> and special:
>>
>> PATH
>> MANPATH
>
> Here: MANPATH is: 'typeset -T' like several others.

If you were to set it in a typical way...

    export MANPATH=/one/path:/another/path:/a/third/path

...then it would display as PATH does.


-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-21 21:52                         ` Lawrence Velázquez
@ 2023-01-22  0:42                           ` Ray Andrews
  2023-01-22 12:29                             ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-22  0:42 UTC (permalink / raw)
  To: zsh-users


On 2023-01-21 13:52, Lawrence Velázquez wrote:
> Why do you keep harping on this, despite everything we've said?
> Again, the fact that your shell only has one variable that "typeset
> -p" displays this way is incidental; you could create more any time
> you want.

I quite understand.  It is unique HERE, and that's what lead me to think 
it was in a category all it's own.  I was wrong.  I get it now.


Roman:

> When you need to see a specific representation, you
should not use `typeset -p` and instead arrange for your preferred
representation to be produced explicitly.

Exactly.  But as I said, I want to display the types too, and had hoped it would be possible, but it isn't so that's that.  But now that I know exactly how the scalar is created and what it must look like, the problem becomes trivial -- replace spaces with colons.  My big error was thinking the tied names were just basically aliases for exactly the same array so PATH path *seemed* like a special case. Dunno, it was just a post-mortem on where I went astray. I've wasted enough of your time on this.
  



^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22  0:42                           ` Ray Andrews
@ 2023-01-22 12:29                             ` Roman Perepelitsa
  2023-01-22 14:17                               ` Ray Andrews
  2023-01-22 19:20                               ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-22 12:29 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023 at 1:42 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I want to display the types too, and had hoped it would be possible, but it isn't so that's that.

Perhaps you can use something like this to describe parameters:

    describe-param() {
      emulate -L zsh
      [[ ARGC -eq 1 && -n $1 ]] || return
      set -- "$@" ${(Pt)1}
      [[ -$2- == *-hide-* ]] && return 1
      print -rn -- "$2 ${(q-)1}"
      if [[ -$2- == *-hideval-* ]]; then
        print
      else
        set -- "$@" ${(M)2:#(array|association)(|-*)}
        print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}"
      fi
    }

The output of this function is of the following shape:

    <TYPE> <NAME>[=<VALUE>]

For example:

    % describe-param PWD
    scalar-export PWD="/home/romka"

    % describe-param MAILCHECK
    integer MAILCHECK="60"

    % describe-param PATH
    scalar-tied-export-special PATH="/home/romka/bin:..."

    % describe-param path
    array-tied-unique-special path=( "/home/romka/bin" ... )

You might want to customize how the type is printed.

If you want to describe all parameters, you can do it like this:

    for name in ${(k)parameters}; do
      describe-param $name
    done

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 12:29                             ` Roman Perepelitsa
@ 2023-01-22 14:17                               ` Ray Andrews
  2023-01-22 16:15                                 ` Bart Schaefer
  2023-01-22 19:20                               ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 14:17 UTC (permalink / raw)
  To: zsh-users


On 2023-01-22 04:29, Roman Perepelitsa wrote:
>
> Perhaps you can use something like this to describe parameters:
>
>      describe-param() {
>        emulate -L zsh
>        [[ ARGC -eq 1 && -n $1 ]] || return
>        set -- "$@" ${(Pt)1}
>        [[ -$2- == *-hide-* ]] && return 1
>        print -rn -- "$2 ${(q-)1}"
>        if [[ -$2- == *-hideval-* ]]; then
>          print
>        else
>          set -- "$@" ${(M)2:#(array|association)(|-*)}
>          print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}"
>        fi
>      }
>
Fantastic.  I've never seen parameter descriptions of that sort. So 
verbal, so helpful , so complete.  Whoever coded that was a friend of 
humanity that day:

5 /aWorking/Zsh/Source/Wk 0 $ describe-param PATH
scalar-tied-export-special 
PATH=".:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin"

5 /aWorking/Zsh/Source/Wk 0 $ describe-param path
array-tied-special path=( "." "/aWorking/Zsh/System" "/aWorking/Bin" 
"/usr/local/bin" "/usr/sbin" "/usr/bin" )

... ALL the information, all the time.  I'll bet it even works on 
Tuesdays.  Dunno, it's mostly a psychological thing but whereas most of 
the time brief, compact information is all you need, it is nice to know 
that when you hafta, you can get ALL the information.  I learn that PATH 
is exported and path is not!  Who knew?  typeset -p obfuscates more than 
helps.  But, as Bart was saying, we can't export arrays (why not? it 
seems arbitrary), so that's what PATH is for.  Complete information 
explains itself. If I'd had that function from the getgo, this entire 
thread would have been unnecessary, the issue would have explained 
itself. It's going to be a good day.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 14:17                               ` Ray Andrews
@ 2023-01-22 16:15                                 ` Bart Schaefer
  2023-01-22 17:23                                   ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 16:15 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023 at 6:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Fantastic.  I've never seen parameter descriptions of that sort.

This is exactly what I suggested in zsh-users/28317 last November,
except I wrote it as a one-liner using the $parameters variable.

> But, as Bart was saying, we can't export arrays (why not? it
> seems arbitrary)

The operating system defines the environment as an array ("C"
language) of strings; you can't nest the arrays.  The way an array is
represented in the environment is by convention to separate the
elements with colons.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 16:15                                 ` Bart Schaefer
@ 2023-01-22 17:23                                   ` Ray Andrews
  0 siblings, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 17:23 UTC (permalink / raw)
  To: zsh-users


On 2023-01-22 08:15, Bart Schaefer wrote:
> This is exactly what I suggested in zsh-users/28317 last November,
> except I wrote it as a one-liner using the $parameters variable.

It can take a while for things to sink in.  One has to be ready. There 
are times when some question or some mistake of mine leads to a tsunami 
of fixes, cascading mental adjustments -- mistakes within mistakes, new 
ideas, re-thinks -- a whole lot of dominos fall over and I can't stand 
them all back up again in one go.


> The operating system defines the environment as an array ("C"
> language) of strings; you can't nest the arrays.  The way an array is
> represented in the environment is by convention to separate the
> elements with colons.

I just love these deep insights.  So this drills right down to a C 
limitation!  Or should I say an OS limitation?  C would permit a 
structure even if Linux won't countenance it.  Mind, it's the sort of 
thing that's so deep in the bedrock that a change is hardly possible.  
Your answer cures  me of any whinyness -- not zsh's issue.  Death and 
taxes and no arrays in the environment, get used to it.  But now I 
finally get the point of those colons, it seemed dumb -- PATH is 
'naturally' an array.  So we have $path :-) And I can confidently 
extrapolate that path is created from PATH, not visa versa, yes?  (Cuz a 
given shell can only 'inherit' PATH, thus the friendlier path must be 
the derivative.)




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: env arrays (was: Re: path PATH)
  2023-01-21 20:26                       ` env arrays (was: Re: path PATH) zeurkous
@ 2023-01-22 17:28                         ` Bart Schaefer
  0 siblings, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 17:28 UTC (permalink / raw)
  To: zeurkous; +Cc: Ray Andrews, zsh-users

On Sat, Jan 21, 2023 at 12:38 PM <zeurkous@blaatscaahp.org> wrote:
>
> It might not be able to contain arrays, but it's possible to have it
> contain array *elements*--
>
>  % env 'blaat[0]=scaahp' 'blaat[1]=mekker' env | tail -n 2
>  blaat[0]=scaahp
>  blaat[1]=mekker
>  %
>
> Can zsh work w/ such an approach?

It could be implemented, but unless we were to rewrite the internals
to use sparse arrays, import of that syntax would allow the moral
equivalent of a zip bomb:

env 'kaboom[999999999999999999]=waytoobig' ...

Generally speaking, for security you do not want environment strings
to be "programmable" in any sense.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 12:29                             ` Roman Perepelitsa
  2023-01-22 14:17                               ` Ray Andrews
@ 2023-01-22 19:20                               ` Bart Schaefer
  2023-01-22 19:31                                 ` Roman Perepelitsa
  2023-01-22 19:52                                 ` Ray Andrews
  1 sibling, 2 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 19:20 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users

On Sun, Jan 22, 2023 at 4:30 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
>     describe-param() {
>       emulate -L zsh
>       [[ ARGC -eq 1 && -n $1 ]] || return
>       set -- "$@" ${(Pt)1}
>       [[ -$2- == *-hide-* ]] && return 1

I'm curious why you chose to do this?  The "hide" attribute means that
a local does not preserve semantics of a special global, not that it's
name is invisible.

>       print -rn -- "$2 ${(q-)1}"
>       if [[ -$2- == *-hideval-* ]]; then
>         print

I'd guess that Ray would prefer to see the value even if it's normally
hidden by "set" but this is more consistent.

>       else
>         set -- "$@" ${(M)2:#(array|association)(|-*)}
>         print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}"

If you leave off the "${(q-)1}" in the earlier "print -rn", I think this is just
   typeset -m ${(q)1}
(where I'm not even sure the (q) is necessary).

>       fi
>     }

[...]

> If you want to describe all parameters, you can do it like this:
>
>     for name in ${(k)parameters}; do
>       describe-param $name
>     done

If the $parameters array is thrown in to the function itself, we can
make describe-param accept multiple names and patterns.

describe-params () {
  emulate -L zsh -o extendedglob
  zmodload zsh/parameter
  set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}
  while ((ARGC))
  do
    print -rn -- "${parameters[$1]} "
    if [[ -${parameters[$1]}- = *-hideval-* ]]
    then
      print -r -- ${(q-)1}
    else
      typeset -m ${(q)1}
    fi
    shift
  done
}

Now describing all parameters is just

  describe-params '*'

and it'll also handle

  describe-params '*(#i)path' '(#i)zsh*'

etc.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:20                               ` Bart Schaefer
@ 2023-01-22 19:31                                 ` Roman Perepelitsa
  2023-01-22 19:51                                   ` Bart Schaefer
  2023-01-22 19:52                                 ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-22 19:31 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

On Sun, Jan 22, 2023 at 8:20 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sun, Jan 22, 2023 at 4:30 AM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> >     describe-param() {
> >       emulate -L zsh
> >       [[ ARGC -eq 1 && -n $1 ]] || return
> >       set -- "$@" ${(Pt)1}
> >       [[ -$2- == *-hide-* ]] && return 1
>
> I'm curious why you chose to do this?  The "hide" attribute means that
> a local does not preserve semantics of a special global, not that it's
> name is invisible.

That's a brainfart on my part. I even know what "hide" means but
somehow I've coded it as if it meant something else.

> >       print -rn -- "$2 ${(q-)1}"
> >       if [[ -$2- == *-hideval-* ]]; then
> >         print
>
> I'd guess that Ray would prefer to see the value even if it's normally
> hidden by "set" but this is more consistent.

I mainly added this after seeing just how much output there is if you
print values of all parameters. Made me appreciate the fact that
`typeset` doesn't print those.

> >       else
> >         set -- "$@" ${(M)2:#(array|association)(|-*)}
> >         print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}"
>
> If you leave off the "${(q-)1}" in the earlier "print -rn", I think this is just
>    typeset -m ${(q)1}

Oh, I only now realized that the output of `typeset -m` isn't the same
as of `typeset -p` (I now see that you've pointed this out in earlier
emails but I missed it). This is definitely an improvement to the code
but makes me wonder whether it's a good thing that typeset behaves
this way. Intuitively, I expected that `typeset -m pat` is equivalent
to `typeset -p [params]..` where `[params]..` is the names of all
parameters matching `pat`.

> (where I'm not even sure the (q) is necessary).

I think it should be (b).

> describe-params () {
>   emulate -L zsh -o extendedglob
>   zmodload zsh/parameter
>   set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}
>   while ((ARGC))
>   do
>     print -rn -- "${parameters[$1]} "
>     if [[ -${parameters[$1]}- = *-hideval-* ]]
>     then
>       print -r -- ${(q-)1}
>     else
>       typeset -m ${(q)1}
>     fi
>     shift
>   done
> }

This looks great! Simpler and more powerful than my version.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:31                                 ` Roman Perepelitsa
@ 2023-01-22 19:51                                   ` Bart Schaefer
  2023-01-22 19:56                                     ` Roman Perepelitsa
                                                       ` (2 more replies)
  0 siblings, 3 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 19:51 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users

On Sun, Jan 22, 2023 at 11:31 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> Intuitively, I expected that `typeset -m pat` is equivalent
> to `typeset -p [params]..` where `[params]..` is the names of all
> parameters matching `pat`.

You can get this by combining -p and -m, which I think is one reason
why -m is different.

> > (where I'm not even sure the (q) is necessary).
>
> I think it should be (b).

Are there valid characters in an identifier name that would be quoted
differently by (b) and (q)?

I did find a bug:  describe-params -

Revised:

describe-params () {
  emulate -L zsh -o extendedglob
  set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}
  while ((ARGC))
  do
    print -rn -- "${parameters[$1]} "
    if [[ -${parameters[$1]}- = *-hideval-* ]]
    then
      print -r -- ${(q-)1}
    else
      typeset -m -- ${(b)1}
    fi
    shift
  done
}


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:20                               ` Bart Schaefer
  2023-01-22 19:31                                 ` Roman Perepelitsa
@ 2023-01-22 19:52                                 ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 19:52 UTC (permalink / raw)
  To: zsh-users

On 2023-01-22 11:20, Bart Schaefer wrote:
>
> I'm curious why you chose to do this?  The "hide" attribute means that
> a local does not preserve semantics of a special global, not that it's
> name is invisible.

I was just about to ask that.  There's a lot to learn from Roman's code 
but in an experimental frame of mind I have it boiled down to:

     set -- "$@" ${(Pt)1}
     print -rn -- "$2 ${(q-)1}"
# Seems unneeded:
#    set -- "$@" ${(M)2:#(array|association)(|-*)}
     print -r -- " = ${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}"

... I'm completely new to this overwriting of '@', it works but it will 
take a while to assimilate.  Never seen anything like it before.  Don't 
know what to make of it.

I'll be interested in Roman's response to your further points before I 
grab the final edit.  Oh, and my last line above, that blows my 
breakers, I don't have a prayer of understanding it right now.  4 levels 
of nesting?




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:51                                   ` Bart Schaefer
@ 2023-01-22 19:56                                     ` Roman Perepelitsa
  2023-01-22 20:03                                       ` Bart Schaefer
  2023-01-22 20:12                                       ` Ray Andrews
  2023-01-24 20:00                                     ` Ray Andrews
  2023-01-24 23:28                                     ` Ray Andrews
  2 siblings, 2 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-22 19:56 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

On Sun, Jan 22, 2023 at 8:51 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sun, Jan 22, 2023 at 11:31 AM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > Intuitively, I expected that `typeset -m pat` is equivalent
> > to `typeset -p [params]..` where `[params]..` is the names of all
> > parameters matching `pat`.
>
> You can get this by combining -p and -m, which I think is one reason
> why -m is different.

It's still weird. I would accept this reasoning if `typeset path`
produced the same output as `typeset -m path` but it doesn't.
Something feels off.

> > > (where I'm not even sure the (q) is necessary).
> >
> > I think it should be (b).
>
> Are there valid characters in an identifier name that would be quoted
> differently by (b) and (q)?

I don't know. I said it should be (b) because it would be correct by
design while (q) could only be correct by coincidence.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:56                                     ` Roman Perepelitsa
@ 2023-01-22 20:03                                       ` Bart Schaefer
  2023-01-22 21:56                                         ` Bart Schaefer
  2023-01-22 20:12                                       ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 20:03 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: zsh-users

On Sun, Jan 22, 2023 at 11:56 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Sun, Jan 22, 2023 at 8:51 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > You can get this by combining -p and -m, which I think is one reason
> > why -m is different.
>
> It's still weird. I would accept this reasoning if `typeset path`
> produced the same output as `typeset -m path` but it doesn't.

Well, the other reason is that "typeset -m" pre-dates "typeset -p" and
had existing expected behavior.

> I don't know. I said it should be (b) because it would be correct by
> design while (q) could only be correct by coincidence.

Fiddling with this and some patterns also brought up another question:

% describe-params 0
scalar-special 0=describe-params

Would it be better to use POSIX_ARGZERO to reveal the name of the
shell itself?  There's no way from inside a function to grab $0 from
the caller unless the caller itself asserts NO_FUNCTION_ARGZERO.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:56                                     ` Roman Perepelitsa
  2023-01-22 20:03                                       ` Bart Schaefer
@ 2023-01-22 20:12                                       ` Ray Andrews
  2023-01-22 21:11                                         ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 20:12 UTC (permalink / raw)
  To: Roman Perepelitsa, Bart Schaefer; +Cc: zsh-users


On 2023-01-22 11:56, Roman Perepelitsa wrote:
> It's still weird. I would accept this reasoning if `typeset path`
> produced the same output as `typeset -m path` but it doesn't.
> Something feels off.
>
typeset basically sux.  I know my opinion is unwashed, but typeset leads 
me astray in every way.  What you and Bart are writing just now is what 
'typeset -p' should basically be doing. This 'display' via re-creation' 
-- which gives us those useless 'typeset -g ...' outputs within a 
function -- And the m and p switches don't play well together.  Nope, 
it's hard to love typeset.  Dunno, if I ask you your middle name, should 
the answer be to re-create your birth certificate?  Just tell me.  
typeset -p is a very busted way of getting information.  OK, it's not 
*meant* for getting information but, prior to describe-param it's where 
you had to go.  Finally we have a real solution!




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 20:12                                       ` Ray Andrews
@ 2023-01-22 21:11                                         ` Bart Schaefer
  2023-01-22 22:44                                           ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 21:11 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Roman Perepelitsa, zsh-users

On Sun, Jan 22, 2023 at 12:12 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> typeset -p is a very busted way of getting information.  OK, it's not
> *meant* for getting information but, prior to describe-param it's where
> you had to go.

That's obviously not true, or it would not have been possible to write
describe-params.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 20:03                                       ` Bart Schaefer
@ 2023-01-22 21:56                                         ` Bart Schaefer
  2023-01-22 22:02                                           ` Roman Perepelitsa
  2023-01-22 23:03                                           ` Ray Andrews
  0 siblings, 2 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 21:56 UTC (permalink / raw)
  To: zsh-users

On Sun, Jan 22, 2023 at 12:03 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> % describe-params 0
> scalar-special 0=describe-params
>
> Would it be better to use POSIX_ARGZERO to reveal the name of the
> shell itself?  There's no way from inside a function to grab $0 from
> the caller unless the caller itself asserts NO_FUNCTION_ARGZERO.

Similar silliness that it may not be possible to fix, so maybe the
above isn't worth considering:

% describe-params '(#i)arg*' \?
integer-readonly-special '!'=0
integer-readonly-special '#'=10
array-readonly-special '*'=( '*' - '?' @ _ '$' 0 ARGC argv )
scalar-readonly-special -=569XZfims
integer-readonly-special '?'=1
array-readonly-special @=( @ _ '$' 0 ARGC argv )
scalar-special _=_
integer-readonly-special '$'=394907
scalar-special 0=describe-params
integer-readonly-special ARGC=2
array-special argv=( argv )

In case not obvious what I mean, $* and $@ and $argv should all have
the same elements, and $# and $ARGC should be equal to one another and
to the number of elements in the first three, but this can't be
preserved while using ARGC and shift to walk the names.  Also, $? is
nonzero because of the "if" test, and $_ is _ because that's the last
word of the command that prints the value of $_.  It's like trying to
examine quantum superposition.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 21:56                                         ` Bart Schaefer
@ 2023-01-22 22:02                                           ` Roman Perepelitsa
  2023-01-22 22:27                                             ` Bart Schaefer
  2023-01-22 23:03                                           ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-22 22:02 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

On Sun, Jan 22, 2023 at 10:57 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> On Sun, Jan 22, 2023 at 12:03 PM Bart Schaefer
> <schaefer@brasslantern.com> wrote:
> >
> > % describe-params 0
> > scalar-special 0=describe-params
> >
> > Would it be better to use POSIX_ARGZERO to reveal the name of the
> > shell itself?  There's no way from inside a function to grab $0 from
> > the caller unless the caller itself asserts NO_FUNCTION_ARGZERO.
>
> Similar silliness that it may not be possible to fix, so maybe the
> above isn't worth considering:
>
> % describe-params '(#i)arg*' \?
> integer-readonly-special '!'=0
> integer-readonly-special '#'=10
> array-readonly-special '*'=( '*' - '?' @ _ '$' 0 ARGC argv )
> scalar-readonly-special -=569XZfims
> integer-readonly-special '?'=1
> array-readonly-special @=( @ _ '$' 0 ARGC argv )
> scalar-special _=_
> integer-readonly-special '$'=394907
> scalar-special 0=describe-params
> integer-readonly-special ARGC=2
> array-special argv=( argv )
>
> In case not obvious what I mean, $* and $@ and $argv should all have
> the same elements, and $# and $ARGC should be equal to one another and
> to the number of elements in the first three, but this can't be
> preserved while using ARGC and shift to walk the names.  Also, $? is
> nonzero because of the "if" test, and $_ is _ because that's the last
> word of the command that prints the value of $_.  It's like trying to
> examine quantum superposition.

I think it would be better for this function to pretend that those
function-scoped parameters don't exist. If it were a builtin, it could
describe parameters such as `ARGC` or `1` in a way that makes sense,
but here the caller can only get confused if any answer is returned
for them at all.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 22:02                                           ` Roman Perepelitsa
@ 2023-01-22 22:27                                             ` Bart Schaefer
  0 siblings, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-22 22:27 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: zsh-users

On Sun, Jan 22, 2023 at 2:03 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> I think it would be better for this function to pretend that those
> function-scoped parameters don't exist.

I'm not happy about that because there's no way to distinguish them
without hard-coding a list of names, which (unlikely as this might be)
is not future-proof.

If they were tagged -local in $parameters that would make more sense
(but that'd mean adding a bunch of extra cases to zsh/parameter, it
just moves the problem).

And $? $_ $- aren't really function-scoped anyway.

> If it were a builtin, it could
> describe parameters such as `ARGC` or `1` in a way that makes sense

Don't have to worry about positionals, they're not in $parameters to begin with.

> but here the caller can only get confused if any answer is returned
> for them at all.

There's no reason not to return the ${(t)...} info.  I'm tempted to
just decide that if that includes "special" then any reported value is
caller-beware.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 21:11                                         ` Bart Schaefer
@ 2023-01-22 22:44                                           ` Ray Andrews
  2023-01-22 23:35                                             ` Lawrence Velázquez
                                                               ` (2 more replies)
  0 siblings, 3 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 22:44 UTC (permalink / raw)
  To: zsh-users

On 2023-01-22 13:11, Bart Schaefer wrote:

> That's obviously not true, or it would not have been possible to write
> describe-params.

Roman's version didn't reference typeset at all (tho yours does).   Not 
that typeset might not be *part* of the solution, but by itself it is 
poor -- thus the value of DP. You and Roman have both pointed out that 
typeset -p is more a way of recreating variables than it is of 
displaying them with type and value.  And if it is already adequate, why 
would DP even need to be written? But it isn't and it did.

Pardon Sensei, but you and Roman have solved a problem while at the same 
time you're claiming there was/is no problem to solve. Nope, DP is this 
dolphin's idea of a well written utility -- focused, simple, 
understandable, informative, complete, helpful and (I expect) with no 
ands, buts, ifs, maybes, exceptions, entanglements or gotchas of any 
kind.  man page will be a couple of sentences.  Software for mortals.  
Superb.  Many thanks! IMHO DP should be standard equipment -- part of 
the release.

(BTW, haven't run your version yet, waiting for Roman to sign off on it, 
but it will only get better.)

Dunno, but if it was up to me it would be built in as: typeset -D

man page:

... To display the type and the value of any parameter: typeset -D PARAM 
(wildcards accepted).

That simple.  Love it.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 21:56                                         ` Bart Schaefer
  2023-01-22 22:02                                           ` Roman Perepelitsa
@ 2023-01-22 23:03                                           ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 23:03 UTC (permalink / raw)
  To: zsh-users


On 2023-01-22 13:56, Bart Schaefer wrote:
> It's like trying to
> examine quantum superposition.
>
Obviously you guys decide these things, but from here it is ... well, 
how to say it ... I"d never  dream that DP would be reporting the 
positional params.  What you've done is pretty fine, that stuff that you 
call 'silliness' looks like exactly that. Leave '$*' out of it.  No 
point in answering a question that nobody is ever going to ask.  Dunno, 
maybe someone, somewhere wants 'DP  #' but I sure don't, I'd find some 
way of filtering stuff like that out.  But I shouldn't say anything.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 22:44                                           ` Ray Andrews
@ 2023-01-22 23:35                                             ` Lawrence Velázquez
  2023-01-22 23:58                                               ` Ray Andrews
  2023-01-23  1:11                                             ` Bart Schaefer
  2023-01-23 10:37                                             ` Roman Perepelitsa
  2 siblings, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-22 23:35 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023, at 5:44 PM, Ray Andrews wrote:
> You and Roman have both pointed out that 
> typeset -p is more a way of recreating variables than it is of 
> displaying them with type and value.  And if it is already adequate, why 
> would DP even need to be written?

It was not written to "fix" typeset -p; it was written to satisfy
your idiosyncratic preferences.


> Dunno, but if it was up to me it would be built in as: typeset -D
>
> man page:
>
> ... To display the type and the value of any parameter: typeset -D PARAM 
> (wildcards accepted).

This should absolutely not be done.


-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 23:35                                             ` Lawrence Velázquez
@ 2023-01-22 23:58                                               ` Ray Andrews
  2023-01-23  0:49                                                 ` Lawrence Velázquez
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-22 23:58 UTC (permalink / raw)
  To: zsh-users

On 2023-01-22 15:35, Lawrence Velázquez wrote:
>
> It was not written to "fix" typeset -p; it was written to satisfy
> your idiosyncratic preferences.
Neither Bart nor Roman would indulge me if there was no merit at all to 
what I want.  Spare the rod and spoil the child.  No ice-cream for 
breakfast.  If I'm wrong then I hafta buck up and learn to do things the 
way they are done.  But in this case I'm right -- what's idiosyncratic 
about wanting full information about a parameter along with it's value?  
What's ever wrong with complete information?
> This should absolutely not be done. 

Why not?  Honest question.  DP can of course remain as a stand-alone 
function, but what would harm if it were bolted in to typeset?  No axe 
to grind here, I have what I want, so I'm just wondering why other's 
shouldn't have it too.  Mind, I suppose core code should not be altered 
trivially.  So, sure, leave it as a function.  Devs decision.  But I 
hope the masses get decribe-params one way or another.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 23:58                                               ` Ray Andrews
@ 2023-01-23  0:49                                                 ` Lawrence Velázquez
  2023-01-23  1:33                                                   ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-23  0:49 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023, at 6:58 PM, Ray Andrews wrote:
> On 2023-01-22 15:35, Lawrence Velázquez wrote:
>>
>> It was not written to "fix" typeset -p; it was written to satisfy
>> your idiosyncratic preferences.
> Neither Bart nor Roman would indulge me if there was no merit at all to 
> what I want.

They are performing a kindness by giving you a tool that suits your
personal tastes.  Their generosity does not carry any broader
implications about how the shell should or should not behave.


> But in this case I'm right

Proclaiming your righteousness ad nauseam is not persuasive, and
you should stop doing it.


> what's idiosyncratic 
> about wanting full information about a parameter along with it's value?  
> What's ever wrong with complete information?

The shell already provides multiple methods of obtaining all this
information.  The fact that you don't like any of them does not
mean that it needs to sprout a new one.

Again, there's nothing wrong with that.  One of the purposes of a
shell is to empower users to construct their own tools.  This is
as it should be.


>> This should absolutely not be done. 
>
> Why not?  Honest question.  DP can of course remain as a stand-alone 
> function, but what would harm if it were bolted in to typeset?

Adding functionality always imposes a variety of costs, and typeset
is already overly complex.  The functionality you want to add is
just a repackaged version of existing functionality, so it does not
justify those costs.


> I'm just wondering why other's shouldn't have it too.

The zsh distribution is not the place to publish scripts written
to scratch your itches.


-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 22:44                                           ` Ray Andrews
  2023-01-22 23:35                                             ` Lawrence Velázquez
@ 2023-01-23  1:11                                             ` Bart Schaefer
  2023-01-23  1:56                                               ` Ray Andrews
  2023-01-23 10:37                                             ` Roman Perepelitsa
  2 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-23  1:11 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023 at 2:44 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-22 13:11, Bart Schaefer wrote:
>
> > That's obviously not true, or it would not have been possible to write
> > describe-params.
>
> Roman's version didn't reference typeset at all (tho yours does).

That's actually exactly my point:  It is not true that you had to
resort to "typeset" to get this information.  Everything you wanted
except the output formatting is available given the parameter name
itself, you don't even need the zsh/parameter module.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23  0:49                                                 ` Lawrence Velázquez
@ 2023-01-23  1:33                                                   ` Bart Schaefer
  2023-01-23  1:49                                                     ` Lawrence Velázquez
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-23  1:33 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users

On Sun, Jan 22, 2023 at 4:51 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> They are performing a kindness by giving you a tool that suits your
> personal tastes.

Well, that, and once Roman had started on it, it became an interesting
programming exercise.

> The zsh distribution is not the place to publish scripts written
> to scratch your itches.

However, there are plenty of scripts in Functions/Misc that fit this
description (e.g. ztodo, sticky-note) or in Functions/Example that are
just interesting for tutorial purposes (zless, zpgrep).  In fact we
ought to see if some of them have become obsolete (promptnl).  This
might fit there somewhere just because "interesting exercise."


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23  1:33                                                   ` Bart Schaefer
@ 2023-01-23  1:49                                                     ` Lawrence Velázquez
  0 siblings, 0 replies; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-23  1:49 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

On Sun, Jan 22, 2023, at 8:33 PM, Bart Schaefer wrote:
> On Sun, Jan 22, 2023 at 4:51 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>> The zsh distribution is not the place to publish scripts written
>> to scratch your itches.
>
> However, there are plenty of scripts in Functions/Misc that fit this
> description (e.g. ztodo, sticky-note) or in Functions/Example that are
> just interesting for tutorial purposes (zless, zpgrep).

Ah!  I had an notion that there was a "Contrib" directory, but when
I didn't see one I assumed I'd gotten confused by another project.

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23  1:11                                             ` Bart Schaefer
@ 2023-01-23  1:56                                               ` Ray Andrews
  2023-01-23  2:59                                                 ` Lawrence Velázquez
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-23  1:56 UTC (permalink / raw)
  To: zsh-users


On 2023-01-22 17:11, Bart Schaefer wrote:
> That's actually exactly my point: It is not true that you had to
> resort to "typeset" to get this information.  Everything you wanted
> except the output formatting is available given the parameter name
> itself, you don't even need the zsh/parameter module.
>
Whatever.  However.  I'm just happy to have something that works.  
Obviously the building blocks were there, I just didn't know how to find 
them.  Everything *seemed* to suggest that typeset -p was where you went 
for that kind of information.  I'm glad to learn otherwise.  Seems I was 
driving nails with a crosscut saw.  Now I have a hammer.  It's that 
simple and thanks again.  If I'd had DP ab ovo, this thread, and a few 
others like it, would never have been started cuz things would have been 
clear from the getgo.

> However, there are plenty of scripts in Functions/Misc that fit this

I don't understand Lawrence's perspective on this.  Can one have too many tools?  I suppose something could be so marginal that it's not worth it's weight but is DP really like that?  I doubt I'm the only person who finds that kind of information useful.  Lawrence spins it as some sort of fetish to want to see the type of a param and it's value at the same time.  I don't see this as anything like a contest.  The devs will make the right decision.  But from the peanut gallery I myself will always vote for what's simple, informative, and clear.  Those who like things that are convoluted, confusing, incomplete and obscure can have those things too.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23  1:56                                               ` Ray Andrews
@ 2023-01-23  2:59                                                 ` Lawrence Velázquez
  2023-01-23  3:47                                                   ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-23  2:59 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023, at 8:56 PM, Ray Andrews wrote:
> On 2023-01-22 17:11, Bart Schaefer wrote:
>> However, there are plenty of scripts in Functions/Misc that fit this
>
> I don't understand Lawrence's perspective on this.  Can one have too 
> many tools?

I would actually argue that the answer to your strawman question
is "yes", but as I implied in another message, I had been unaware
of (or had forgotten about) Functions/{Examples,Misc}.  Since those
directories already exist, I'd have no particular objection to
shipping your toy in one of them, if so desired.

> Lawrence spins it as some sort of fetish to want to see the type
> of a param and it's value at the same time.

What I actually said (as opposed to the lie you just told) is that
I think it is inappropriate for the shell to natively duplicate
functionality that already exists, merely to provide an alternate
visual representation that you personally like better.

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23  2:59                                                 ` Lawrence Velázquez
@ 2023-01-23  3:47                                                   ` Ray Andrews
  0 siblings, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-23  3:47 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: zsh-users

On 2023-01-22 18:59, Lawrence Velázquez wrote:
>
> I would actually argue that the answer to your strawman question
> is "yes",
Sure.  Sometimes merely the disk space used by a useless function should 
recommend it be purged.  I'll leave it to wiser people to make that 
decision in this case.  I like it, but it's 'official' fate is not my 
decision.
>
> What I actually said (as opposed to the lie you just told) is that
> I think it is inappropriate for the shell to natively duplicate
> functionality that already exists, merely to provide an alternate
> visual representation that you personally like better.

The output given by DP is unique otherwise it wouldn't have been 
written.  I'd rather say it harnesses exiting functionality in a useful 
way.  Every line of  computer software ever written is in some way a 
duplication of something that might be done by more primitive (using the 
term non-pejoratively I just mean by more basic) methods.  Programmers 
assemble simple instructions into more complex collections of 
instructions to achieve efficiency. DP is an example.  A dozen lines 
that give a very nice output IMHO.

BTW I'm not righteous, I'm a greasy plebe.  I'm usually wrong. This 
entire thread is a chain of mistakes on my part.  Mistakes within 
mistakes.  I've been with zsh almost 10 years and I still rate myself a 
C-.  But I have a talent for clarity and I know it when I see it.   
Occasionally I'm right, and this is one of those times.  But there's 
nothing to argue about, I'm not a dev and the decision is not mine. Your 
voice will carry far more weight than mine and that's as it should be.  
But I like it.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 22:44                                           ` Ray Andrews
  2023-01-22 23:35                                             ` Lawrence Velázquez
  2023-01-23  1:11                                             ` Bart Schaefer
@ 2023-01-23 10:37                                             ` Roman Perepelitsa
  2023-01-23 15:28                                               ` Ray Andrews
  2023-01-23 16:26                                               ` Bart Schaefer
  2 siblings, 2 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-23 10:37 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 22, 2023 at 11:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-22 13:11, Bart Schaefer wrote:
>
> > That's obviously not true, or it would not have been possible to write
> > describe-params.
>
> [...]
>
> (BTW, haven't run your version yet, waiting for Roman to sign off on it,
> but it will only get better.)

Me to sign off on Bart's code? Ha-ha :) I started using zsh in 2019
while Bart has been a contributor since the previous century. When
Bart and I disagree, it would be wise to go with his opinion by
default.

By the way, one thing bothers me about tied parameters. Is there
really no way (other than parsing the output of `typeset -p`) to
retrieve the name of the tied counterpart? Here's what I mean:

    % typeset -T FOO foo
    % tied-counterpart FOO
    foo
    % tied-counterpart foo
    FOO

How do you implement `tied-counterpart` that behaves as in the
(imaginary) transcript above?

Now that I think of it, there are a few more parameter properties that
aren't exposed through anything other than `typeset -p`.

    % typeset -i8 -R10 foo
    % typeset -p foo
    typeset -i8 -R10 foo=0
    % print -r -- ${(t)foo}
    integer-right_blanks

The numbers 8 and 10 cannot be retried from anywhere, right?

There is also at least one case where `typeset -p` is lossy.

    % typeset -F2 foo
    % typeset -p foo
    typeset -F foo=0.00

Note that the output is missing "2". Is this intended?

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23 10:37                                             ` Roman Perepelitsa
@ 2023-01-23 15:28                                               ` Ray Andrews
  2023-01-23 15:40                                                 ` zeurkous
  2023-01-23 16:26                                               ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-23 15:28 UTC (permalink / raw)
  To: zsh-users


On 2023-01-23 02:37, Roman Perepelitsa wrote:
> Me to sign off on Bart's code? Ha-ha :) I started using zsh in 2019
> while Bart has been a contributor since the previous century. When
> Bart and I disagree, it would be wise to go with his opinion by
> default.
NO!  2019?  And you've developed your skills this far?  In 4 years? 
Nuts, I have more 'seniority' that you?  That really does make me feel 
like a moron ;-)
> Now that I think of it, there are a few more parameter properties that
> aren't exposed through anything other than `typeset -p`.

That's the sort of thing that steams me.  Just for the principal of it.  
There are always these leaks and exceptions and maybes.  I suppose that 
such a big project must develop imperfections of that sort as it grows, 
still one could wish for one-stop shopping -- one command that shows you 
*every* property.  Dunno, surely this data is all stored in one place?  
Anyway, in practice DP is 99% of the way there.






^ permalink raw reply	[flat|nested] 119+ messages in thread

* RE: Re: path PATH
  2023-01-23 15:28                                               ` Ray Andrews
@ 2023-01-23 15:40                                                 ` zeurkous
  2023-01-23 16:02                                                   ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: zeurkous @ 2023-01-23 15:40 UTC (permalink / raw)
  To: Ray Andrews, zsh-users

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On Mon, 23 Jan 2023 07:28:11 -0800, Ray Andrews <rayandrews@eastlink.ca> wrote:
> That's the sort of thing that steams me.  Just for the principal of it. 

principle*

But yeah...
 
> There are always these leaks and exceptions and maybes.  I suppose that 
> such a big project must develop imperfections of that sort as it grows,

...you got it.

(In fact, me'd even argue that UNIX could use a "lessons-learned"
rewrite altogether. But that's once again beyond our purview.)

         --zeurkous.

-- 
Friggin' Machines!


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23 15:40                                                 ` zeurkous
@ 2023-01-23 16:02                                                   ` Ray Andrews
  2023-01-23 16:25                                                     ` zeurkous
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-23 16:02 UTC (permalink / raw)
  To: zsh-users

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


On 2023-01-23 07:40, zeurkous@blaatscaahp.org wrote:
> (In fact, me'd even argue that UNIX could use a "lessons-learned"
> rewrite altogether. But that's once again beyond our purview.)
>
>           --zeurkous.
You've read 'the cathedral and the bazaar' of course.  If I were a 
gazilionaire I'd pay some hotshots to rewrite the whole thing from the 
bedrock up -- build a cathedral.  Same with zsh -- pay the devs to 
really get things right.  Think Haussmann redoing Paris.

[-- Attachment #2: Type: text/html, Size: 1135 bytes --]

^ permalink raw reply	[flat|nested] 119+ messages in thread

* RE: Re: path PATH
  2023-01-23 16:02                                                   ` Ray Andrews
@ 2023-01-23 16:25                                                     ` zeurkous
  0 siblings, 0 replies; 119+ messages in thread
From: zeurkous @ 2023-01-23 16:25 UTC (permalink / raw)
  To: Ray Andrews, zsh-users

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

On Mon, 23 Jan 2023 08:02:10 -0800, Ray Andrews <rayandrews@eastlink.ca> wrote:
> This is a multi-part message in MIME format.
> --------------s8tUpr0M54E8X0ltYkQwh4uy
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit

Sigh.

> On 2023-01-23 07:40, zeurkous@blaatscaahp.org wrote:
>> (In fact, me'd even argue that UNIX could use a "lessons-learned"
>> rewrite altogether. But that's once again beyond our purview.)
>>
>>           --zeurkous.
> You've read 'the cathedral and the bazaar' of course. 

Yes, *many* moons ago. It is a remarkable work of apologism (a not
unknown feature of many of esr's writings), and as such rightfully did
not influence me opinion all that much.

        --zeurkous.
 
> If I were a 
> gazilionaire I'd pay some hotshots to rewrite the whole thing from the 
> bedrock up -- build a cathedral.  Same with zsh -- pay the devs to 
> really get things right.  Think Haussmann redoing Paris.
> --------------s8tUpr0M54E8X0ltYkQwh4uy
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> <html>
>   <head>
>     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>   </head>
>   <body>
>     <p><br>
>     </p>
>     <div class="moz-cite-prefix">On 2023-01-23 07:40,
>       <a class="moz-txt-link-abbreviated" href="mailto:zeurkous@blaatscaahp.org">zeurkous@blaatscaahp.org</a> wrote:<br>
>     </div>
>     <blockquote type="cite"
>       cite="mid:thinkcrap!zeurkous!1674488400.13351@uucp">(In fact, me'd
>       even argue that UNIX could use a "lessons-learned"
>       <pre class="moz-quote-pre" wrap="">rewrite altogether. But that's once again beyond our purview.)
>
>          --zeurkous.
> </pre>
>     </blockquote>
>     You've read 'the cathedral and the bazaar' of course.  If I were a
>     gazilionaire I'd pay some hotshots to rewrite the whole thing from
>     the bedrock up -- build a cathedral.  Same with zsh -- pay the devs
>     to really get things right.  Think <span
>       class="js-about-item-abstr">Haussmann redoing Paris.  <br>
>     </span>
>     <blockquote type="cite"
>       cite="mid:thinkcrap!zeurkous!1674488400.13351@uucp">
>       <pre class="moz-quote-pre" wrap="">
> </pre>
>     </blockquote>
>   </body>
> </html>
>
> --------------s8tUpr0M54E8X0ltYkQwh4uy--
>

-- 
Friggin' Machines!


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-23 10:37                                             ` Roman Perepelitsa
  2023-01-23 15:28                                               ` Ray Andrews
@ 2023-01-23 16:26                                               ` Bart Schaefer
  1 sibling, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-23 16:26 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users

On Mon, Jan 23, 2023 at 2:37 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> Me to sign off on Bart's code? Ha-ha :) I started using zsh in 2019
> while Bart has been a contributor since the previous century. When
> Bart and I disagree, it would be wise to go with his opinion by
> default.

On the other hand, that means there's a lot of stuff I've forgotten
that's fresh in your memory, and things I might take for granted that
you dig into.

> By the way, one thing bothers me about tied parameters. Is there
> really no way (other than parsing the output of `typeset -p`) to
> retrieve the name of the tied counterpart?

% typeset +m path
array tied PATH path

This DOES represent something that you can't get without "typeset",
and it's not exceptionally well documented:

          Except when assignments are made with NAME=VALUE, using +m
          forces the matching parameters and their attributes to be
          printed, even inside a function.  Note that -m is ignored if
          no patterns are given, so 'typeset -m' displays attributes but
          'typeset -a +m' does not.  Ordinary scalar string parameters
          have no attributes, so for those +m prints only the names.

> Now that I think of it, there are a few more parameter properties that
> aren't exposed through anything other than `typeset -p`.

% typeset -i8 -R10 foo
% typeset +m foo
integer 8 right justified 10 foo

>     % typeset -F2 foo
>     % typeset -p foo
>     typeset -F foo=0.00
>
> Note that the output is missing "2". Is this intended?

Almost certainly not.

% typeset +m foo
float foo


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:51                                   ` Bart Schaefer
  2023-01-22 19:56                                     ` Roman Perepelitsa
@ 2023-01-24 20:00                                     ` Ray Andrews
  2023-01-24 20:42                                       ` Bart Schaefer
  2023-01-24 23:28                                     ` Ray Andrews
  2 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-24 20:00 UTC (permalink / raw)
  To: zsh-users

Bart:

I'm chewing on your code, I understand everything but this:
> 	set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}

It can be omitted seemingly without consequence if there's only one arg, 
but it's needed if multiple.  Would you be so patient as to explain 
what's going on there?  It's too thick for me.






^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-24 20:00                                     ` Ray Andrews
@ 2023-01-24 20:42                                       ` Bart Schaefer
  2023-01-24 20:50                                         ` Bart Schaefer
  2023-01-24 20:54                                         ` Ray Andrews
  0 siblings, 2 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-24 20:42 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Jan 24, 2023 at 12:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> >       set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}

$parameters is an associative array, so you can subscript it with [ ]
to get the elements.  The keys of this array are parameter names.

${(.|.)var} means to join an array with vertical bars; here the var is
@ for the positional parameters.

${~something} means the value of something can be treated as a
pattern, so the |-joined positional parameters form a pattern.

(I) in an associative array subscript means to return every element
whose key matches a pattern, so instead of getting just one element it
is an array of elements.

(k) prefixing an associative array reference means to return the keys
(normally the values would be returned), so now we have an array of
parameter names.

(o) prefixing any array reference means to sort ("order") the results,
so we get the matching parameter names in alphabetical order.

"set --" replaces the original positional parameters with this array
of parameter names.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-24 20:42                                       ` Bart Schaefer
@ 2023-01-24 20:50                                         ` Bart Schaefer
  2023-01-24 20:54                                         ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-24 20:50 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Jan 24, 2023 at 12:42 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> ${(.|.)var} means to join an array with vertical bars

(j.|.) that is.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-24 20:42                                       ` Bart Schaefer
  2023-01-24 20:50                                         ` Bart Schaefer
@ 2023-01-24 20:54                                         ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-24 20:54 UTC (permalink / raw)
  To: zsh-users


On 2023-01-24 12:42, Bart Schaefer wrote:
>
>>>        set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}
> $parameters is an associative array, so you can subscript it with [ ]

Thanks.  Would have taken me a week to figure it all out.  One simply 
can't search for '(j.|.)' and home in on the answer, you hafta know head 
of time what kind of animal it is.  Inside out, vs. outside in.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-22 19:51                                   ` Bart Schaefer
  2023-01-22 19:56                                     ` Roman Perepelitsa
  2023-01-24 20:00                                     ` Ray Andrews
@ 2023-01-24 23:28                                     ` Ray Andrews
  2023-01-24 23:42                                       ` Bart Schaefer
  2 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-24 23:28 UTC (permalink / raw)
  To: zsh-users


On 2023-01-22 11:51, Bart Schaefer wrote:

     if [[ -${parameters[$1]}- = *-hideval-* ]]

The things we come across poking our noses into the workings:

'hideval' surely is clearly helpful when some params have values that no 
moral should ever look at. But maybe half of the hideval params are also 
marked 'hide', which ... well, what does that add?  Manual has nothing 
to say about it.  BTW I'd often wondered why so many params had 'no 
value'.  They do!  Just hidden.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-24 23:28                                     ` Ray Andrews
@ 2023-01-24 23:42                                       ` Bart Schaefer
  2023-01-25  0:14                                         ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-24 23:42 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Jan 24, 2023 at 3:28 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> 'hideval' surely is clearly helpful when some params have values that no
> moral should ever look at. But maybe half of the hideval params are also
> marked 'hide', which ... well, what does that add?  Manual has nothing
> to say about it.

This was actually mentioned earlier in this same thread.

On Sun, Jan 22, 2023 at 11:20 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> On Sun, Jan 22, 2023 at 4:30 AM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> >       [[ -$2- == *-hide-* ]] && return 1
>
> I'm curious why you chose to do this?  The "hide" attribute means that
> a local does not preserve semantics of a special global, not that it's
> name is invisible.

The manual DOES explain this.  Search "man zshall" for "hide", it's
about the 5th occurrence.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-24 23:42                                       ` Bart Schaefer
@ 2023-01-25  0:14                                         ` Ray Andrews
  2023-01-25 16:38                                           ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-25  0:14 UTC (permalink / raw)
  To: zsh-users


On 2023-01-24 15:42, Bart Schaefer wrote:
> This was actually mentioned earlier in this same thread. 

To be honest, when you guys have an issue in hand, I just wait for you 
to be finished before I try figure out what's going on. It's too hard to 
follow in real time.  Sorry for the duplication tho.

The manual DOES explain this. Search "man zshall" for "hide", it's
> about the 5th occurrence.
>
To be honest again, I searched for 'hideval' and scanned up and down 
from there.  'hide' is referred to but not explained.  And since 
'hideval' only occurs the one time (that I can see) and isn't explained 
I figured that 'hide' would be no different.  And that 'hide' out of 
context would probably show up a hundred times.  Pardon, that's just 
lazy on my part.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25  0:14                                         ` Ray Andrews
@ 2023-01-25 16:38                                           ` Ray Andrews
  2023-01-25 16:43                                             ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-25 16:38 UTC (permalink / raw)
  To: zsh-users


For purposes of cleaning up dead variables I sometimes want to list any 
unset params.  Before recent education I thought:

$ set | grep -E "bg$"

bg

... meant that bg was unset and now I know it's hidden.  (Nice if that 
was made more explicit.) So what would be a complete list of unset 
params?  This is close:

$ typeset -mp "*" | grep -e "=(  )$" -e "=''$" -e "=0$"

typeset ZLE_LINE_ABORTED=''
typeset -aT CDPATH cdpath=(  )
typeset -T CDPATH cdpath=(  )
typeset -aT MAILPATH mailpath=(  )
typeset -aT MANPATH manpath=(  )
typeset -T MANPATH manpath=(  )
typeset -a compprefuncs=(  )
typeset -aT WATCH watch=(  )
typeset cc=0
typeset -a zzz=(  )
typeset OPTARG=''
typeset -i10 UID=0
typeset KEYBOARD_HACK=''
typeset -i10 GID=0
typeset zz=''
typeset -aT FIGNORE fignore=(  )
typeset -T WATCH watch=(  )
typeset MATCH_FOUND=''
typeset -T MAILPATH mailpath=(  )
typeset -i zzzz=0
typeset -a comppostfuncs=(  )
typeset -T FIGNORE fignore=(  )
typeset _execute_input=''
typeset _execute_history=''
typeset -aT PSVAR psvar=(  )
typeset _execute_output=''
typeset -a z=(  )
typeset -a argv=(  )
typeset _execute_linecount=''
typeset varis_switches=''
typeset -T PSVAR psvar=(  )
typeset -i10 EUID=0
typeset -i10 EGID=0

... but probably there's others.

BTW, I very much doubt anything can be done about it, but I trust 
there's no way to distinguish between an unset integer and one 
explicitly set to zero?  Not that much will ever hinge on it.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 16:38                                           ` Ray Andrews
@ 2023-01-25 16:43                                             ` Roman Perepelitsa
  2023-01-25 16:56                                               ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-25 16:43 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Jan 25, 2023 at 5:38 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> So what would be a complete list of unset
> params?  This is close:
>
> $ typeset -mp "*" | grep -e "=(  )$" -e "=''$" -e "=0$"
>
> typeset ZLE_LINE_ABORTED=''
> [...]
> typeset -i10 EGID=0

All of these parameters are set. Here's how an unset parameter looks like:

    % typeset -p blah
    typeset: no such variable: blah

    % [[ -v blah ]] || print unset
    unset

    % (( ${+blah} )) || print unset
    unset

You can print the list of all unset parameters but the output will be
infinite. To do that, you start by enumerating all one-character names
and checking them against `[[ -v ]]`. Proceed with two-character
names, etc.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 16:43                                             ` Roman Perepelitsa
@ 2023-01-25 16:56                                               ` Ray Andrews
  2023-01-25 17:02                                                 ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-25 16:56 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 08:43, Roman Perepelitsa wrote:
>
> All of these parameters are set. Here's how an unset parameter looks like:

Maybe I'm using the wrong word.  How do we say set to nothing?

5 /aWorking/Zsh/Source/Wk 0 $ zzz=; typeset -m zzz
zzz=''

5 /aWorking/Zsh/Source/Wk 0 $ integer zzz=; typeset -m zzz
zzz=0

... param exists, but has no value (excepting the default zero for 
integers).



^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 16:56                                               ` Ray Andrews
@ 2023-01-25 17:02                                                 ` Roman Perepelitsa
  2023-01-25 17:34                                                   ` Ray Andrews
  2023-01-25 22:18                                                   ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-25 17:02 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Jan 25, 2023 at 5:58 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2023-01-25 08:43, Roman Perepelitsa wrote:
> >
> > All of these parameters are set. Here's how an unset parameter looks like:
>
> Maybe I'm using the wrong word.  How do we say set to nothing?
>
> 5 /aWorking/Zsh/Source/Wk 0 $ zzz=; typeset -m zzz
> zzz=''
>
> 5 /aWorking/Zsh/Source/Wk 0 $ integer zzz=; typeset -m zzz
> zzz=0
>
> ... param exists, but has no value (excepting the default zero for
> integers).

These parameters have values. The following three lines are equivalent
(assuming that foo isn't set beforehand):

    typeset foo
    typeset foo=
    typeset foo=""

These are also equivalent:

    typeset -i foo
    typeset -i foo=
    typeset -i foo=""
    typeset -i foo=0

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 17:02                                                 ` Roman Perepelitsa
@ 2023-01-25 17:34                                                   ` Ray Andrews
  2023-01-25 17:37                                                     ` Roman Perepelitsa
  2023-01-25 22:18                                                   ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-25 17:34 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 09:02, Roman Perepelitsa wrote:
> These parameters have values. The following three lines are equivalent

5 /aWorking/Zsh/Source/Wk 1 $ zzz=

5 /aWorking/Zsh/Source/Wk 1 $ echo "'$zzz'"
''

What is the value of zzz?  How can it be called anything but nothing?




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 17:34                                                   ` Ray Andrews
@ 2023-01-25 17:37                                                     ` Roman Perepelitsa
  2023-01-25 18:26                                                       ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-25 17:37 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Jan 25, 2023 at 6:34 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2023-01-25 09:02, Roman Perepelitsa wrote:
> > These parameters have values. The following three lines are equivalent
>
> 5 /aWorking/Zsh/Source/Wk 1 $ zzz=
>
> 5 /aWorking/Zsh/Source/Wk 1 $ echo "'$zzz'"
> ''
>
> What is the value of zzz?  How can it be called anything but nothing?

This value is usually called "empty" or "null". The parameter is not
unset though.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 17:37                                                     ` Roman Perepelitsa
@ 2023-01-25 18:26                                                       ` Ray Andrews
  2023-01-25 18:34                                                         ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-25 18:26 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 09:37, Roman Perepelitsa wrote:
>
> This value is usually called "empty" or "null". The parameter is not
> unset though.
>
Ah.  Ok, that's the correct terminology.  Yeah.  'unset' implies the var 
itself does not exist vs. having a null value.  So how can I check for 
all null parameters?  As previous, I think I'm pretty close.  I've 
noticed that over time editing functions, they can accumulate dead 
variables and the above is an effort to catch them.  Man, I thought this 
little exploration of the params was going to be simple ... not so!  
Come to that, how many fundamental types are there?  I mean an exported 
array is still, fundamentally an array.  A tied array is still an 
array.  But an associative array is a different sort of animal, so I 
have: scalar, integer, array, A array, .... what else?  There'll only be 
so many displays for null params and when I know them all I can catch 
them all.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 18:26                                                       ` Ray Andrews
@ 2023-01-25 18:34                                                         ` Roman Perepelitsa
  2023-01-25 19:00                                                           ` Ray Andrews
  2023-01-26  2:13                                                           ` Ray Andrews
  0 siblings, 2 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-25 18:34 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Jan 25, 2023 at 7:26 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-25 09:37, Roman Perepelitsa wrote:
> >
> > This value is usually called "empty" or "null". The parameter is not
> > unset though.
> >
> Ah.  Ok, that's the correct terminology.  Yeah.  'unset' implies the var
> itself does not exist vs. having a null value.  So how can I check for
> all null parameters?

You can use [[ -z ]] for that.

    for name in ${(k)parameters}; do
      if [[ -z ${(P)name} ]]; then
        print -r -- $name
      fi
    done

> Come to that, how many fundamental types are there?

There is ‘scalar’, ‘array’, ‘integer’, ‘float’ or ‘association’. I
copied it straight from the docs.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 18:34                                                         ` Roman Perepelitsa
@ 2023-01-25 19:00                                                           ` Ray Andrews
  2023-01-26  2:13                                                           ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-25 19:00 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 10:34, Roman Perepelitsa wrote:
> You can use [[ -z ]] for that.
>      for name in ${(k)parameters}; do
>        if [[ -z ${(P)name} ]]; then
>          print -r -- $name
>        fi
>      done
Excellent, it beats grepping for various endings.
> There is ‘scalar’, ‘array’, ‘integer’, ‘float’ or ‘association’. I
> copied it straight from the docs.

Section?  I'd like to read up on that.  As usual the biggest problem is 
knowing where to look for stuff.  Thanks Roman.

...

Stop being quite so lazy Ray .... found it :-)





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 17:02                                                 ` Roman Perepelitsa
  2023-01-25 17:34                                                   ` Ray Andrews
@ 2023-01-25 22:18                                                   ` Bart Schaefer
  2023-01-25 23:10                                                     ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-25 22:18 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users

On Wed, Jan 25, 2023 at 9:06 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> These parameters have values. The following three lines are equivalent
> (assuming that foo isn't set beforehand):
>
>     typeset foo
>     typeset foo=
>     typeset foo=""

Note in passing that if the TYPESET_TO_UNSET option is in effect, the
first of those three is not equivalent to the other two.

>     typeset -i foo

Similarly.

This exposes another case where only "typeset" can provide full information.

% typeset +m foo
integer foo
% printf "<%s>\n" $parameters[foo]
<>
%

The parameter is unset and so not in $parameters, but typeset
"remembers" that it is an integer.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 22:18                                                   ` Bart Schaefer
@ 2023-01-25 23:10                                                     ` Ray Andrews
  2023-01-25 23:19                                                       ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-25 23:10 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 14:18, Bart Schaefer wrote:
>
> Similarly.
>
> This exposes another case where only "typeset" can provide full information.
>
> % typeset +m foo
> integer foo
> % printf "<%s>\n" $parameters[foo]
> <>
> %
>
> The parameter is unset and so not in $parameters, but typeset
> "remembers" that it is an integer.
>
 From the stands, it look to me like describe-params has to be the 
way.   A new function is needed that cleans all this up, probably at the 
source code level.  Mind, I'm biased, I've never liked typeset.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 23:10                                                     ` Ray Andrews
@ 2023-01-25 23:19                                                       ` Bart Schaefer
  2023-01-26  0:55                                                         ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-25 23:19 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Jan 25, 2023 at 3:11 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>  From the stands, it look to me like describe-params has to be the
> way.

Part of the point here is that describe-params won't help in this
case.  Fortunately, typeset-to-unset is off by default (it's a POSIX
compatibility option).


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 23:19                                                       ` Bart Schaefer
@ 2023-01-26  0:55                                                         ` Ray Andrews
  0 siblings, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-26  0:55 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 15:19, Bart Schaefer wrote:
>
> Part of the point here is that describe-params won't help in this
> case.  Fortunately, typeset-to-unset is off by default (it's a POSIX
> compatibility option).
Not as a script/function but as C source I'll bet you could come up with 
full disclosure.   DP is at, what? 99%, but 100% is sweet.  Or maybe 
there as some things that will always dangle.  Like I was saying, I'll 
be there's no way to distinguish between 'integer int=0' and 'integer 
int='  ... you get zero either way.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-25 18:34                                                         ` Roman Perepelitsa
  2023-01-25 19:00                                                           ` Ray Andrews
@ 2023-01-26  2:13                                                           ` Ray Andrews
  2023-01-26  2:37                                                             ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-26  2:13 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 10:34, Roman Perepelitsa wrote:
> You can use [[ -z ]] for that.
>      for name in ${(k)parameters}; do
>        if [[ -z ${(P)name} ]]; then
>          print -r -- $name
>        fi
>      done

One small problem with that.  It seems to print all the values alright, 
but ends with:

"failed to find end of command substitution"

... you'd have tested it of course, so why that msg here?  Virgin shell 
reports the same msg.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26  2:13                                                           ` Ray Andrews
@ 2023-01-26  2:37                                                             ` Bart Schaefer
  2023-01-26  4:27                                                               ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-26  2:37 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Jan 25, 2023 at 6:13 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> "failed to find end of command substitution"

You've copy-pasted wrong somewhere and have $( where you should have ${


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26  2:37                                                             ` Bart Schaefer
@ 2023-01-26  4:27                                                               ` Ray Andrews
  2023-01-26 20:26                                                                 ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-26  4:27 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 18:37, Bart Schaefer wrote:
> On Wed, Jan 25, 2023 at 6:13 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> "failed to find end of command substitution"
> You've copy-pasted wrong somewhere and have $( where you should have ${
>

>      for name in ${(k)parameters}; do
>        if [[ -z ${(P)name} ]]; then
>          print -r -- $name
>        fi
>      done
>
That's what I'm running.  I suspected the same thing but ....


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26  4:27                                                               ` Ray Andrews
@ 2023-01-26 20:26                                                                 ` Ray Andrews
  2023-01-26 20:29                                                                   ` Roman Perepelitsa
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-26 20:26 UTC (permalink / raw)
  To: zsh-users


On 2023-01-25 20:27, Ray Andrews wrote:

> You've copy-pasted wrong somewhere and have $( where you should have ${
>>
>
>>      for name in ${(k)parameters}; do
>>        if [[ -z ${(P)name} ]]; then
>>          print -r -- $name
>>        fi
>>      done
>>
> That's what I'm running.  I suspected the same thing but ....

Strange, I fired up the computer today, run exactly the same command and 
no message.  Fool around for a while and it comes back.  Restart shell 
... no change.  Restart terminal and it goes away.  I'll try to figure 
out exactly what triggers it.  Must be some environment corruption.

Bart:

In your (temporarily name-shortened) describe-params, I'm trying to 
capture the output to a variable for further processing:

#describe-params ()
dp ()
{
     emulate -L zsh -o extendedglob
ddescribeparams=()
local line=
     set -- ${(ok)parameters[(I)${~${(j.|.)@}}]}
     while ((ARGC))
     do
#        print -rn -- "${parameters[$1]} "
         line+="${parameters[$1]} "
         if [[ -${parameters[$1]}- = *-hideval-* ]]
         then
             # If param is hidden, typeset won't show anything so use this:
#            print -r -- ${(q-)1}
             line+="${(q-)1}"
         else
#            typeset -m -- ${(b)1}
             line+=$( typeset -m -- ${(b)1} )
         fi
ddescribeparams+="$line"
line=
     shift
     done
print -l -- $ddescribeparams
}

...

             line+=$( typeset -m -- ${(b)1} )

... isn't working with eg:

$ typeset -m yellow

yellow=$'\C-[[33;1m'

... the predictable thing is happening and the color code gets applied 
and my terminal turns yellow.  How can I capture the value of yellow 
without that problem?  I've run into this before but I can't remember 
the solution.







^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 20:26                                                                 ` Ray Andrews
@ 2023-01-26 20:29                                                                   ` Roman Perepelitsa
  2023-01-26 20:59                                                                     ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-26 20:29 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Jan 26, 2023 at 9:27 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> print -l -- $ddescribeparams

Add -r.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 20:29                                                                   ` Roman Perepelitsa
@ 2023-01-26 20:59                                                                     ` Ray Andrews
  2023-01-26 21:17                                                                       ` Bart Schaefer
  2023-01-26 21:41                                                                       ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-26 20:59 UTC (permalink / raw)
  To: zsh-users


On 2023-01-26 12:29, Roman Perepelitsa wrote:
> On Thu, Jan 26, 2023 at 9:27 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> print -l -- $ddescribeparams
> Add -r.
>
> Roman.
>
Ah!  Damn, I know that.  I was fooling around with quotes and single 
quotes and protected quotes and '${(Q-continuum) }| '  ... barking up 
every tree but the right one.  And I know better! Tx.

BTW, reading up on the types, the doc seems rather incomplete.  I 
identify: scalar, array, association, integer, float, float-double, and 
modifiers: hideval, hide, readonly, special, tied, unique, export(ed), 
undefined and local ... but the doc only mentions some of them in 
passing, there's only explicit explanation of a few of them -- that I 
can find.  eg 'hideval' is only mentioned twice and then only in passing.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 20:59                                                                     ` Ray Andrews
@ 2023-01-26 21:17                                                                       ` Bart Schaefer
  2023-01-26 21:41                                                                       ` Bart Schaefer
  1 sibling, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-26 21:17 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Jan 26, 2023 at 1:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
=> BTW, reading up on the types, the doc seems rather incomplete.  I
> identify: scalar, array, association, integer, float, float-double, and

"double" is effectively just a modifier also, the basic type is still float.

> modifiers: hideval, hide, readonly, special, tied, unique, export(ed),
> undefined and local ... but the doc only mentions some of them in
> passing, there's only explicit explanation of a few of them -- that I
> can find.

That's because those words were chosen to have an obvious mapping onto
the switches accepted by the typeset command, and it didn't seem
necessary to explain the switches twice.

double = -E
hideval = -H
hide = -h
readonly = -r

etc.  The only one that doesn't have such a direct mapping is
"special", which just means it's known internally to zsh so
referencing or changing its value might have side-effects.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 20:59                                                                     ` Ray Andrews
  2023-01-26 21:17                                                                       ` Bart Schaefer
@ 2023-01-26 21:41                                                                       ` Bart Schaefer
  2023-01-26 21:44                                                                         ` Bart Schaefer
  2023-01-26 22:18                                                                         ` Ray Andrews
  1 sibling, 2 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-26 21:41 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Jan 26, 2023 at 1:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> undefined and local ... but the doc only mentions some of them

Where did you find "undefined" that led you to think it's a parameter modifier?


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 21:41                                                                       ` Bart Schaefer
@ 2023-01-26 21:44                                                                         ` Bart Schaefer
  2023-01-26 22:36                                                                           ` Ray Andrews
  2023-01-26 22:18                                                                         ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-26 21:44 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Jan 26, 2023 at 1:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Where did you find "undefined" that led you to think it's a parameter modifier?

Oh ... parameters autoloadable from a module that haven't yet been
loaded.  That's a bit of an odd case.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 21:41                                                                       ` Bart Schaefer
  2023-01-26 21:44                                                                         ` Bart Schaefer
@ 2023-01-26 22:18                                                                         ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-26 22:18 UTC (permalink / raw)
  To: zsh-users


On 2023-01-26 13:41, Bart Schaefer wrote:
> On Thu, Jan 26, 2023 at 1:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> undefined and local ... but the doc only mentions some of them
> Where did you find "undefined" that led you to think it's a parameter modifier?

Nuts, where did I see it?  Things very loose here right now, too many 
irons in the fire.  But it showed up.  Then I tried to find it in the 
doc and saw this:

If  no  attribute flags are given, and either no name arguments are present
               or the flag +m is used, then each parameter name printed 
is preceded  by  a
               list  of  the  attributes  of that parameter (array, 
association, exported,
               float, integer, readonly, or

                                                        undefined

         for autoloaded  parameters  not  yet
               loaded).   If  +m is used with attribute flags, and all 
those flags are in‐
               troduced with +, the matching parameter names are printed 
but their  values
               are not.

... I did see it.


>


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 21:44                                                                         ` Bart Schaefer
@ 2023-01-26 22:36                                                                           ` Ray Andrews
  2023-01-26 22:43                                                                             ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-26 22:36 UTC (permalink / raw)
  To: zsh-users


On 2023-01-26 13:44, Bart Schaefer wrote:
> On Thu, Jan 26, 2023 at 1:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>> Where did you find "undefined" that led you to think it's a parameter modifier?
> Oh ... parameters autoloadable from a module that haven't yet been
> loaded.  That's a bit of an odd case.

With no one place where all these modifiers are discussed, it's sorta 
like an Easter egg hunt -- one collects modifiers as one finds new 
examples here and there.  I probably still haven't found all of them.  I 
admit that it becomes a bit of an obsession more than a practical matter 
but when I decide I want a list of *all* of the types/modifiers, I want 
a list of *all* of them.  Dunno, it's the stamp-collector's mentality I 
suppose.  And to think that I thought that typeset -p gave us the 
complete story.

BTW, trivial bit of hair-splitting, but the doc says that, eg, integers 
*are* scalars -- uses scalar like a category -- I thought a var was a 
scalar *or* an integer.  That is, scalar is a type, not a family of 
types.  I think that's what we do in practice anyway so it's a bit 
unimportant.





>


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 22:36                                                                           ` Ray Andrews
@ 2023-01-26 22:43                                                                             ` Bart Schaefer
  2023-01-27  0:19                                                                               ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-26 22:43 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Jan 26, 2023 at 2:36 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> BTW, trivial bit of hair-splitting, but the doc says that, eg, integers
> *are* scalars -- uses scalar like a category

This is true.  A scalar is anything that substitutes only a single
value, as distinct from an array that substitutes multiple values.

scalar
  (string, the default and not given a distinct name)
  integer
  float (including double-precision)
array
  (of string, the default)
  associative array (aka "association" or "hash" or "hash table")

Any single element of an array is also a scalar, at least at this time
-- we don't support compound data types.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-26 22:43                                                                             ` Bart Schaefer
@ 2023-01-27  0:19                                                                               ` Ray Andrews
  2023-01-27  3:36                                                                                 ` Ray Andrews
  2023-01-27 17:51                                                                                 ` Ray Andrews
  0 siblings, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-27  0:19 UTC (permalink / raw)
  To: zsh-users


On 2023-01-26 14:43, Bart Schaefer wrote:
>
> This is true.  A scalar is anything that substitutes only a single
> value, as distinct from an array that substitutes multiple values.

Now that you mention it, that's logical.  Mind, then we need a word for 
a 'plain' scalar, vs. say in integer.    Yeah, I see the point.   Mind, 
in practice context pretty much makes the meaning clear.   OTOH, for a C 
coder the ambiguity of shell data types is disturbing, but I guess 
that's the way it always has been and always will be.  I still find 
myself 'declaring' all my variables even if I don't have to.





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-27  0:19                                                                               ` Ray Andrews
@ 2023-01-27  3:36                                                                                 ` Ray Andrews
  2023-01-27 17:51                                                                                 ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-27  3:36 UTC (permalink / raw)
  To: zsh-users

4 /aWorking/Zsh/Source/Wk 0 $ typeset -F zzz

4 /aWorking/Zsh/Source/Wk 0 $ typeset -E zzzz

4 /aWorking/Zsh/Source/Wk 0 $ dp "zzz*"
float   zzz = 0.0000000000
float   zzzz = 0.000000000e+00

... wouldn't it make sense to identify the double float as 'double'? Or 
something to distinguish it from the other?  These long-form type 
descriptions would seem to be crisply unambiguous apart from that exception.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-27  0:19                                                                               ` Ray Andrews
  2023-01-27  3:36                                                                                 ` Ray Andrews
@ 2023-01-27 17:51                                                                                 ` Ray Andrews
  2023-01-27 20:45                                                                                   ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-27 17:51 UTC (permalink / raw)
  To: zsh-users


Finally have what I thought I had: the full story on PATH path:


3 /aWorking/Zsh/Source/Wk 0 $ . test1; vv path

Stes  PATH = 
.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin
Ats   path = ( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin 
/usr/sbin /usr/bin ) ...

Here's the legend, from the accompanying help:

TYPES: These are condensed from the detailed information you can see 
like this: '$ print ${(t)path}'.  Basic types are capitalized, modifiers 
are in lower case:

S: An ordinary scalar (not an integer or float).
I: An integer.
F: A float ('typeset -F:' decimal display or 'typeset -E': scientific 
display).
A: A normal array.
H: An associative array or 'association' or 'hash' (always 'hideval' as 
well).
e: The variable has been exported to the environment and is thus 
persistent within that terminal -- it will be inherited by subshells.
l: The variable is local to the running function.
t: The variable is 'tied' to another variable (see docs: 'typeset -T').
s: The variable is special to the shell.
r: The variable is read-only (this often goes with 'special').
v: 'hideval': the value of the variable will be hidden -- there are 
things we really don't want to see, like lists of color codes.  This 
tends to go with 'special' and 'hide'.
h: Hide: Used with 'special' (see docs: 'typeset -h').
u: Unique: ??(no documentation found).
?: Undefined: For autoloaded parameters not yet loaded (whatever that 
means).
"

... edits and corrections most welcome.  Have I missed any?


3 /aWorking/Zsh/Source/Wk 0 $ vv "z*"

S     Z = /aWorking/Zsh
A     zle_bracketed_paste = ( $'\C-[[?2004h' $'\C-[[?2004l' )
S     ZSH_ARGZERO = zsh
S     ZSHBOOT = /aWorking/Zsh/Boot
Srts  ZSH_EVAL_CONTEXT = toplevel:shfunc:cmdsubst
Arts  zsh_eval_context = ( toplevel shfunc cmdsubst )
S     ZSH_NAME = zsh
S     ZSH_PATCHLEVEL = debian/5.8-6+deb11u1
Arhvs zsh_scheduled_events = !hidden!
Irs   ZSH_SUBSHELL = 1
S     ZSH_VERSION = 5.8





^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-27 17:51                                                                                 ` Ray Andrews
@ 2023-01-27 20:45                                                                                   ` Bart Schaefer
  2023-01-27 21:09                                                                                     ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-27 20:45 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Jan 27, 2023 at 9:51 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> t: The variable is 'tied' to another variable (see docs: 'typeset -T').
>
> ... edits and corrections most welcome.  Have I missed any?

You'll probably never see it, but "typeset -t" puts a "tag" on the
variable.  This is completely meaningless to anything/anyone except
program(mer)s using "typeset -t" and I have no recollection of the
use-case for which it was added.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-27 20:45                                                                                   ` Bart Schaefer
@ 2023-01-27 21:09                                                                                     ` Ray Andrews
  2023-01-27 23:45                                                                                       ` scowles
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-27 21:09 UTC (permalink / raw)
  To: zsh-users


On 2023-01-27 12:45, Bart Schaefer wrote:
> On Fri, Jan 27, 2023 at 9:51 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> t: The variable is 'tied' to another variable (see docs: 'typeset -T').
>>
>> ... edits and corrections most welcome.  Have I missed any?
> You'll probably never see it, but "typeset -t" puts a "tag" on the
> variable.  This is completely meaningless to anything/anyone except
> program(mer)s using "typeset -t" and I have no recollection of the
> use-case for which it was added.

There's always one more thing.  As you say, it sounds pretty marginal.  
Anyway I'm happy that:

0 /aWorking/Zsh/Source/Wk 0 $ typeset -p path
typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

is now:

1 /aWorking/Zsh/Source/Wk 0 $ v path

Stes  PATH = 
.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin
Ats   path = ( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin 
/usr/sbin /usr/bin ) ...

... so all the confusions and incorrect assumptions the former lead me 
to are now clarified.  Thanks for the help, it was a trail of tears.  
More work un-learning the wrong stuff than learning the right stuff.



>


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-27 21:09                                                                                     ` Ray Andrews
@ 2023-01-27 23:45                                                                                       ` scowles
  2023-01-28  0:12                                                                                         ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: scowles @ 2023-01-27 23:45 UTC (permalink / raw)
  To: zsh-users; +Cc: Ray Andrews


On Fri, 27 Jan 2023, Ray Andrews wrote:

> Date: Fri, 27 Jan 2023 13:09:41
> From: Ray Andrews <rayandrews@eastlink.ca>
> To: zsh-users@zsh.org
> Subject: Re: path PATH
>
> On 2023-01-27 12:45, Bart Schaefer wrote:
>> On Fri, Jan 27, 2023 at 9:51 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>>> t: The variable is 'tied' to another variable (see docs: 'typeset -T').
>>>
>>> ... edits and corrections most welcome.  Have I missed any?
>> You'll probably never see it, but "typeset -t" puts a "tag"...
>
> ...
> Anyway I'm happy that:
>
> 0 /aWorking/Zsh/Source/Wk 0 $ typeset -p path
> typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin
> /usr/sbin /usr/bin )
>
> is now:
>
> 1 /aWorking/Zsh/Source/Wk 0 $ v path
> ...


as a lurker on the list, i am very grateful that you, ray, persevered through 
this thread.  if dp(){} has changed since yesterday, would you mind posting your 
latest version?

the details from bart, roman, and mikael in both of these related threads ( -Re: 
path PATH, -Re: A way to untie -T vars?) have been quite helpful.


--


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-27 23:45                                                                                       ` scowles
@ 2023-01-28  0:12                                                                                         ` Ray Andrews
  2023-01-28  3:47                                                                                           ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-28  0:12 UTC (permalink / raw)
  To: zsh-users


On 2023-01-27 15:45, scowles@ckhb.org wrote:
>
> as a lurker on the list, i am very grateful that you, ray, persevered 
> through this thread.  if dp(){} has changed since yesterday, would you 
> mind posting your latest version?
>
The guts of it are almost exactly as Bart left it, but my version tarts 
it up a little bit:

A few notes: 'infomsg' is just a colored message, 'echo' is fine. ${cyn} 
is just the color code for cyan, and ${nrm} is the code for 'normal'.  I 
like colored output.  As I have it, the accumulated output goes to a 
variable instead of printing directly but the old code is there too.  
And I've shortened the type-strings to single letters but that's easy to 
cut out if you want.  Oh, and I also truncate at screen width but that's 
also easy to cut out.  I Don't need to see those huge variables full length:

function v () # For 'variables'.
{
     [[ "$1" = '-h' || "$1" = '-s' ]] && \
     {
     infomsg "
List attributes and values of all variables indicated by FILTER.

v ,CSsp [FILTER]

v ,C: SENS: (if FILTER is given).
v ,S: Show only if the value is not hidden.
v ,s: Show only if the value IS hidden.
v ,p: Plain, no color, this is good when the output needs to be sent to 
a file.

FILTER: if given, is a pattern of variable names.  If wildcards are 
given then the argument must be quoted to avoid expansion by the shell.

TYPES: These are condensed from the detailed information you can see 
like this: '$ print ${(t)path}'.  Basic types are capitalized, modifiers 
are in lower case:

S: An ordinary scalar (not an integer or float).
I: An integer.
F: A float ('typeset -F:' decimal display or 'typeset -E': scientific 
display).
A: A normal array.
H: An associative array or 'association' or 'hash' (always 'hideval' as 
well).
e: The variable has been exported to the environment and is thus 
persistent within that terminal -- it will be inherited by subshells.
l: The variable is local to the running function.
t: The variable is 'tied' to another variable (see docs: 'typeset -T').
s: The variable is special to the shell.
r: The variable is read-only (this often goes with 'special').
v: 'hideval': the value of the variable will be hidden -- there are 
things we really don't want to see, like lists of color codes.  This 
tends to go with 'special' and 'hide'.
h: Hide: Used with 'special' (see docs: 'typeset -h').
u: Unique: ??
?: Undefined: For autoloaded parameters not yet loaded (whatever that 
means).
"
return
     }
     local ccolored=( sed -r "s/^(.{6})([^ = ]*)/\1${cyn}\2${nrm}/" )
     local hhidden=( )

     local case='(#i)'
     local width=$(( COLUMNS - 5 ))
     local line=
     typeset -ga VARIABLES=()

     if [[ ${1:0:1} == ',' ]]; then
     for ((i=1; i < ${#1}; i++)); do
     case ${1:$i:1} in
         C ) case= ;; # Enable case sensitive.
         p ) ccolored= ;; # 'plain': no color.
         S ) hhidden=( grep -v ' = !hidden!' ) ;;    # Show only if a 
value is set.
         s ) hhidden=( grep ' = !hidden!' ) ;; # Show only if a value is 
NOT set.
         * ) errormsg "No such switch \",${1:$i:1}\""; return 1 ;;
         esac
     done
     shift
     fi      # End: process ',' switches.

     # If a capital letter is given then force case sensitivity:
     [[ $@ == *[[:upper:]]* ]] && case=

     # Default is all params:
     [ ! "$@" ] && set 1 '*'

     set -- ${(ok)parameters[(I)${case}${~${(j.|.)@}}]}
     while ((ARGC)); do
         # Type eg: 'scalar '
#        print -rn -- "${parameters[$1]} "
         line+="${parameters[$1]} "
         if [[ -${parameters[$1]}- = *-hideval-* ]]
         then
             # Append name and '=-hidden-'
             # If param is hidden, typeset won't show anything so use this:
#            print -r -- ${(q-)1}
             line+="${(q-)1}=!hidden!"
         else
             # Append name and value eg: 'ZSH_VERSION=5.8':
#            typeset -m -- ${(b)1}
             line+=$( typeset -m -- ${(b)1} )
         fi
     VARIABLES+="$line"
     line=
     shift
     done

     echo
     [ ! "$VARIABLES" ] && warningmsg "Nothing found" && return 1

print -rl -- $VARIABLES | sed \
-re "s/(^[^ ]*) ([^=]*)=(.*)/\1   \2 = \3/" \
  -e "s/scalar[ |-]/S/" \
  -e "s/integer[ |-]/I/" \
  -e "s/float[ |-]/F/" \
  -e "s/array[ |-]/A/" \
  -e "s/association[ |-]/H/" \
  -e "s/export[ |-]/e/" \
  -e "s/local[ |-]/l/" \
  -e "s/special[ |-]/s/" \
  -e "s/readonly[ |-]/r/" \
  -e "s/hideval[ |-]/v/" \
  -e "s/hide[ |-]/h/" \
  -e "s/tied[ |-]/t/" \
  -e "s/unique[ |-]/u/" \
  -e "s/undefined[ |-]/?/" \
  -e "s/^([^ ]*)/\1     /" \
  -e "s/^(.{6}) */\1/" \
  -e "s/^(.{1,${width}}).*/\1/" \
  -e "s/^(.{$width})/\1 .../" \
  | ${ccolored:-cat} | ${hhidden:-cat}

} # END: v()

allvars ()
{
     # Name and type:
     print -l -- "\n${cyn}ALL VARIABLES AND THEIR TYPES:${nrm} \n"
     printf "%-25s %s\n" ${(kv)parameters} | sort
     # Types only:
#    printf "%s\n" ${(v)parameters} | sort
}

nullvars ()
{
     # emulate -L zsh -o extendedglob
     nnullvars=()
     for name in ${(k)parameters}; do
         if [[ -z ${(P)name} ]]; then
#        print -r -- $name
             nnullvars+="$name"
         fi
     done

     print -l -- "\n${cyn}NULL VARIABLES:${nrm} \n"
     print -l -- "$nnullvars[@]" | sort
}

... hope you like it!




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-28  0:12                                                                                         ` Ray Andrews
@ 2023-01-28  3:47                                                                                           ` Bart Schaefer
  2023-01-28 16:42                                                                                             ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-28  3:47 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Jan 27, 2023 at 4:12 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>      local ccolored=( sed -r "s/^(.{6})([^ = ]*)/\1${cyn}\2${nrm}/" )
>      local hhidden=( )
>
>      local case='(#i)'
>      local width=$(( COLUMNS - 5 ))
>      local line=
>      typeset -ga VARIABLES=()

All of these are going to obscure the types of any variables in the
surrounding scope that share those names.  That's one reason I was
careful not to use any locals in my function.

> print -rl -- $VARIABLES | sed \

Does this do the right thing if you have a variable named $scalar (or
$array, etc.?)

It'd be better to convert the value of ${parameters[$1]} as you find
it, rather than build the whole output and then rewrite it.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-28  3:47                                                                                           ` Bart Schaefer
@ 2023-01-28 16:42                                                                                             ` Ray Andrews
  2023-01-28 22:51                                                                                               ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-28 16:42 UTC (permalink / raw)
  To: zsh-users


On 2023-01-27 19:47, Bart Schaefer wrote:
> typeset -ga VARIABLES=()
> All of these are going to obscure the types of any variables in the
> surrounding scope that share those names.  That's one reason I was
> careful not to use any locals in my function.
I noticed that.  The only 'local's shown are the funcs internal ones.  
Could give 'em names unlikely to be used elsewhere.  I've seen that sort 
of thing.  Or is there a better way?  Given the branching and switches, 
I can't think how to do it in one string of pipes w.o. intermediate 
variables.  And variables to hold the switches.
>
>> print -rl -- $VARIABLES | sed \
> Does this do the right thing if you have a variable named $scalar (or
> $array, etc.?)
I take it for granted that my colorizing and various condensations and 
formattings are always going to leak, but they're not mission critical 
just efforts to make things look better most of the time. When I find a 
leak I patch it if I can.  Still it's a good thing to do things in the 
most robust way of course.
>
> It'd be better to convert the value of ${parameters[$1]} as you find
> it, rather than build the whole output and then rewrite it.

Well, the paint isn't even dry on that effort I posted. Improvements 
most welcome.  As I have it now, it's just sequential thinking -- first  
get the core functionality, then add the switches (case, etc.) then 
massage the output.  No doubt it can be handled better.  It's C- coding.

Anyway the whole exercise is just a 'cry for help' -- typeset -p (or 
typeset -P) should give us full disclosure.  display-params() should be 
hard coded and, IMHO, accessed via a switch to typeset. Wiser people 
disagree, but that's my two cents.  Nuts, there's already, what? three 
or five functions that sorta attempt to display this information but 
none of them shows it all.  Seems to me a full listing of params with 
*all* attributes and values is core functionality.

And the doc should discuss *all* the attributes in one place. Every last 
one. </whine> :-)




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-28 16:42                                                                                             ` Ray Andrews
@ 2023-01-28 22:51                                                                                               ` Bart Schaefer
  2023-01-29  2:30                                                                                                 ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-28 22:51 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 28, 2023 at 8:42 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Could give 'em names unlikely to be used elsewhere.  I've seen that sort
> of thing.  Or is there a better way?  Given the branching and switches,
> I can't think how to do it in one string of pipes w.o. intermediate
> variables.  And variables to hold the switches.

You're already resorting to a subshell for
>              line+=$( typeset -m -- ${(b)1} )
So why not get rid of "line", go back to printing everything to
stdout, and (if you still need to) put the entire function call in
$(...) ?  Instead of forking for each parameter, fork once for the
whole main body of the function.

As far as I can tell, "case" is the only bit that matters to finding
the parameter names (although you could do hidden/not without piping
to grep).

So your $case is for example ${~${1:#*C*}:-'(#i)'} which you can feed
into the arguments of dp.

Take a look at the way the "untie" function I posted elsewhere takes
care of managing the list of typeset switches needed to preserve the
attributes of the parameter that's left behind after untying.

> Anyway the whole exercise is just a 'cry for help' -- typeset -p (or
> typeset -P) should give us full disclosure.

You're the first person in 30+ years to ask for this, so it's not
surprising that it hasn't been done so far.  I still don't really
grasp why this is helpful to you (especially when what you do with is
it squash it down to a bunch of cryptic one-letter abbreviations).

> And the doc should discuss *all* the attributes in one place.

They are all discussed in the documentation for "typeset", they're
just not all laid out in a table.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-28 22:51                                                                                               ` Bart Schaefer
@ 2023-01-29  2:30                                                                                                 ` Ray Andrews
  2023-01-29  3:03                                                                                                   ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-29  2:30 UTC (permalink / raw)
  To: zsh-users


On 2023-01-28 14:51, Bart Schaefer wrote:

> So why not get rid of "line", go back to printing everything to 

...

Heavy duty suggestions.  The difference between your level and my 
level.  If it wasn't presumptuous I'd just ask you to clean it up for me 
and then I'd study the changes.  Otherwise I'll see if I can understand 
and implement.  I know my code is amateurish.   Ah, for a master class, 
where I could have all my code critiqued.
> You're the first person in 30+ years to ask for this, so it's not
> surprising that it hasn't been done so far.
Can't argue with that.  OTOH most people conform their expectations to 
what's currently available -- basically they only ask for what they 
have.  But if better information were available, they might very well 
come to value and expect that.  Not to wander too far off topic but 
Windows users think that Windows is 'the universe' and that there's 
nothing more or better to even be contemplated.  And when you tell them 
that there is more and better, they aren't even interested cuz it would 
involve expanding their tiny minds.
> I still don't really
> grasp why this is helpful to you (especially when what you do with is
> it squash it down to a bunch of cryptic one-letter abbreviations).

1 /aWorking/Zsh/Source/Wk 1 $ v path

Stes  PATH = 
.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin

Ats   path = ( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin 
/usr/sbin /usr/bin ) ...

... because the above is accurate.  If that information had been 
(easily) available to me, this thread would never have been started.   
What is a tied variable?  As we see, a scalar is created from an array, 
named in all caps, and then exported.  As it was:


0 /aWorking/Zsh/Source/Wk 0 $ typeset -p PATH
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

... and I'm interpreting that as saying that PATH and path are two 
different names for the same var.  It seems like so long ago :(

The expanded 'full-word' descriptions are of course available, but with 
the compressed form one has room for the value too.  Once I sort out 
your suggestions above I think I'll add a 'full word' switch, but 
without the values.  Mind I already have that with:


0 /aWorking/Zsh/Source/Wk 0 $ allvars

ALL VARIABLES AND THEIR TYPES:

$                         integer-readonly-special
0                         scalar-special
aa                        scalar
a                         integer
aliases                   undefined
ARGC                      integer-readonly-special

...

zsh_eval_context          array-readonly-tied-special
ZSH_EVAL_CONTEXT          scalar-readonly-tied-special
ZSH_NAME                  scalar
ZSH_PATCHLEVEL            scalar
zsh_scheduled_events      undefined
ZSH_SUBSHELL              integer-readonly-special
ZSH_VERSION               scalar

... work in progress of course.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29  2:30                                                                                                 ` Ray Andrews
@ 2023-01-29  3:03                                                                                                   ` Bart Schaefer
  2023-01-29  3:44                                                                                                     ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-29  3:03 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 28, 2023 at 6:31 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2023-01-28 14:51, Bart Schaefer wrote:
>
> > I still don't really
> > grasp why this is helpful to you
>
> ... because the above is accurate.

That's not an answer to the question.  Other available information is
also accurate, just not (what you consider) complete.

> ... and I'm interpreting that as saying that PATH and path are two
> different names for the same var.

Still not an answer.  They actually ARE two different names for the
same operation of the shell, so what difference did it make to you?
When do you ever need to know this for a variable you can't look up by
name in the docs?

If the answer is just because you're curious, that's perfectly fine,
but it isn't necessarily a justification for adding something to the C
code of the shell.

Incidentally, "typeset -P" is already co-opted by the zsh/param/private module.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29  3:03                                                                                                   ` Bart Schaefer
@ 2023-01-29  3:44                                                                                                     ` Ray Andrews
  2023-01-29  4:35                                                                                                       ` Bart Schaefer
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-29  3:44 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users


On 2023-01-28 19:03, Bart Schaefer wrote:
>
> That's not an answer to the question.  Other available information is
> also accurate, just not (what you consider) complete.
Hmmm ... OK, as you use the word.  As I was using it 'accurate' includes 
complete and unambiguous and helpful.  Short of dp, there was no direct 
way of seeing *all* the attributes.  I don't get it Bart, you and Roman 
provided a very nice function and at the  same time you're speaking as 
if there was nothing for it to do.
> If the answer is just because you're curious, that's perfectly fine,
> but it isn't necessarily a justification for adding something to the C
> code of the shell.
That's for the dev's judgement of course.  I have what I want in any 
case.  Dunno, I guess it's just my mentality.  I like complete 
information estheticaly displayed.  Matter of principle mostly, but 
sometimes of practice.  As in this case, I'm occasionally thrown off the 
scent by something misleading or incomplete.  I've had two private 
messages thanking *me* for dp even tho I didn't write it. So I'm not the 
only guy liking that display.  I still think it should be a core 
competence.
>
> Incidentally, "typeset -P" is already co-opted by the zsh/param/private module.

I picked '-P' as a for instance -- sorta 'p' on steroids.  Come to that, 
just philosophically speaking, I don't like commands having both active 
and passive functionality anyway, so it shouldn't be attached to 
typeset.  You don't want to type a command to 'see' something and end up 
'doing' something by accident.  Imagine if 'rm' had a passive usage: 'rm 
-V' ... view previous deletions ... and you type 'rm -r' by mistake and 
... Nope, I was wrong to use typeset to display information from the getgo.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29  3:44                                                                                                     ` Ray Andrews
@ 2023-01-29  4:35                                                                                                       ` Bart Schaefer
  2023-01-29 15:54                                                                                                         ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-29  4:35 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sat, Jan 28, 2023 at 7:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I don't get it Bart, you and Roman
> provided a very nice function and at the  same time you're speaking as
> if there was nothing for it to do.

It's the other way around.  The function gave you what you want, so
there's nothing for a built-in to the shell to do.

If NO function could give you what you wanted, that's a different
question.  E.g., it's a valid point that a parameter declared with
"typeset -E" could be more accurately described by $parameters /
${(t)var}, or that justification width could be more obviously
obtainable than just "typeset +m", or even that the documentation
could do a better job of relating ${(t)var} to the options of
"typeset" (I've submitted a patch for that last, incidentally).


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29  4:35                                                                                                       ` Bart Schaefer
@ 2023-01-29 15:54                                                                                                         ` Ray Andrews
  2023-01-29 21:21                                                                                                           ` Lawrence Velázquez
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-29 15:54 UTC (permalink / raw)
  To: zsh-users

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


On 2023-01-28 20:35, Bart Schaefer wrote:
>
> It's the other way around.  The function gave you what you want, so
> there's nothing for a built-in to the shell to do.
Sure, that's a design decision.  How useful does something have to be 
before it's  hard-coded.  Matter of judgement.  Tho I'm vocal with my 
opinion, at the end of the day it's not my call, nor should it be.  
However a guy like you is so conformed to the status quo -- nuts, you 
built it -- that you no longer 'see' the defects as defects (this 
presuming I'll right when in fact I am often wrong). Where a guy like me 
can be useful is in providing a fresh view of things.  I advocate for 
spelling reform.  Folks who's spelling is perfect say that spelling 
reform isn't needed.
> If NO function could give you what you wanted, that's a different
> question.  E.g., it's a valid point that a parameter declared with
> "typeset -E" could be more accurately described by $parameters /
> ${(t)var}, or that justification width could be more obviously
> obtainable than just "typeset +m",
That's another interesting question.  IMHO core functionality is not -- 
or not hugely -- concerned with appearance -- the individual tarts 
things up as he sees fit -- but *complete* information is a core 
function.  OTOH, a justification option would be very nice -- saves me 
the trouble.  But, for example, I'd put spaces around the equal signs 
cuz it then breaks the output into logical words and thus makes it very 
much easier to, say, columnize the display.
>   or even that the documentation
> could do a better job of relating ${(t)var} to the options of
> "typeset" (I've submitted a patch for that last, incidentally).

In that case my opinion is that the 'Parameters' section of the manual 
should tell the whole story vs. the information being attached to 
individual commands, since there are several commands -- not to mention 
${(t)...} -- that have a duplicated use/reference to the attributes; so 
they should all refer back to Mother.  IOW, the fact that parameters 
have attributes is a fundamental feature of the shell irrespective of 
any particular command, not an incidental collection of details 
pertaining to this command or that command.  That could be said better.

In the crudest, outline form, add something like the 'help' for my function:


    15.1 Description

A parameter has a name, a value, and a number of attributes. A name may 
be any sequence of alphanumeric characters and underscores, or the 
single characters ‘*’, ‘@’, ‘#’, ‘?’, ‘-’, ‘$’, or ‘!’. A parameter 
whose name begins with an alphanumeric or underscore is also referred to 
as a /variable/.

The attributes of a parameter determine the /type/ of its value, often 
referred to as the parameter type or variable type, and also control 
other processing that may be applied to the value when it is referenced. 
The value type may be a /scalar/ (a string, an integer, or a floating 
point number), an array (indexed numerically), or an /associative/ array 
(an unordered set of name-value pairs, indexed by name, also referred to 
as a /hash/).

Here's a complete list of the types and the attributes ( with their 
single-letter designations as used in various commands [ maybe not but 
.... ] ):

TYPES:

S: An ordinary scalar (not an integer or float).
I: An integer.
F: A float ('typeset -F:' decimal display or 'typeset -E': scientific 
display).
A: A normal array.
H: An associative array or 'association' or 'hash' (always 'hideval' as 
well).

ATTRIBUTES:

e: The variable has been exported to the enironment and is thus 
persistent within that terminal -- it will be inherited by subshells.
l: The variable is local to the running function.
t: The variable is 'tied' to another variable.
s: The variable is special to the shell.
r: The variable is read-only (this often goes with 'special').
v: 'hideval': the value of the variable will be hidden -- there are 
things we really don't want to see, like lists of color codes.  This 
tends to go with 'special' and 'hide'.
h: Hide: Used with 'special' ??
u: Unique: ??
?: Undefined: For autoloaded parameters not yet loaded (whatever that 
means).

These types and attributes will now be discussed in detail:

... back to text.


BTW, that section of the manual is very well written, almost literate, 
and technical writing hardly ever is, tho I do wish it was complete.

BTW am I mistaken that 'hideval' is not discussed anywhere?


[-- Attachment #2: Type: text/html, Size: 6168 bytes --]

^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29 15:54                                                                                                         ` Ray Andrews
@ 2023-01-29 21:21                                                                                                           ` Lawrence Velázquez
  2023-01-29 22:33                                                                                                             ` Ray Andrews
  0 siblings, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-29 21:21 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 29, 2023, at 10:54 AM, Ray Andrews wrote:
> BTW am I mistaken that 'hideval' is not discussed anywhere?

Look up typeset -H in zshbuiltins(1).

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29 21:21                                                                                                           ` Lawrence Velázquez
@ 2023-01-29 22:33                                                                                                             ` Ray Andrews
  2023-01-29 22:42                                                                                                               ` Lawrence Velázquez
  0 siblings, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-29 22:33 UTC (permalink / raw)
  To: zsh-users


On 2023-01-29 13:21, Lawrence Velázquez wrote:
> On Sun, Jan 29, 2023, at 10:54 AM, Ray Andrews wrote:
>> BTW am I mistaken that 'hideval' is not discussed anywhere?
> Look up typeset -H in zshbuiltins(1).
>
No mention of 'hideval' that I can see.  It's not a stretch to 
understand that '-H' will set the attribute that is called 'hideval' but 
IMHO that should be explicit.  That's why I suggest that all this stuff 
be explained in one place, namely in the 'Parameters' section of the 
manual.


BTW since 'typeset -p' claims to display information in the same format 
as for the recreation of the parameter:

1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123

1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
typeset -i zzz

... but if I run that output as a new command, the -H is clearly lost.  
'typeset -p' does not do what it claims to do.  Contrast my function (dp 
is the guts of it):

1 /aWorking/Zsh/Source/Wk 0 $ v zzz

Iv    zzz = !hidden!

... an integer with the 'hideval' attribute set.  Accurate and 
complete.  (Tho using my made-up contractions.) Long form:


1 /aWorking/Zsh/Source/Wk 0 $ allvars | grep zzz

zzz                       integer-hideval

'exported' and 'special' are discussed in the 'Parameters' section of 
the manual,  the others are not.  'readonly' is explicitly discussed in 
the above section of zshbuiltins but no other attribute names are.  
'hideval' is referenced in the 'PARAMETER EXPANSION' section of the 
manual but nowhere else.  It's not optimal.  It might take a paragraph 
or two to completely cover the subject, why not do that?  What is the 
virtue in having bits of information on one subject scattered all over?

Seems that the subsection 'Parameter Expansion Flags' under 't' does 
show them all.  So it wouldn't be much work to flesh out the information 
there and merge it into 'Parameters' for a complete understanding of the 
subject in one place.






^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29 22:33                                                                                                             ` Ray Andrews
@ 2023-01-29 22:42                                                                                                               ` Lawrence Velázquez
  2023-01-30  0:42                                                                                                                 ` Ray Andrews
  2023-01-30  4:41                                                                                                                 ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-29 22:42 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Jan 29, 2023, at 5:33 PM, Ray Andrews wrote:
> On 2023-01-29 13:21, Lawrence Velázquez wrote:
>> On Sun, Jan 29, 2023, at 10:54 AM, Ray Andrews wrote:
>>> BTW am I mistaken that 'hideval' is not discussed anywhere?
>> Look up typeset -H in zshbuiltins(1).
>>
> No mention of 'hideval' that I can see.  It's not a stretch to 
> understand that '-H' will set the attribute that is called 'hideval' but 
> IMHO that should be explicit.

The patch Bart mentioned earlier adds an explicit reference.

> BTW since 'typeset -p' claims to display information in the same format 
> as for the recreation of the parameter:
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> typeset -i zzz
>
> ... but if I run that output as a new command, the -H is clearly lost.

Feels like a bug.

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29 22:42                                                                                                               ` Lawrence Velázquez
@ 2023-01-30  0:42                                                                                                                 ` Ray Andrews
  2023-01-30  0:46                                                                                                                   ` Ray Andrews
  2023-01-30  4:41                                                                                                                 ` Bart Schaefer
  1 sibling, 1 reply; 119+ messages in thread
From: Ray Andrews @ 2023-01-30  0:42 UTC (permalink / raw)
  To: zsh-users


On 2023-01-29 14:42, Lawrence Velázquez wrote:
> The patch Bart mentioned earlier adds an explicit reference. 
Easier if all the exposition was in one place tho, one would quickly see 
what's missing.
>
> Feels like a bug.

Yeah, and as I've said, apart from it, this thread would never have 
started.  If typeset -p really did output exactly the string that would 
recreate the param that was input to it, then that would be just what I 
feel it should do -- and claims to do -- and dp wouldn't be needed.  Oh, 
and it might as well output the value too cuz values are part of the 
input to a typeset, ergo a recreation would obviously include the value:


1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123

1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
#typeset -i zzz

typeset -Hi zzz=123

... cool to be able to view a var and in such a way that one could just 
edit that and recreate the var in one go.  typeset -p is a good idea, it 
just doesn't do what it claims to do.

>


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30  0:42                                                                                                                 ` Ray Andrews
@ 2023-01-30  0:46                                                                                                                   ` Ray Andrews
  0 siblings, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-30  0:46 UTC (permalink / raw)
  To: zsh-users


On 2023-01-29 16:42, Ray Andrews wrote:
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> #typeset -i zzz
>
> typeset -Hi zzz=123

Question, how would you do that?  Sent the output directly back to the 
command line for edit and re-execution?




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-29 22:42                                                                                                               ` Lawrence Velázquez
  2023-01-30  0:42                                                                                                                 ` Ray Andrews
@ 2023-01-30  4:41                                                                                                                 ` Bart Schaefer
  2023-01-30  5:16                                                                                                                   ` Lawrence Velázquez
  2023-01-30 14:40                                                                                                                   ` Ray Andrews
  1 sibling, 2 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-30  4:41 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users

On Sun, Jan 29, 2023 at 2:43 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> On Sun, Jan 29, 2023, at 5:33 PM, Ray Andrews wrote:
>
> > BTW since 'typeset -p' claims to display information in the same format
> > as for the recreation of the parameter:
> >
> > ... but if I run that output as a new command, the -H is clearly lost.
>
> Feels like a bug.

The explicit purpose of the hideval attribute is to prevent "typeset
-p" (and several other things) from displaying/restoring the value.

     -p [ N ]
          If the -p option is given, parameters and values are printed
          in the form of a typeset command with an assignment,
          regardless of other flags and options.  Note that the -H flag
          on parameters is respected; no value will be shown for these
          parameters.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30  4:41                                                                                                                 ` Bart Schaefer
@ 2023-01-30  5:16                                                                                                                   ` Lawrence Velázquez
  2023-01-30  6:55                                                                                                                     ` Bart Schaefer
  2023-01-30 14:40                                                                                                                   ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Lawrence Velázquez @ 2023-01-30  5:16 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

On Sun, Jan 29, 2023, at 11:41 PM, Bart Schaefer wrote:
> On Sun, Jan 29, 2023 at 2:43 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>>
>> On Sun, Jan 29, 2023, at 5:33 PM, Ray Andrews wrote:
>>
>> > BTW since 'typeset -p' claims to display information in the same format
>> > as for the recreation of the parameter:
>> >
>> > ... but if I run that output as a new command, the -H is clearly lost.
>>
>> Feels like a bug.
>
> The explicit purpose of the hideval attribute is to prevent "typeset
> -p" (and several other things) from displaying/restoring the value.
>
>      -p [ N ]
>           If the -p option is given, parameters and values are printed
>           in the form of a typeset command with an assignment,
>           regardless of other flags and options.  Note that the -H flag
>           on parameters is respected; no value will be shown for these
>           parameters.

Hm, I was thinking about the omitted -H, not the omitted value
(which I didn't even miss, admittedly).  Then again, the variable
can't be reconstructed without the value, so I'm not sure how
valuable it would be for "typeset -p" output to retain the -H.

As an aside:  The "typeset -p" description is pretty clear about
hiding the value of -H parameters, but then what does "the option
does not apply if the parameter is specified by name" refer to in
the -H description?

	-H	Hide value: specifies that typeset will not display
		the value of the parameter when listing parameters;
		the display for such parameters is always as if the
		`+' flag had been given.  Use of the parameter is
		in other respects normal, and the option does not
		apply if the parameter is specified by name, or by
		pattern with the -m option.

-- 
vq


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30  5:16                                                                                                                   ` Lawrence Velázquez
@ 2023-01-30  6:55                                                                                                                     ` Bart Schaefer
  0 siblings, 0 replies; 119+ messages in thread
From: Bart Schaefer @ 2023-01-30  6:55 UTC (permalink / raw)
  To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users

On Sun, Jan 29, 2023 at 9:17 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> As an aside:  The "typeset -p" description is pretty clear about
> hiding the value of -H parameters, but then what does "the option
> does not apply if the parameter is specified by name" refer to in
> the -H description?

Badly-placed (or missing?) comma, plus use of "if" where "when" would be better.

>                 the option does not
>                 apply if the parameter is specified by name, or by
>                 pattern with the -m option.

The [-H] option does not apply [when] the parameter is specified [by
name or by pattern] with the -m option.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30  4:41                                                                                                                 ` Bart Schaefer
  2023-01-30  5:16                                                                                                                   ` Lawrence Velázquez
@ 2023-01-30 14:40                                                                                                                   ` Ray Andrews
  2023-01-30 14:55                                                                                                                     ` Ray Andrews
  2023-01-30 14:56                                                                                                                     ` Roman Perepelitsa
  1 sibling, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-30 14:40 UTC (permalink / raw)
  To: zsh-users


On 2023-01-29 20:41, Bart Schaefer wrote:
> The explicit purpose of the hideval attribute is to prevent "typeset
> -p" (and several other things) from displaying/restoring the value.
>
Interesting, that's a logical dilemma.  It's like writing into the 
constitution that the constitution cannot be changed.  So then (my  
imaginary version):



1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123

1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz

typeset -Hi zzz=123

$ typeset -Hi zzz=456 # New value for zzz.

... very understandable that some vars should be hidden 'normally' but 
does that mean you have to start a new terminal to edit 'zzz'? -- that 
the country must be dissolved in order to change it's constitution?  
Usually there's a way to amend the constitution.  So, in the same 
spirit, my lines above would seem to me to be the one and only legal way 
to view and edit zzz.  Or, it could be decided that zzz can *never* be 
viewed.  But then never edited as well?  One thing I'd say for sure: 
(real code):

1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123

1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
typeset -i zzz

... that's simply wrong.  Hiding the '-H' merely fools you into thinking 
zzz is a plain integer with no value and that's not correct.  My v() does:

1 /aWorking/Zsh/Source/Wk 0 $ v zzz

Iv    zzz = !hidden!

... so at least you see the attributes correctly ( I should use the 
'real' single letters that typeset uses) even if you are still forbidden 
to see the value.  It's a design decision of course, but IMHO every 
locked door has a key, every constitution can be amended and every var 
should be viewable and editable even if (in this case) only by explicit 
exception.  Is there really no way at all to see the value of a 
hideval?  Surely there is.






^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 14:40                                                                                                                   ` Ray Andrews
@ 2023-01-30 14:55                                                                                                                     ` Ray Andrews
  2023-01-30 14:56                                                                                                                     ` Roman Perepelitsa
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-30 14:55 UTC (permalink / raw)
  To: zsh-users


On 2023-01-30 06:40, Ray Andrews wrote:
>
>
> ... so at least you see the attributes correctly ( I should use the 
> 'real' single letters that typeset uses) even if you are still 
> forbidden to see the value.  It's a design decision of course, but 
> IMHO every locked door has a key, every constitution can be amended 
> and every var should be viewable and editable even if (in this case) 
> only by explicit exception.  Is there really no way at all to see the 
> value of a hideval?  Surely there is.
>
>
>
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> typeset -i zzz
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset +H zzz
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> typeset -i zzz=123
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=456
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> typeset -i zzz
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset +H zzz
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> typeset -i zzz=456
>
> ... it seems like a whole lot of trouble.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 14:40                                                                                                                   ` Ray Andrews
  2023-01-30 14:55                                                                                                                     ` Ray Andrews
@ 2023-01-30 14:56                                                                                                                     ` Roman Perepelitsa
  2023-01-30 15:56                                                                                                                       ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-30 14:56 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Mon, Jan 30, 2023 at 3:41 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2023-01-29 20:41, Bart Schaefer wrote:
> > The explicit purpose of the hideval attribute is to prevent "typeset
> > -p" (and several other things) from displaying/restoring the value.
> >
> Interesting, that's a logical dilemma.  It's like writing into the
> constitution that the constitution cannot be changed.

Are you confusing hideval with readonly? You can change the value of a
hideval parameter like any other.

    % typeset -H foo=bar
    % foo=baz
    % print -r -- $foo
    baz

> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123
>
> 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz
> typeset -i zzz
>
> ... that's simply wrong

This output may be confusing to you but it's not wrong. The absence of
"=" in the output means this is a -H parameter.

In one of the previous emails I wrote that you can recreate parameters
in a fresh shell by evaluating the output of `typeset -p` from another
shell. *That* was wrong. The docs don't claim this.

> Hiding the '-H' merely fools you into thinking
> zzz is a plain integer with no value and that's not correct.

This *interpretation* of the output would be incorrect.

> 1 /aWorking/Zsh/Source/Wk 0 $ v zzz
> Iv    zzz = !hidden!
>
> ... so at least you see the attributes correctly

This is a different representation for the same information. You could
argue that this representation is better because it is easier to parse
for a human, or easier to understand correctly, or more difficult to
understand incorrectly. You cannot say that it's more correct though.

>  Is there really no way at all to see the value of a
> hideval?

You can expand a hideval parameter like any other.

    % typeset -H foo=bar
    % print -r -- $foo
    bar

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 14:56                                                                                                                     ` Roman Perepelitsa
@ 2023-01-30 15:56                                                                                                                       ` Ray Andrews
  2023-01-30 16:09                                                                                                                         ` Roman Perepelitsa
  2023-01-30 17:50                                                                                                                         ` Bart Schaefer
  0 siblings, 2 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-30 15:56 UTC (permalink / raw)
  To: zsh-users


On 2023-01-30 06:56, Roman Perepelitsa wrote:
>
> This is a different representation for the same information. You could
> argue that this representation is better because it is easier to parse
> for a human, or easier to understand correctly, or more difficult to
> understand incorrectly. You cannot say that it's more correct though.
Yeah, that's true.  I shouldn't say 'wrong', it's more like 
'misleading'.  I myself think the '-H' should remain.
> You can expand a hideval parameter like any other.
>      % typeset -H foo=bar
>      % print -r -- $foo
>      bar

Ha!  I tried everything but the simplest thing.  But that begs the 
question of what 'hideval' really achieves if in fact it's not hidden at 
all.


1 /aWorking/Zsh/Source/Wk 0 $ typeset +H bg

1 /aWorking/Zsh/Source/Wk 0 $ typeset -p bg
typeset -A bg=( [black]=$'\C-[[40m' [blue]=$'\C-[[44m' 
[cyan]=$'\C-[[46m' [default]=$'\C-[[49m' [green]=$'\C-[[42m' 
[grey]=$'\C-[[40m' [magenta]=$'\C-[[45m' [red]=$'\C-[[41m' 
[white]=$'\C-[[47m' [yellow]=$'\C-[[43m' )

1 /aWorking/Zsh/Source/Wk 0 $ print -r $bg
[ colored block characters here]

1 /aWorking/Zsh/Source/Wk 0 $ print -r ${(b)bg}
[46m [47m [43m [45m [40m [44m [41m [49m [42m [40m

1 /aWorking/Zsh/Source/Wk 0 $ print -r ${(q+)bg}
$'\C-[[46m' $'\C-[[47m' $'\C-[[43m' $'\C-[[45m' $'\C-[[40m' $'\C-[[44m' 
$'\C-[[41m' $'\C-[[49m' $'\C-[[42m' $'\C-[[40m'


... looks like I must still 'typeset +H' to see the real value -- keys 
and values that is.

IMHO the whole thing is a mess.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 15:56                                                                                                                       ` Ray Andrews
@ 2023-01-30 16:09                                                                                                                         ` Roman Perepelitsa
  2023-01-30 16:24                                                                                                                           ` Bart Schaefer
  2023-01-30 23:05                                                                                                                           ` Ray Andrews
  2023-01-30 17:50                                                                                                                         ` Bart Schaefer
  1 sibling, 2 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-30 16:09 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Mon, Jan 30, 2023 at 4:57 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> But that begs the question of what 'hideval' really achieves if
> in fact it's not hidden at all.

It does what it says on the tin. From typeset docs:

    -H specifies that typeset will not display the value of the
    parameter when listing parameters

> ... looks like I must still 'typeset +H' to see the real value -- keys
> and values that is.

These are not "real" values. You can choose any representation you
like. It looks like you want this:

    printf '[%s]=%s ' "${(@kvq+)bg}"

We keep going in circles. If `typeset -p` doesn't do exactly what you
want, it doesn't mean it's broken or bad. If it was *impossible* to
produce the output you want, that would be actually bad. Up until now
all output that you've identified as desirable was shown to be
possible to produce without extending zsh. This means there is no need
to extend zsh. If you want to produce some output but don't know how,
ask.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 16:09                                                                                                                         ` Roman Perepelitsa
@ 2023-01-30 16:24                                                                                                                           ` Bart Schaefer
  2023-01-30 16:34                                                                                                                             ` Roman Perepelitsa
  2023-01-30 23:05                                                                                                                           ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-30 16:24 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users

On Mon, Jan 30, 2023 at 8:10 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> These are not "real" values. You can choose any representation you
> like. It looks like you want this:
>
>     printf '[%s]=%s ' "${(@kvq+)bg}"

Actually he just wants

  typeset -m bg

which is what describe-params does, so I don't know how we got off
into these weeds again.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 16:24                                                                                                                           ` Bart Schaefer
@ 2023-01-30 16:34                                                                                                                             ` Roman Perepelitsa
  0 siblings, 0 replies; 119+ messages in thread
From: Roman Perepelitsa @ 2023-01-30 16:34 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

On Mon, Jan 30, 2023 at 5:25 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Mon, Jan 30, 2023 at 8:10 AM Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > These are not "real" values. You can choose any representation you
> > like. It looks like you want this:
> >
> >     printf '[%s]=%s ' "${(@kvq+)bg}"
>
> Actually he just wants
>
>   typeset -m bg
>
> which is what describe-params does, so I don't know how we got off
> into these weeds again.

Good point.

Mine still stands though. Ray, if you don't like how `typeset -m`
represents information, you can always produce your own hand-crafted
output. If you don't know how, ask.

Roman.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 15:56                                                                                                                       ` Ray Andrews
  2023-01-30 16:09                                                                                                                         ` Roman Perepelitsa
@ 2023-01-30 17:50                                                                                                                         ` Bart Schaefer
  2023-01-31  0:42                                                                                                                           ` Ray Andrews
  1 sibling, 1 reply; 119+ messages in thread
From: Bart Schaefer @ 2023-01-30 17:50 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Mon, Jan 30, 2023 at 7:57 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Ha!  I tried everything but the simplest thing.  But that begs the
> question of what 'hideval' really achieves if in fact it's not hidden at
> all.

hideval was introduced as an internal attribute to avoid having the
large/hard-to-read contents of module-provided arrays (like $aliases,
$parameters and especially $functions) spewed out in a wall of text
when the user was not expecting it.

Later, someone else said this would be useful for situations like
global variables used to cache data across function invocations, where
the user doesn't need to know the details of the function
implementation -- so -H was added to typeset.

In short, you shouldn't use it yourself unless you have a known
reason, and if somebody else used it, it means they don't want you to
be nosy.


^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 16:09                                                                                                                         ` Roman Perepelitsa
  2023-01-30 16:24                                                                                                                           ` Bart Schaefer
@ 2023-01-30 23:05                                                                                                                           ` Ray Andrews
  1 sibling, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-30 23:05 UTC (permalink / raw)
  To: zsh-users


On 2023-01-30 08:09, Roman Perepelitsa wrote:
>
> We keep going in circles. If `typeset -p` doesn't do exactly what you
> want, it doesn't mean it's broken or bad. If it was *impossible* to
> produce the output you want, that would be actually bad. Up until now
> all output that you've identified as desirable was shown to be
> possible to produce without extending zsh. This means there is no need
> to extend zsh.

I've agreed to that several times.  My humble opinion is that typeset -p 
should produce a more complete output but that's just me.   Don't take 
this stuff more seriously than I take it.

Actually he just wants

   typeset -m bg

... yup.  Just when I reconcile myself to my ... = !hidden! ... then I see that hideval or not, one *can* see the value after all.  Ok, I surrender: typeset -p is a masterpiece of helpful, informative clarity.  And hidden values are still entirely visible just as one would expect from something hidden.  Got it.




^ permalink raw reply	[flat|nested] 119+ messages in thread

* Re: path PATH
  2023-01-30 17:50                                                                                                                         ` Bart Schaefer
@ 2023-01-31  0:42                                                                                                                           ` Ray Andrews
  0 siblings, 0 replies; 119+ messages in thread
From: Ray Andrews @ 2023-01-31  0:42 UTC (permalink / raw)
  To: zsh-users


On 2023-01-30 09:50, Bart Schaefer wrote:
>
> hideval was introduced as an internal attribute to avoid having the
> large/hard-to-read contents of module-provided arrays (like $aliases,
> $parameters and especially $functions) spewed out in a wall of text
> when the user was not expecting it.

Sure.  It makes sense that there are things you'd not want to look at 
unless explicitly requested.  I'm actually a little surprised that they 
are so easy to look at.  But as long as it's explicit then of course you 
should see what you want to see.  I have no complaints other than 
typeset -p removing the '-H' flag which is clearly still in effect.  But 
you guys are happy with it so that's the end of the subject.






^ permalink raw reply	[flat|nested] 119+ messages in thread

end of thread, other threads:[~2023-01-31  0:43 UTC | newest]

Thread overview: 119+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-20 21:57 path PATH Ray Andrews
2023-01-20 22:20 ` Bart Schaefer
2023-01-21  2:23   ` Ray Andrews
2023-01-21  6:11     ` Lawrence Velázquez
2023-01-21 15:18       ` Ray Andrews
2023-01-21 15:25         ` Roman Perepelitsa
2023-01-21 16:21           ` Ray Andrews
2023-01-21 16:38             ` Roman Perepelitsa
2023-01-21 16:54               ` Ray Andrews
2023-01-21 17:01                 ` Roman Perepelitsa
2023-01-21 18:53                   ` Ray Andrews
2023-01-21 19:09                     ` Roman Perepelitsa
2023-01-21 20:50                       ` Ray Andrews
2023-01-21 21:11                         ` Roman Perepelitsa
2023-01-21 20:19                     ` Bart Schaefer
2023-01-21 20:26                       ` env arrays (was: Re: path PATH) zeurkous
2023-01-22 17:28                         ` Bart Schaefer
2023-01-21 21:03                       ` path PATH Ray Andrews
2023-01-21 21:52                         ` Lawrence Velázquez
2023-01-22  0:42                           ` Ray Andrews
2023-01-22 12:29                             ` Roman Perepelitsa
2023-01-22 14:17                               ` Ray Andrews
2023-01-22 16:15                                 ` Bart Schaefer
2023-01-22 17:23                                   ` Ray Andrews
2023-01-22 19:20                               ` Bart Schaefer
2023-01-22 19:31                                 ` Roman Perepelitsa
2023-01-22 19:51                                   ` Bart Schaefer
2023-01-22 19:56                                     ` Roman Perepelitsa
2023-01-22 20:03                                       ` Bart Schaefer
2023-01-22 21:56                                         ` Bart Schaefer
2023-01-22 22:02                                           ` Roman Perepelitsa
2023-01-22 22:27                                             ` Bart Schaefer
2023-01-22 23:03                                           ` Ray Andrews
2023-01-22 20:12                                       ` Ray Andrews
2023-01-22 21:11                                         ` Bart Schaefer
2023-01-22 22:44                                           ` Ray Andrews
2023-01-22 23:35                                             ` Lawrence Velázquez
2023-01-22 23:58                                               ` Ray Andrews
2023-01-23  0:49                                                 ` Lawrence Velázquez
2023-01-23  1:33                                                   ` Bart Schaefer
2023-01-23  1:49                                                     ` Lawrence Velázquez
2023-01-23  1:11                                             ` Bart Schaefer
2023-01-23  1:56                                               ` Ray Andrews
2023-01-23  2:59                                                 ` Lawrence Velázquez
2023-01-23  3:47                                                   ` Ray Andrews
2023-01-23 10:37                                             ` Roman Perepelitsa
2023-01-23 15:28                                               ` Ray Andrews
2023-01-23 15:40                                                 ` zeurkous
2023-01-23 16:02                                                   ` Ray Andrews
2023-01-23 16:25                                                     ` zeurkous
2023-01-23 16:26                                               ` Bart Schaefer
2023-01-24 20:00                                     ` Ray Andrews
2023-01-24 20:42                                       ` Bart Schaefer
2023-01-24 20:50                                         ` Bart Schaefer
2023-01-24 20:54                                         ` Ray Andrews
2023-01-24 23:28                                     ` Ray Andrews
2023-01-24 23:42                                       ` Bart Schaefer
2023-01-25  0:14                                         ` Ray Andrews
2023-01-25 16:38                                           ` Ray Andrews
2023-01-25 16:43                                             ` Roman Perepelitsa
2023-01-25 16:56                                               ` Ray Andrews
2023-01-25 17:02                                                 ` Roman Perepelitsa
2023-01-25 17:34                                                   ` Ray Andrews
2023-01-25 17:37                                                     ` Roman Perepelitsa
2023-01-25 18:26                                                       ` Ray Andrews
2023-01-25 18:34                                                         ` Roman Perepelitsa
2023-01-25 19:00                                                           ` Ray Andrews
2023-01-26  2:13                                                           ` Ray Andrews
2023-01-26  2:37                                                             ` Bart Schaefer
2023-01-26  4:27                                                               ` Ray Andrews
2023-01-26 20:26                                                                 ` Ray Andrews
2023-01-26 20:29                                                                   ` Roman Perepelitsa
2023-01-26 20:59                                                                     ` Ray Andrews
2023-01-26 21:17                                                                       ` Bart Schaefer
2023-01-26 21:41                                                                       ` Bart Schaefer
2023-01-26 21:44                                                                         ` Bart Schaefer
2023-01-26 22:36                                                                           ` Ray Andrews
2023-01-26 22:43                                                                             ` Bart Schaefer
2023-01-27  0:19                                                                               ` Ray Andrews
2023-01-27  3:36                                                                                 ` Ray Andrews
2023-01-27 17:51                                                                                 ` Ray Andrews
2023-01-27 20:45                                                                                   ` Bart Schaefer
2023-01-27 21:09                                                                                     ` Ray Andrews
2023-01-27 23:45                                                                                       ` scowles
2023-01-28  0:12                                                                                         ` Ray Andrews
2023-01-28  3:47                                                                                           ` Bart Schaefer
2023-01-28 16:42                                                                                             ` Ray Andrews
2023-01-28 22:51                                                                                               ` Bart Schaefer
2023-01-29  2:30                                                                                                 ` Ray Andrews
2023-01-29  3:03                                                                                                   ` Bart Schaefer
2023-01-29  3:44                                                                                                     ` Ray Andrews
2023-01-29  4:35                                                                                                       ` Bart Schaefer
2023-01-29 15:54                                                                                                         ` Ray Andrews
2023-01-29 21:21                                                                                                           ` Lawrence Velázquez
2023-01-29 22:33                                                                                                             ` Ray Andrews
2023-01-29 22:42                                                                                                               ` Lawrence Velázquez
2023-01-30  0:42                                                                                                                 ` Ray Andrews
2023-01-30  0:46                                                                                                                   ` Ray Andrews
2023-01-30  4:41                                                                                                                 ` Bart Schaefer
2023-01-30  5:16                                                                                                                   ` Lawrence Velázquez
2023-01-30  6:55                                                                                                                     ` Bart Schaefer
2023-01-30 14:40                                                                                                                   ` Ray Andrews
2023-01-30 14:55                                                                                                                     ` Ray Andrews
2023-01-30 14:56                                                                                                                     ` Roman Perepelitsa
2023-01-30 15:56                                                                                                                       ` Ray Andrews
2023-01-30 16:09                                                                                                                         ` Roman Perepelitsa
2023-01-30 16:24                                                                                                                           ` Bart Schaefer
2023-01-30 16:34                                                                                                                             ` Roman Perepelitsa
2023-01-30 23:05                                                                                                                           ` Ray Andrews
2023-01-30 17:50                                                                                                                         ` Bart Schaefer
2023-01-31  0:42                                                                                                                           ` Ray Andrews
2023-01-26 22:18                                                                         ` Ray Andrews
2023-01-25 22:18                                                   ` Bart Schaefer
2023-01-25 23:10                                                     ` Ray Andrews
2023-01-25 23:19                                                       ` Bart Schaefer
2023-01-26  0:55                                                         ` Ray Andrews
2023-01-22 19:52                                 ` Ray Andrews
2023-01-21 16:48             ` Bart Schaefer
2023-01-21  5:47 ` Lawrence Velázquez

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).