* 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: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-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
* "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-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 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
* 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 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: 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: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 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 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
* 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
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).