zsh-users
 help / color / mirror / code / Atom feed
* var=$( typeset "$1" ) ... not within a function.
@ 2022-10-20 17:21 Ray Andrews
  2022-10-20 17:25 ` Roman Perepelitsa
                   ` (2 more replies)
  0 siblings, 3 replies; 39+ messages in thread
From: Ray Andrews @ 2022-10-20 17:21 UTC (permalink / raw)
  To: Zsh Users

function ii ()
{
     var=$( printenv "$1" )
     [ "$var" ] && var=$( typeset "$1" )
     print "var is: $var    "
}
$ . test; ii USER
var is:

... why won't 'typeset' work there?  Funny thing is that if I run it as 
a script:

  $ var=$( printenv "$1" )
[ "$var" ] && var=$( typeset "$1" )
print "var is: $var     "

...

var is: USER=root

... no problem.  I don't even have a wild guess why this might be.





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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:21 var=$( typeset "$1" ) ... not within a function Ray Andrews
@ 2022-10-20 17:25 ` Roman Perepelitsa
  2022-10-20 17:51   ` Ray Andrews
  2022-10-20 17:29 ` var=$( typeset "$1" ) ... not within a function Mikael Magnusson
  2022-10-21 17:33 ` Ray Andrews
  2 siblings, 1 reply; 39+ messages in thread
From: Roman Perepelitsa @ 2022-10-20 17:25 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Thu, Oct 20, 2022 at 7:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> function ii ()
> {
>      var=$( printenv "$1" )
>      [ "$var" ] && var=$( typeset "$1" )
>      print "var is: $var    "
> }
> $ . test; ii USER
> var is:
>
> ... why won't 'typeset' work there?

Try typing `typeset USER` in your interactive shell. What do you get as output?

Take a look at typeset_silent option.

Roman.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:21 var=$( typeset "$1" ) ... not within a function Ray Andrews
  2022-10-20 17:25 ` Roman Perepelitsa
@ 2022-10-20 17:29 ` Mikael Magnusson
  2022-10-20 17:43   ` Ray Andrews
  2022-10-21 17:33 ` Ray Andrews
  2 siblings, 1 reply; 39+ messages in thread
From: Mikael Magnusson @ 2022-10-20 17:29 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On 10/20/22, Ray Andrews <rayandrews@eastlink.ca> wrote:
> function ii ()
> {
>      var=$( printenv "$1" )
>      [ "$var" ] && var=$( typeset "$1" )
>      print "var is: $var    "
> }

What kind of logic is behind this code? You first check if the given
name is in the environment, then you assign over the same parameter
again with the same value using another way to get the value.

-- 
Mikael Magnusson


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:29 ` var=$( typeset "$1" ) ... not within a function Mikael Magnusson
@ 2022-10-20 17:43   ` Ray Andrews
  0 siblings, 0 replies; 39+ messages in thread
From: Ray Andrews @ 2022-10-20 17:43 UTC (permalink / raw)
  To: zsh-users


On 2022-10-20 10:29, Mikael Magnusson wrote:
> On 10/20/22, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> function ii ()
>> {
>>       var=$( printenv "$1" )
>>       [ "$var" ] && var=$( typeset "$1" )
>>       print "var is: $var    "
>> }
> What kind of logic is behind this code? You first check if the given
> name is in the environment, then you assign over the same parameter
> again with the same value using another way to get the value.

There is method in my madness.  printenv there returns "root", typeset 
return "USER=root" and more importantly printenv does not accept 
wildcards and  ... nevermind -- the point is that whatever my motives, 
it seems strange that the code doesn't work when inside a function.


>


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:25 ` Roman Perepelitsa
@ 2022-10-20 17:51   ` Ray Andrews
  2022-10-20 17:54     ` Roman Perepelitsa
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-20 17:51 UTC (permalink / raw)
  To: zsh-users


On 2022-10-20 10:25, Roman Perepelitsa wrote:
> Try typing `typeset USER` in your interactive shell. What do you get 
> as output?
> Take a look at typeset_silent option.

There's part of an explanation. 'typeset -m' cures the problem but why 
is there only a problem within the function?  Why this special handling 
of typeset?




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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:51   ` Ray Andrews
@ 2022-10-20 17:54     ` Roman Perepelitsa
  2022-10-20 18:38       ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Roman Perepelitsa @ 2022-10-20 17:54 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Oct 20, 2022 at 7:52 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2022-10-20 10:25, Roman Perepelitsa wrote:
> > Try typing `typeset USER` in your interactive shell. What do you get
> > as output?
> > Take a look at typeset_silent option.
>
> There's part of an explanation. 'typeset -m' cures the problem but why
> is there only a problem within the function?  Why this special handling
> of typeset?

The function is a red herring. If you run `unsetopt typeset_silent` in
the function or before invoking it, you'll see the same behavior as
you see in the script. If you read the description of this option,
you'll immediately see that everything works as expected. This option
controls `typeset` in exactly the way you are observing.

Roman.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:54     ` Roman Perepelitsa
@ 2022-10-20 18:38       ` Ray Andrews
  2022-10-20 18:44         ` Roman Perepelitsa
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-20 18:38 UTC (permalink / raw)
  To: zsh-users


On 2022-10-20 10:54, Roman Perepelitsa wrote:
> The function is a red herring. If you run `unsetopt typeset_silent` in
> the function or before invoking it, you'll see the same behavior as
> you see in the script. If you read the description of this option,
> you'll immediately see that everything works as expected. This option
> controls `typeset` in exactly the way you are observing.

But wouldn't my shell settings be inherited by the function?  It may be 
all as wanted, but it seems anomalous.  Why this special handling for 
typeset?  I can see that if you are setting or changing something, then 
the effect within a function will be different so various protections 
might be in order, but the simple display of an environment variable ... 
it seems strange.




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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 18:38       ` Ray Andrews
@ 2022-10-20 18:44         ` Roman Perepelitsa
  2022-10-20 19:15           ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Roman Perepelitsa @ 2022-10-20 18:44 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Oct 20, 2022 at 8:39 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-10-20 10:54, Roman Perepelitsa wrote:
> > The function is a red herring. If you run `unsetopt typeset_silent` in
> > the function or before invoking it, you'll see the same behavior as
> > you see in the script. If you read the description of this option,
> > you'll immediately see that everything works as expected. This option
> > controls `typeset` in exactly the way you are observing.
>
> But wouldn't my shell settings be inherited by the function?  It may be
> all as wanted, but it seems anomalous.  Why this special handling for
> typeset?  I can see that if you are setting or changing something, then
> the effect within a function will be different so various protections
> might be in order, but the simple display of an environment variable ...
> it seems strange.

There is no special handling of typeset within functions. `typeset
USER` behaves differently depending on whether typeset_silent is set
or not. You tested `typeset USER` in an environment where this option
is set and then in another environment where it's unset, and got
different results. This is expected. If you want `typeset USER` to
print, make sure to unset typeset_silent beforehand. However, what you
are doing is so bizarre that you should probably rewrite that code. I
would offer an alternative but I have no guess as to what you might be
trying to achieve.

Roman.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 18:44         ` Roman Perepelitsa
@ 2022-10-20 19:15           ` Ray Andrews
  2022-10-20 19:35             ` Roman Perepelitsa
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-20 19:15 UTC (permalink / raw)
  To: zsh-users


On 2022-10-20 11:44, Roman Perepelitsa wrote:
> USER` behaves differently depending on whether typeset_silent is set
> or not. You tested `typeset USER` in an environment where this option
> is set and then in another environment where it's unset, and got
> different results.

file 'test':

function ii ()

{
setopt typeset_silent
var=$(typeset USER)
print set in function $var

unsetopt typeset_silent
var=$(typeset USER)
print unset in function $var
}
setopt typeset_silent
var=$(typeset USER)
print set in script $var

unsetopt typeset_silent
var=$(typeset USER)
print unset in script $var

. test; ii
set in script
unset in script USER=root
set in function
unset in function

... confused.




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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 19:15           ` Ray Andrews
@ 2022-10-20 19:35             ` Roman Perepelitsa
  2022-10-20 20:48               ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Roman Perepelitsa @ 2022-10-20 19:35 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Oct 20, 2022 at 9:16 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2022-10-20 11:44, Roman Perepelitsa wrote:
> > USER` behaves differently depending on whether typeset_silent is set
> > or not. You tested `typeset USER` in an environment where this option
> > is set and then in another environment where it's unset, and got
> > different results.
>
> file 'test':
>
> function ii ()
>
> {
> setopt typeset_silent
> var=$(typeset USER)
> print set in function $var
>
> unsetopt typeset_silent
> var=$(typeset USER)
> print unset in function $var
> }
> setopt typeset_silent
> var=$(typeset USER)
> print set in script $var
>
> unsetopt typeset_silent
> var=$(typeset USER)
> print unset in script $var
>
> . test; ii
> set in script
> unset in script USER=root
> set in function
> unset in function
>
> ... confused.

Oh, I see what you mean. I confused you, sorry.

typeset_silent kicks in only when you do `typeset foo` and there is
already `foo` in scope. Here, when have `typeset USER` in a function,
there is no `USER` in scope, so a new parameter is defined.

I cannot offer a solution because I don't know what you are trying to
achieve. No small change will make this code look reasonable.

Roman.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 19:35             ` Roman Perepelitsa
@ 2022-10-20 20:48               ` Ray Andrews
  2022-10-21  0:54                 ` Bart Schaefer
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-20 20:48 UTC (permalink / raw)
  To: zsh-users


> Oh, I see what you mean. I confused you, sorry.
It's easy to do.
> typeset_silent kicks in only when you do `typeset foo` and there is
> already `foo` in scope. Here, when have `typeset USER` in a function,
> there is no `USER` in scope, so a new parameter is defined.
I understand.  Mind, I wasn't trying to create a parameter, just return 
it's value if set, which is what the prior test is for. typeset scares 
me because sometimes it's a passive reporter, other times dangerously 
active, in this case I was just looking for information but it seems 
like I created a parameter -- which '-m' seems to prevent.  It's all 
rather Byzantine but I do at least get it.  Many thanks.
>
> I cannot offer a solution because I don't know what you are trying to
> achieve. No small change will make this code look reasonable.

It's not reasonable, it's a boiled down minimal code to convey my 
problem which is now solved.  I appreciate your patience!


> Roman.
>


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 20:48               ` Ray Andrews
@ 2022-10-21  0:54                 ` Bart Schaefer
  2022-10-21  1:58                   ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Bart Schaefer @ 2022-10-21  0:54 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

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

On Thu, Oct 20, 2022 at 1:48 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> typeset scares
> me because sometimes it's a passive reporter, other times dangerously
> active

Yes, it's unfortunate that typeset (without options) was ever given
the function you describe as "passive reporter".  Worse that it's
synonym "declare" behaves the same.

> in this case I was just looking for information

There are two typeset options specifically for that purpose: -p, which
prints "typeset" commands so you can replay them e.g. with "eval" or
from a script file, and "+" (all by itself), which either prints all
the parameter names (and only the names), or the assignment form of
whatever names follow it.  (The manual still doesn't explain the
latter effect, I see, claiming that nothing is allowed to follow a
bare "+" sign.)

> but it seems
> like I created a parameter -- which '-m' seems to prevent.

The -m option actually is for pattern-matching and is intended to be
combined with other options ... when you use it without any others, it
has the effect of canceling "what typeset does when there are no
options", and that accidentally produces the effect you wanted.

[-- Attachment #2: doc-typeset-plus.txt --]
[-- Type: text/plain, Size: 1467 bytes --]

diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo
index 641e46cf9..dd54a0fc8 100644
--- a/Doc/Zsh/builtins.yo
+++ b/Doc/Zsh/builtins.yo
@@ -2047,8 +2047,9 @@ startitem()
 item(tt(PLUS()))(
 If `tt(PLUS())' appears by itself in a separate word as the last option,
 then the names of all parameters (functions with tt(-f)) are printed, but
-the values (function bodies) are not.  No var(name) arguments may appear,
-and it is an error for any other options to follow `tt(PLUS())'.  The
+the values (function bodies) are not.  If var(name) arguments appear,
+both those names and their values are printed in the form of assignments.
+It is an error for any other options to follow `tt(PLUS())', but the
 effect of `tt(PLUS())' is as if all attribute flags which precede it were
 given with a `tt(PLUS())' prefix.  For example, `tt(typeset -U PLUS())' is
 equivalent to `tt(typeset +U)' and displays the names of all arrays having
@@ -2081,7 +2082,8 @@ Except when assignments are made with var(name)tt(=)var(value), using
 tt(+m) forces the matching parameters and their attributes to be printed,
 even inside a function.  Note that tt(-m) is ignored if no patterns are
 given, so `tt(typeset -m)' displays attributes but `tt(typeset -a +m)'
-does not.
+does not.  Ordinary scalar string parameters have no attributes, so for
+those tt(+m) prints only the names.
 )
 item(tt(-p) [ var(n) ])(
 If the tt(-p) option is given, parameters and values are printed in the

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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21  0:54                 ` Bart Schaefer
@ 2022-10-21  1:58                   ` Ray Andrews
  2022-10-21  2:25                     ` Bart Schaefer
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-21  1:58 UTC (permalink / raw)
  To: zsh-users


On 2022-10-20 17:54, Bart Schaefer wrote:
> Yes, it's unfortunate that typeset (without options) was ever given
> the function you describe as "passive reporter".  Worse that it's
> synonym "declare" behaves the same.

Prowling around in the parameters there's lots of little mysteries,

  $ typeset -mp CDPATH
typeset -T CDPATH cdpath=(  )

... but the same command from within a script or function gives:

typeset -g -T CDPATH cdpath=(  )

... and if I scan the entire output of "$ typeset -p" and look for 
'CDPATH' I get:

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

... and from within a function the '-g' is added.

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

... what's the truth of the matter with CDPATH?  And how in hell can 
there be two of them?

I get the feeling that this whole neck of the woods hasn't been given a 
housecleaning since ENIAC, it's just always been this way and probably 
has to stay this way due to the ancientness of the tradition.  Probably 
goes back to sh 0.1

... and while I'm whining I notice that 'set' never does anything like: 
"CDPATH cdpath", it puts them on separate lines.  Dunno, couldn't they 
have separate values?






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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21  1:58                   ` Ray Andrews
@ 2022-10-21  2:25                     ` Bart Schaefer
  2022-10-21 14:24                       ` Ray Andrews
  2022-11-01  5:00                       ` "typeset -p" inconsistency Bart Schaefer
  0 siblings, 2 replies; 39+ messages in thread
From: Bart Schaefer @ 2022-10-21  2:25 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Oct 20, 2022 at 6:58 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>   $ typeset -mp CDPATH
> typeset -T CDPATH cdpath=(  )

That's actually a bug ... "typeset -T" doesn't take two arguments in
that format.

> ... but the same command from within a script or function gives:
>
> typeset -g -T CDPATH cdpath=(  )

The -g is because typeset -p is supposed to be outputting a command
that can be sent back through "eval".  If you were to execute that
typeset without the -g when inside a function, you would create a new
local CDPATH variable.  The -g makes sure you are still referencing
the global.

> ... and if I scan the entire output of "$ typeset -p" and look for
> 'CDPATH' I get:
>
> typeset -T CDPATH cdpath=(  )
> typeset -aT CDPATH cdpath=(  )

The first one is the (incorrect) assignment for $CDPATH.
The second one is the (correct) assignment for $cdpath.
These are "tied" variables (the -T) meaning that if you change either
one of them, the other also changes.

> ... and from within a function the '-g' is added.

See above.

> ... and while I'm whining I notice that 'set' never does anything like:
> "CDPATH cdpath", it puts them on separate lines.  Dunno, couldn't they
> have separate values?

No, they can't.  One is a colon-separated string and the other is an
array, but they always track one another.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21  2:25                     ` Bart Schaefer
@ 2022-10-21 14:24                       ` Ray Andrews
  2022-10-21 14:37                         ` Ray Andrews
  2022-10-21 17:34                         ` Roman Perepelitsa
  2022-11-01  5:00                       ` "typeset -p" inconsistency Bart Schaefer
  1 sibling, 2 replies; 39+ messages in thread
From: Ray Andrews @ 2022-10-21 14:24 UTC (permalink / raw)
  To: zsh-users


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

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

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

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

$ . i; i "*path*"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 14:24                       ` Ray Andrews
@ 2022-10-21 14:37                         ` Ray Andrews
  2022-10-21 17:34                         ` Roman Perepelitsa
  1 sibling, 0 replies; 39+ messages in thread
From: Ray Andrews @ 2022-10-21 14:37 UTC (permalink / raw)
  To: zsh-users


On 2022-10-21 07:24, Ray Andrews wrote:
> (If case sensitivity was built in to typeset I'd not have to bother 
> with the sed filter at all.  Seems to me that since we already have 
> the use of wildcards there, case sensitivity would be a natural 
> enhancement.  Dunno, maybe '-M' ... capital M means wildcards plus 
> case sensitive.)
Sorry, I said that exactly backwards. 'M' for INsensitive.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-20 17:21 var=$( typeset "$1" ) ... not within a function Ray Andrews
  2022-10-20 17:25 ` Roman Perepelitsa
  2022-10-20 17:29 ` var=$( typeset "$1" ) ... not within a function Mikael Magnusson
@ 2022-10-21 17:33 ` Ray Andrews
  2022-10-21 18:25   ` Bart Schaefer
  2 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-21 17:33 UTC (permalink / raw)
  To: zsh-users

$ printenv path

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

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

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

... typeset politely links the two variables, but printenv is less 
intelligent.




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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 14:24                       ` Ray Andrews
  2022-10-21 14:37                         ` Ray Andrews
@ 2022-10-21 17:34                         ` Roman Perepelitsa
  1 sibling, 0 replies; 39+ messages in thread
From: Roman Perepelitsa @ 2022-10-21 17:34 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Oct 21, 2022 at 4:25 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> So, to add case sensitivity to the output of typeset I just run
> it thru a 'sed' for filtering and colorizing (which you can't see below
> of course).  So, if I want to know if, case insensitively, what "*path*"
> might mean to the shell

Try this:

  function print-params() {
    emulate -L zsh -o extened_glob
    local names=( ${parameters[(I)(#i)$~1]} )
    if (( $#names )); then
      typeset -p -- $names
    fi
  }

  print-params '*path*'

You can do the same thing with other associative arrays: aliases,
functions, commands, etc.

Roman.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 17:33 ` Ray Andrews
@ 2022-10-21 18:25   ` Bart Schaefer
  2022-10-21 18:57     ` Ray Andrews
  2022-10-21 19:04     ` Ray Andrews
  0 siblings, 2 replies; 39+ messages in thread
From: Bart Schaefer @ 2022-10-21 18:25 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Oct 21, 2022 at 10:33 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> ... typeset politely links the two variables, but printenv is less
> intelligent.

Lower-case cdpath is not an environment variable, so printenv would
have no reason to print it.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 18:25   ` Bart Schaefer
@ 2022-10-21 18:57     ` Ray Andrews
  2022-10-21 19:02       ` Roman Perepelitsa
  2022-10-21 19:04     ` Ray Andrews
  1 sibling, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-10-21 18:57 UTC (permalink / raw)
  To: zsh-users


On 2022-10-21 11:25, Bart Schaefer wrote:
>
> Lower-case cdpath is not an environment variable, so printenv would
> have no reason to print it.

Sorry I meant:

2 /aWorking/Zsh/Source/Wk 2 $ printenv path

2 /aWorking/Zsh/Source/Wk 2 $ printenv PATH
.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

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

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





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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 18:57     ` Ray Andrews
@ 2022-10-21 19:02       ` Roman Perepelitsa
  2022-10-21 19:06         ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Roman Perepelitsa @ 2022-10-21 19:02 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Oct 21, 2022 at 8:58 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2022-10-21 11:25, Bart Schaefer wrote:
> >
> > Lower-case cdpath is not an environment variable, so printenv would
> > have no reason to print it.
>
> Sorry I meant:
>
> 2 /aWorking/Zsh/Source/Wk 2 $ printenv path

The same reason applies here: `path` is not an environment variable,
so printenv doesn't print it.

Now that you've described what you are trying to achieve, it's clear
that using printenv is not what you need. Please see my last post for
one way of printing parameters whose names case-insensitively match a
pattern.

Roman.


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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 18:25   ` Bart Schaefer
  2022-10-21 18:57     ` Ray Andrews
@ 2022-10-21 19:04     ` Ray Andrews
  1 sibling, 0 replies; 39+ messages in thread
From: Ray Andrews @ 2022-10-21 19:04 UTC (permalink / raw)
  To: zsh-users


On 2022-10-21 11:25, Bart Schaefer wrote:
> On Fri, Oct 21, 2022 at 10:33 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> ... typeset politely links the two variables, but printenv is less
>> intelligent.
> Lower-case cdpath is not an environment variable, so printenv would
> have no reason to print it.

Sorry within sorry:  yes of course, even with 'path/PATH' one is 
exported the other is not,  I assumed that since they were tied together 
they must have the same scope.  The only difference that I was zoomed in 
on was the absence of the '-a' in the one case -- but there's the other 
difference as well.  Easy to lose the scent!





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

* Re: var=$( typeset "$1" ) ... not within a function.
  2022-10-21 19:02       ` Roman Perepelitsa
@ 2022-10-21 19:06         ` Ray Andrews
  0 siblings, 0 replies; 39+ messages in thread
From: Ray Andrews @ 2022-10-21 19:06 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: zsh-users


On 2022-10-21 12:02, Roman Perepelitsa wrote:
>
> Now that you've described what you are trying to achieve, it's clear
> that using printenv is not what you need. Please see my last post for
> one way of printing parameters whose names case-insensitively match a
> pattern.

Thanks for that, I'm studying it.  Nice to get closer to the root of the 
issue, and that does it.


>
> Roman.


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

* "typeset -p" inconsistency
  2022-10-21  2:25                     ` Bart Schaefer
  2022-10-21 14:24                       ` Ray Andrews
@ 2022-11-01  5:00                       ` Bart Schaefer
  2022-11-01 12:07                         ` Peter Stephenson
  2022-11-01 12:40                         ` Ray Andrews
  1 sibling, 2 replies; 39+ messages in thread
From: Bart Schaefer @ 2022-11-01  5:00 UTC (permalink / raw)
  To: Zsh Users

On Thu, Oct 20, 2022 at 7:25 PM, I wrote:
>
> > typeset -T CDPATH cdpath=(  )
> > typeset -aT CDPATH cdpath=(  )
>
> The first one is the (incorrect) assignment for $CDPATH.

Nobody called me out on that ... the first assignment is actually just
fine.  I'm not sure how I ended up thinking that didn't work.  There
is, however, a related buglet:

% setopt extendedglob
% typeset -U CDPATH
% typeset -mp '(#i)cdpath'
typeset -aT CDPATH cdpath=(  )
typeset -UT CDPATH cdpath=(  )

Note the -U attribute is only retained when printing the assignment
for the scalar ... which is literally correct, since it was only
asserted for the scalar, but lossy, whereas the array-ness is
preserved in both cases (as long as typeset remains a reserved word).


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

* Re: "typeset -p" inconsistency
  2022-11-01  5:00                       ` "typeset -p" inconsistency Bart Schaefer
@ 2022-11-01 12:07                         ` Peter Stephenson
  2022-11-01 12:40                         ` Ray Andrews
  1 sibling, 0 replies; 39+ messages in thread
From: Peter Stephenson @ 2022-11-01 12:07 UTC (permalink / raw)
  To: Zsh Users

> On 01/11/2022 05:00 Bart Schaefer <schaefer@brasslantern.com> wrote:
> % setopt extendedglob
> % typeset -U CDPATH
> % typeset -mp '(#i)cdpath'
> typeset -aT CDPATH cdpath=(  )
> typeset -UT CDPATH cdpath=(  )
> 
> Note the -U attribute is only retained when printing the assignment
> for the scalar ... which is literally correct, since it was only
> asserted for the scalar, but lossy, whereas the array-ness is
> preserved in both cases (as long as typeset remains a reserved word).

That does correctly reflect the behaviour of the -U flag, however.

% typeset -T FOO foo
% foo=(one two three)   
% typeset -U foo
% print $foo
one two three
% foo+=(two)           # flag applied
% print $foo
one two three
% FOO+=:two            # flag not applied
% print $foo
one two three two

Other consequences of this are logical, e.g. "foo=($foo)" does
prune, "typeset -U FOO" works as expected.

The ideal output for typeset -p to reflect how this works might
be to output the typeset -T separately from any indication
of any flags set on one or other of the two interfaces to the
value, i.e. something like what I typed (but with the current
value somewhere).

typeset -T FOO foo=(one two three)
typeset -U foo

pws


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

* Re: "typeset -p" inconsistency
  2022-11-01  5:00                       ` "typeset -p" inconsistency Bart Schaefer
  2022-11-01 12:07                         ` Peter Stephenson
@ 2022-11-01 12:40                         ` Ray Andrews
  2022-11-01 19:08                           ` Bart Schaefer
  1 sibling, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-11-01 12:40 UTC (permalink / raw)
  To: zsh-users


On 2022-10-31 22:00, Bart Schaefer wrote:
> On Thu, Oct 20, 2022 at 7:25 PM, I wrote:
>>> typeset -T CDPATH cdpath=(  )
>>> typeset -aT CDPATH cdpath=(  )
>> The first one is the (incorrect) assignment for $CDPATH.
> Nobody called me out on that ... the first assignment is actually just
> fine.

But the 'typeset - g -aT ... ' remains a bug as you said?  Or at least a 
redundancy?




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

* Re: "typeset -p" inconsistency
  2022-11-01 12:40                         ` Ray Andrews
@ 2022-11-01 19:08                           ` Bart Schaefer
  2022-11-01 21:25                             ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Bart Schaefer @ 2022-11-01 19:08 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Nov 1, 2022 at 5:40 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-10-31 22:00, Bart Schaefer wrote:
> > On Thu, Oct 20, 2022 at 7:25 PM, I wrote:
> >>> typeset -T CDPATH cdpath=(  )
> >>> typeset -aT CDPATH cdpath=(  )
> >> The first one is the (incorrect) assignment for $CDPATH.
> > Nobody called me out on that ... the first assignment is actually just
> > fine.
>
> But the 'typeset - g -aT ... ' remains a bug as you said?  Or at least a
> redundancy?

That's not what I said, in either case.  Again, the -g appears only
when, from inside a function, you ask typeset (by passing the -p
option) to display a command that would create a variable that
persists (is global, hence -g) after the function returns.

The two examples above aren't really "redundant" either.  You asked
typeset to display commands to re-create all the current variables.
The first command is meant to re-create the scalar CDPATH and the
second is meant to re-create the array cdpath.  Because they could
have different attributes (the -U example you trimmed), it's not
redundant to output each of them separately.

The "buglet" is that if you execute both assignments, you end up
assigning all the attributes of either one of the pair to both of the
pair:

% typeset -UT FOO foo=(a b c b a)
% typeset -p foo
typeset -aUT FOO foo=( a b c )
% typeset -p FOO
typeset -UT FOO foo=( a b c )

Both have -U.  Now add -u to just the array:

% typeset -u foo
% typeset -p FOO
typeset -UT FOO foo=( a b c )
% typeset -p foo
typeset -auUT FOO foo=( a b c )

The output is different for each, as it should be ... but if I execute
that first one:

% typeset -auUT FOO foo=( a b c )
% typeset -p FOO
typeset -uUT FOO foo=( a b c )

Oops, we've added -u to FOO as well.  This is an inevitable ambiguity
in the syntax for creating tied variables.

One way to resolve it may be to separate the declaration of tied-ness
from the declaration of other attributes, as PWS mentioned, although I
think there's still ambiguity with respect to in which order the
declarations and the assignments must appear:

% typeset -u FOO
% typeset -T FOO foo=(a b c)
% typeset -p FOO
typeset -T FOO foo=( a b c )

Note -u has been lost from FOO by the subsequent -T declaration.  This
means we can't get away with outputting the assignments for each
variable as we encounter it in the hash table scan, but I'm also not
sure it's sufficient to first scan for and emit all the -T and then
emit all the attribute settings.

There's a comment in the code:

            * We choose to print the value for the array instead of the scalar
            * as scalars can't disambiguate between
            * typeset -T SCALAR array=()
            * and
            * typeset -T SCALAR array=('')

This is an impossible situation for assignment whenever there are
attributes of the scalar that are not in common with the array.

One possibility (which would be a backwards-incompatible change) would
be to treat

typeset -a ... -T FOO foo

as applying all flags to only the array, and

typeset ... -T FOO foo

(without -a) as applying all flags only to the scalar.  That doesn't
fix the assignment problem, though.  Another possibility would be to
allow attribute flags to appear between the scalar name and the array
name, something like:

typeset <attributes for both> -T <attributes for scalar> FOO
<attributes for array> foo

but that breaks the use of our generic option parsing code and still
doesn't solve the assignment ambiguity.


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

* Re: "typeset -p" inconsistency
  2022-11-01 19:08                           ` Bart Schaefer
@ 2022-11-01 21:25                             ` Ray Andrews
  2022-11-01 21:40                               ` Bart Schaefer
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-11-01 21:25 UTC (permalink / raw)
  To: zsh-users


On 2022-11-01 12:08, Bart Schaefer wrote:
> On Tue, Nov 1, 2022 at 5:40 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> But the 'typeset - g -aT ... ' remains a bug as you said?  Or at least a
>> redundancy?
> That's not what I said, in either case.

Right, I just dug up that reply.  My issue was the '-g' but that wasn't 
your issue.


> The two examples above aren't really "redundant" either.  You asked
> typeset to display commands to re-create all the current variables.

No mens rea, I have no thought to ask typeset to re-create anything, I 
just want a list of current variables, thassall.  As we discussed, 
there's this ambiguity between the passive and the active.  Strange that 
a request ends up as a re-creation.  Anyway I just filter the duplicates 
out, but it does seem very belabored.  I'd just use 'set', which doesn't 
show the duplicates, but then again typeset shows you the type of the 
variable.  Not to whine, but it doesn' t seem much to ask for a 'just 
show me' functionality -- set, but with the types.    No recreation of 
anything.  BTW


fignore=(  )
FPATH=/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion:/usr/share/zsh/functions/Completion/AIX:/usr/share/zsh/functions/Completion/BSD:/usr/share/zsh/functions/Completion/Base:/usr/share/zsh/functions/Completion/Cygwin:/usr/share/zsh/functions/Completion/Darwin:/usr/share/zsh/functions/Completion/Debian:/usr/share/zsh/functions/Completion/Linux:/usr/share/zsh/functions/Completion/Mandriva:/usr/share/zsh/functions/Completion/Redhat:/usr/share/zsh/functions/Completion/Solaris:/usr/share/zsh/functions/Completion/Unix:/usr/share/zsh/functions/Completion/X:/usr/share/zsh/functions/Completion/Zsh:/usr/share/zsh/functions/Completion/openSUSE:/usr/share/zsh/functions/Exceptions:/usr/share/zsh/functions/MIME:/usr/share/zsh/functions/Math:/usr/share/zsh/functions/Misc:/usr/share/zsh/functions/Newuser:/usr/share/zsh/functions/Prompts:/usr/share/zsh/functions/TCP:/usr/share/zsh/functions/VCS_Info:/usr/share/zsh/functions/VCS_Info/Backends:/usr/share/zsh/functions/Zftp:/usr/share/zsh/functions/Zle

... is that really necessary?  Wouldn't we expect folks to add to their 
fpath, or to the above, as they need?




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

* Re: "typeset -p" inconsistency
  2022-11-01 21:25                             ` Ray Andrews
@ 2022-11-01 21:40                               ` Bart Schaefer
  2022-11-01 22:46                                 ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Bart Schaefer @ 2022-11-01 21:40 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Nov 1, 2022 at 2:25 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> No mens rea, I have no thought to ask typeset to re-create anything

It doesn't actually re-create anything right then, but the definition
of -p is "display in the format of a typeset command" (implying the
desire that it actually do something if you were to execute that
command later).

> fignore=(  )
> FPATH=/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion:/usr/share/zsh/functions/Completion/AIX:/usr/share/zsh/functions/Completion/BSD:/usr/share/zsh/functions/Completion/Base:/usr/share/zsh/functions/Completion/Cygwin:/usr/share/zsh/functions/Completion/Darwin:/usr/share/zsh/functions/Completion/Debian:/usr/share/zsh/functions/Completion/Linux:/usr/share/zsh/functions/Completion/Mandriva:/usr/share/zsh/functions/Completion/Redhat:/usr/share/zsh/functions/Completion/Solaris:/usr/share/zsh/functions/Completion/Unix:/usr/share/zsh/functions/Completion/X:/usr/share/zsh/functions/Completion/Zsh:/usr/share/zsh/functions/Completion/openSUSE:/usr/share/zsh/functions/Exceptions:/usr/share/zsh/functions/MIME:/usr/share/zsh/functions/Math:/usr/share/zsh/functions/Misc:/usr/share/zsh/functions/Newuser:/usr/share/zsh/functions/Prompts:/usr/share/zsh/functions/TCP:/usr/share/zsh/functions/VCS_Info:/usr/share/zsh/functions/VCS_Info/Backends:/usr/share/zsh/functions/Zftp:/usr/share/zsh/functions/Zle
>
> ... is that really necessary?

Is what really necessary?  I don't understand the question.  (There's
no relationship between fignore and fpath or FPATH, if that's what you
mean.)


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

* Re: "typeset -p" inconsistency
  2022-11-01 21:40                               ` Bart Schaefer
@ 2022-11-01 22:46                                 ` Ray Andrews
  2022-11-02  1:13                                   ` Lawrence Velázquez
  2022-11-02  3:10                                   ` Bart Schaefer
  0 siblings, 2 replies; 39+ messages in thread
From: Ray Andrews @ 2022-11-01 22:46 UTC (permalink / raw)
  To: zsh-users


On 2022-11-01 14:40, Bart Schaefer wrote:
> It doesn't actually re-create anything right then, but the definition
> of -p is "display in the format of a typeset command"
Still I just wish there was some simple way of displaying the state of 
things without the pseudo re-creation.  It seems like a simple thing.
>
>> fignore=(  )
>> FPATH=/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion:/usr/share/zsh/functions/Completion/AIX:/usr/share/zsh/functions/Completion/BSD:/usr/share/zsh/functions/Completion/Base:/usr/share/zsh/functions/Completion/Cygwin:/usr/share/zsh/functions/Completion/Darwin:/usr/share/zsh/functions/Completion/Debian:/usr/share/zsh/functions/Completion/Linux:/usr/share/zsh/functions/Completion/Mandriva:/usr/share/zsh/functions/Completion/Redhat:/usr/share/zsh/functions/Completion/Solaris:/usr/share/zsh/functions/Completion/Unix:/usr/share/zsh/functions/Completion/X:/usr/share/zsh/functions/Completion/Zsh:/usr/share/zsh/functions/Completion/openSUSE:/usr/share/zsh/functions/Exceptions:/usr/share/zsh/functions/MIME:/usr/share/zsh/functions/Math:/usr/share/zsh/functions/Misc:/usr/share/zsh/functions/Newuser:/usr/share/zsh/functions/Prompts:/usr/share/zsh/functions/TCP:/usr/share/zsh/functions/VCS_Info:/usr/share/zsh/functions/VCS_Info/Backends:/usr/share/zsh/functions/Zftp:/usr/share/zsh/functions/Zle
>>
>> ... is that really necessary?
> Is what really necessary?  I don't understand the question.  (There's
> no relationship between fignore and fpath or FPATH, if that's what you
> mean.)

No, I mean it seems a bit long and a bit belabored.  I'm just saying 
that I'd expect those variables to be set to standard internal paths, 
and if someone is running some particular distro they can add to the 
paths as needed.  Dunno, maybe that stuff is genuinely current.  I see 
lots of stuff in the ..../Debian completions, I should take a close look 
-- there's been some work done there.  Just saying that having 
everything on the path seems superfluous.  If I run Debian I'll add the 
Debian directory but why the /Redhat?  Nevermind, it's such a small 
issue.  Come to think of it, those directories are in the 'fignore' ... 
are they to be ignored?




>

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

* Re: "typeset -p" inconsistency
  2022-11-01 22:46                                 ` Ray Andrews
@ 2022-11-02  1:13                                   ` Lawrence Velázquez
  2022-11-02  2:42                                     ` Ray Andrews
  2022-11-02  3:10                                   ` Bart Schaefer
  1 sibling, 1 reply; 39+ messages in thread
From: Lawrence Velázquez @ 2022-11-02  1:13 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Nov 1, 2022, at 6:46 PM, Ray Andrews wrote:
> On 2022-11-01 14:40, Bart Schaefer wrote:
>> It doesn't actually re-create anything right then, but the definition
>> of -p is "display in the format of a typeset command"
> Still I just wish there was some simple way of displaying the state of 
> things without the pseudo re-creation.  It seems like a simple thing.

"It seems like a simple thing" (based on zero evidence, btw) is not
a reason to duplicate existing functionality in a less precise and
significantly more verbose way.


>>> fignore=(  )
>>> FPATH=/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion:/usr/share/zsh/functions/Completion/AIX:/usr/share/zsh/functions/Completion/BSD:/usr/share/zsh/functions/Completion/Base:/usr/share/zsh/functions/Completion/Cygwin:/usr/share/zsh/functions/Completion/Darwin:/usr/share/zsh/functions/Completion/Debian:/usr/share/zsh/functions/Completion/Linux:/usr/share/zsh/functions/Completion/Mandriva:/usr/share/zsh/functions/Completion/Redhat:/usr/share/zsh/functions/Completion/Solaris:/usr/share/zsh/functions/Completion/Unix:/usr/share/zsh/functions/Completion/X:/usr/share/zsh/functions/Completion/Zsh:/usr/share/zsh/functions/Completion/openSUSE:/usr/share/zsh/functions/Exceptions:/usr/share/zsh/functions/MIME:/usr/share/zsh/functions/Math:/usr/share/zsh/functions/Misc:/usr/share/zsh/functions/Newuser:/usr/share/zsh/functions/Prompts:/usr/share/zsh/functions/TCP:/usr/share/zsh/functions/VCS_Info:/usr/share/zsh/functions/VCS_Info/Backends:/usr/share/zsh/functions/Zftp:/usr/share/zsh/functions/Zle
>>>
>>> ... is that really necessary?
>> Is what really necessary?  I don't understand the question.  (There's
>> no relationship between fignore and fpath or FPATH, if that's what you
>> mean.)
>
> No, I mean it seems a bit long and a bit belabored.  I'm just saying 
> that I'd expect those variables to be set to standard internal paths, 
> and if someone is running some particular distro they can add to the 
> paths as needed.

Ask whoever packaged your zsh.  That is not the default FPATH.


> Come to think of it, those directories are in the 'fignore' ... 
> are they to be ignored?

What?  Based on the output you shared, fignore is clearly empty.


-- 
vq


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

* Re: "typeset -p" inconsistency
  2022-11-02  1:13                                   ` Lawrence Velázquez
@ 2022-11-02  2:42                                     ` Ray Andrews
  2022-11-02  3:11                                       ` Lawrence Velázquez
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-11-02  2:42 UTC (permalink / raw)
  To: zsh-users


On 2022-11-01 18:13, Lawrence Velázquez wrote:
> "It seems like a simple thing" (based on zero evidence, btw) is not
> a reason to duplicate existing functionality in a less precise and
> significantly more verbose way.

Ironically my only thought was to reduce verbosity by getting rid of the 
duplication.

)

2 /aWorking/Zsh/Source/Wk 0 $ typeset -mp "(#i)path"
typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

2 /aWorking/Zsh/Source/Wk 0 $ . test; test path
typeset -g -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

... three different permutations for one and the same variable. I 
suppose one gets used to it, but at first it's pretty confusing.  But 
that's just me.

No, I mean it seems a bit long and a bit belabored.  I'm just saying
>> that I'd expect those variables to be set to standard internal paths,
>> and if someone is running some particular distro they can add to the
>> paths as needed.
> Ask whoever packaged your zsh.  That is not the default FPATH.
>
Ah!  So that's Debian's doing.  Funny they include so much stuff for 
other distros.  I'll edit that back to stock.  Mind, it's time I 
downloaded 5.9.  When I reinstalled Debian I just went with whatever 
came down the wire from them since I had to have a shell fast.  I've got 
the time to get it from the devs now.



>> Come to think of it, those directories are in the 'fignore' ...
>> are they to be ignored?
> What?  Based on the output you shared, fignore is clearly empty.

Probably got my wires crossed.  It was an off-hand question.


>
>


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

* Re: "typeset -p" inconsistency
  2022-11-01 22:46                                 ` Ray Andrews
  2022-11-02  1:13                                   ` Lawrence Velázquez
@ 2022-11-02  3:10                                   ` Bart Schaefer
  2022-11-02 17:09                                     ` Ray Andrews
  1 sibling, 1 reply; 39+ messages in thread
From: Bart Schaefer @ 2022-11-02  3:10 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Tue, Nov 1, 2022 at 3:46 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-11-01 14:40, Bart Schaefer wrote:
> > It doesn't actually re-create anything right then, but the definition
> > of -p is "display in the format of a typeset command"
> Still I just wish there was some simple way of displaying the state of
> things without the pseudo re-creation.  It seems like a simple thing.

paste =(typeset +) =(set)

or perhaps (following is one line, gmail may wrap it)

print -lr -- ${(*)${(Aok)parameters}//(#m)*/${(Pt)MATCH} "$(typeset -m
${(q)MATCH})"}

(Use "setopt extendedglob" instead of (*) for zsh before 5.9)

> >> fignore=(  )
> >> FPATH=...
>
> No, I mean it seems a bit long and a bit belabored.  I'm just saying
> that I'd expect those variables to be set to standard internal paths

The internal value for FPATH is determined by the build-time options
to match the install locations of the functions.  There are typically
two options:  Place all the function files in a single directory
(which results in a short FPATH but possible name collisions) or
preserve the source tree directory hierarchy (which results in what
you saw).  The latter is often used because then it's possible to
(after the fact) omit directories that are not relevant.

> Come to think of it, those directories are in the 'fignore' ...
> are they to be ignored?

Please disconnect fignore from FPATH in your brain.  They are totally
unrelated things.  You may be thinking of fpath, which is the
tied-array equivalent of the FPATH tied-scalar.


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

* Re: "typeset -p" inconsistency
  2022-11-02  2:42                                     ` Ray Andrews
@ 2022-11-02  3:11                                       ` Lawrence Velázquez
  2022-11-02 12:56                                         ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Lawrence Velázquez @ 2022-11-02  3:11 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Axel Beckert, zsh-users

On Tue, Nov 1, 2022, at 10:42 PM, Ray Andrews wrote:
> On 2022-11-01 18:13, Lawrence Velázquez wrote:
>> "It seems like a simple thing" (based on zero evidence, btw) is not
>> a reason to duplicate existing functionality in a less precise and
>> significantly more verbose way.
>
> Ironically my only thought was to reduce verbosity by getting rid of the 
> duplication.
>
> )
>
> 2 /aWorking/Zsh/Source/Wk 0 $ typeset -mp "(#i)path"
> typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
> /usr/local/bin /usr/sbin /usr/bin )
> export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
> /usr/local/bin /usr/sbin /usr/bin )
>
> 2 /aWorking/Zsh/Source/Wk 0 $ . test; test path
> typeset -g -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
> /usr/local/bin /usr/sbin /usr/bin )
> export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
> /usr/local/bin /usr/sbin /usr/bin )
>
> ... three different permutations for one and the same variable. I 
> suppose one gets used to it, but at first it's pretty confusing.  But 
> that's just me.

As Bart already explained, it is not "one and the same variable"
-- PATH and path are *two separate variables*.  So there is no
"duplication".

(I suppose one could argue that "-g" should always be output for
global variables, even outside of functions, for the sake of
consistency.)

(As an aside, "test" is a builtin and POSIX-mandated utility, so
using that name for your own purposes is not the best idea.)


>>> No, I mean it seems a bit long and a bit belabored.  I'm just saying
>>> that I'd expect those variables to be set to standard internal paths,
>>> and if someone is running some particular distro they can add to the
>>> paths as needed.
>> Ask whoever packaged your zsh.  That is not the default FPATH.
>>
> Ah!  So that's Debian's doing.  Funny they include so much stuff for 
> other distros.  I'll edit that back to stock.

That FPATH probably reflects the way Debian installs the functions,
so modifying it too much might actually break things.  (A stock zsh
installation just dumps all the functions into one directory.)
Perhaps Axel could provide some guidance here.


-- 
vq


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

* Re: "typeset -p" inconsistency
  2022-11-02  3:11                                       ` Lawrence Velázquez
@ 2022-11-02 12:56                                         ` Ray Andrews
  2022-11-02 17:04                                           ` Bart Schaefer
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-11-02 12:56 UTC (permalink / raw)
  To: zsh-users


On 2022-11-01 20:11, Lawrence Velázquez wrote:
> As Bart already explained, it is not "one and the same variable"
> -- PATH and path are *two separate variables*.  So there is no
> "duplication".
This country boy sees them as duplication.  'set' does not print them 
twice.  Anyway you guys are happy with it so I'm flogging a dead horse 
as usual.  Besides it's easy enough to filter out Tweedle-Dee and leave 
Tweedle-Dum cuz I learn nothing from the one that I don't already know 
from the other.  I know I'm fanatical about this sort of thing.
> (I suppose one could argue that "-g" should always be output for
> global variables, even outside of functions, for the sake of
> consistency.)

Consistency is one of my cardinal virtues, I like it alot.  The 
Linux/Unix world doesn't mind a bit of fuzz tho.

> (As an aside, "test" is a builtin and POSIX-mandated utility, so
> using that name for your own purposes is not the best idea.)
It's the sort of thing you learn via hard knocks.



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

* Re: "typeset -p" inconsistency
  2022-11-02 12:56                                         ` Ray Andrews
@ 2022-11-02 17:04                                           ` Bart Schaefer
  2022-11-02 17:19                                             ` Ray Andrews
  0 siblings, 1 reply; 39+ messages in thread
From: Bart Schaefer @ 2022-11-02 17:04 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Nov 2, 2022 at 5:56 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-11-01 20:11, Lawrence Velázquez wrote:
> > As Bart already explained, it is not "one and the same variable"
> > -- PATH and path are *two separate variables*.  So there is no
> > "duplication".
> This country boy sees them as duplication.  'set' does not print them
> twice.

Of course it does.

% set | grep -wi path
PATH=/opt/local/bin:/opt/local/sbin:/Users/schaefer/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin:/usr/X11/bin:/Library/PostgreSQL/8.3/bin:/Developer/usr/bin
path=( /opt/local/bin /opt/local/sbin /Users/schaefer/bin
/usr/local/bin /usr/bin /bin /sbin /usr/sbin /usr/X11/bin
/Library/PostgreSQL/8.3/bin /Developer/usr/bin )


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

* Re: "typeset -p" inconsistency
  2022-11-02  3:10                                   ` Bart Schaefer
@ 2022-11-02 17:09                                     ` Ray Andrews
  0 siblings, 0 replies; 39+ messages in thread
From: Ray Andrews @ 2022-11-02 17:09 UTC (permalink / raw)
  To: zsh-users


On 2022-11-01 20:10, Bart Schaefer wrote:
> paste =(typeset +) =(set) 


Messy.  I like my filters better.

> or perhaps (following is one line, gmail may wrap it)
>
> print -lr -- ${(*)${(Aok)parameters}//(#m)*/${(Pt)MATCH} "$(typeset -m
> ${(q)MATCH})"}
Deep magic.  I'm not ready to cast such spells.
>
> Please disconnect fignore from FPATH in your brain.  They are totally
> unrelated things.  You may be thinking of fpath, which is the
> tied-array equivalent of the FPATH tied-scalar.

I think I just got confused.  It was an off-hand thing, it just struck 
me that fpath was a bit bloated.  I'm a lean and mean sort of guy.




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

* Re: "typeset -p" inconsistency
  2022-11-02 17:04                                           ` Bart Schaefer
@ 2022-11-02 17:19                                             ` Ray Andrews
  2022-11-02 18:21                                               ` Bart Schaefer
  0 siblings, 1 reply; 39+ messages in thread
From: Ray Andrews @ 2022-11-02 17:19 UTC (permalink / raw)
  To: zsh-users


On 2022-11-02 10:04, Bart Schaefer wrote:
>
> Of course it does.
>
> % set | grep -wi path
> PATH=/opt/local/bin:/opt/local/sbin:/Users/schaefer/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin:/usr/X11/bin:/Library/PostgreSQL/8.3/bin:/Developer/usr/bin
> path=( /opt/local/bin /opt/local/sbin /Users/schaefer/bin
> /usr/local/bin /usr/bin /bin /sbin /usr/sbin /usr/X11/bin
> /Library/PostgreSQL/8.3/bin /Developer/usr/bin )
>
Different tho, they have different cases and there is that '-T' issue 
which is a complication perhaps better left as it is.  Only typeset 
gives us that '-g -aT' duplication.  Mind, typeset does deal with that 
elegantly:


2 /aWorking/Zsh/Source/Wk 0 $ typeset -mp "(#i)path"
typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )
export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin 
/usr/local/bin /usr/sbin /usr/bin )

... now that I understand it, I can see that 'PATH path' is just how it 
needs to be displayed.  But not twice please and of course you can add 
the '-g' if from within a function.  Nope, it's just not very friendly.  
I'm right about this.




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

* Re: "typeset -p" inconsistency
  2022-11-02 17:19                                             ` Ray Andrews
@ 2022-11-02 18:21                                               ` Bart Schaefer
  0 siblings, 0 replies; 39+ messages in thread
From: Bart Schaefer @ 2022-11-02 18:21 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Wed, Nov 2, 2022 at 10:19 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I'm right about this.

https://xkcd.com/386/


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

end of thread, other threads:[~2022-11-02 18:23 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-20 17:21 var=$( typeset "$1" ) ... not within a function Ray Andrews
2022-10-20 17:25 ` Roman Perepelitsa
2022-10-20 17:51   ` Ray Andrews
2022-10-20 17:54     ` Roman Perepelitsa
2022-10-20 18:38       ` Ray Andrews
2022-10-20 18:44         ` Roman Perepelitsa
2022-10-20 19:15           ` Ray Andrews
2022-10-20 19:35             ` Roman Perepelitsa
2022-10-20 20:48               ` Ray Andrews
2022-10-21  0:54                 ` Bart Schaefer
2022-10-21  1:58                   ` Ray Andrews
2022-10-21  2:25                     ` Bart Schaefer
2022-10-21 14:24                       ` Ray Andrews
2022-10-21 14:37                         ` Ray Andrews
2022-10-21 17:34                         ` Roman Perepelitsa
2022-11-01  5:00                       ` "typeset -p" inconsistency Bart Schaefer
2022-11-01 12:07                         ` Peter Stephenson
2022-11-01 12:40                         ` Ray Andrews
2022-11-01 19:08                           ` Bart Schaefer
2022-11-01 21:25                             ` Ray Andrews
2022-11-01 21:40                               ` Bart Schaefer
2022-11-01 22:46                                 ` Ray Andrews
2022-11-02  1:13                                   ` Lawrence Velázquez
2022-11-02  2:42                                     ` Ray Andrews
2022-11-02  3:11                                       ` Lawrence Velázquez
2022-11-02 12:56                                         ` Ray Andrews
2022-11-02 17:04                                           ` Bart Schaefer
2022-11-02 17:19                                             ` Ray Andrews
2022-11-02 18:21                                               ` Bart Schaefer
2022-11-02  3:10                                   ` Bart Schaefer
2022-11-02 17:09                                     ` Ray Andrews
2022-10-20 17:29 ` var=$( typeset "$1" ) ... not within a function Mikael Magnusson
2022-10-20 17:43   ` Ray Andrews
2022-10-21 17:33 ` Ray Andrews
2022-10-21 18:25   ` Bart Schaefer
2022-10-21 18:57     ` Ray Andrews
2022-10-21 19:02       ` Roman Perepelitsa
2022-10-21 19:06         ` Ray Andrews
2022-10-21 19:04     ` Ray Andrews

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).