* path PATH @ 2023-01-20 21:57 Ray Andrews 2023-01-20 22:20 ` Bart Schaefer 2023-01-21 5:47 ` Lawrence Velázquez 0 siblings, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-20 21:57 UTC (permalink / raw) To: Zsh Users $ echo $path . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin $ echo $PATH .:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin $ typeset -p path typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) $ typeset -p PATH export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... looks like typeset doesn't want to show the real contents of $PATH. As I understand it, the '-T' switch links two arrays that have different names but the same content. Is this an exception? Might hafta be, because I know that the two are linked even tho they format differently. Still one should be able to view $PATH 'honestly' no? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-20 21:57 path PATH Ray Andrews @ 2023-01-20 22:20 ` Bart Schaefer 2023-01-21 2:23 ` Ray Andrews 2023-01-21 5:47 ` Lawrence Velázquez 1 sibling, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-20 22:20 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users Have you completely forgotten the lengthy thread (Subject: "typeset -p" inconsistency) that we had the first week of last November? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-20 22:20 ` Bart Schaefer @ 2023-01-21 2:23 ` Ray Andrews 2023-01-21 6:11 ` Lawrence Velázquez 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-21 2:23 UTC (permalink / raw) To: zsh-users On 2023-01-20 14:20, Bart Schaefer wrote: > Have you completely forgotten the lengthy thread (Subject: "typeset > -p" inconsistency) that we had the first week of last November? > Not completely, but perhaps some detail. It was one of those things that swamped me with too much to learn too quickly. Anyway, all the other '-T' arrays show identical content for either version, only 'PATH path' has this issue AFAICT. And only PATH path is reported as 'export -T' (as well as 'typeset -g -aT', but all the '-T' arrays have double entries tho only PATH path has that unique 2nd version). $ typeset -p | grep --color=always -- '^export -T' export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... so it is unique. Anyway it's a small thing but I'm wondering why only the one 'version' is ever shown. If it was covered, pardon, I've forgotten that. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 2:23 ` Ray Andrews @ 2023-01-21 6:11 ` Lawrence Velázquez 2023-01-21 15:18 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-21 6:11 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Jan 20, 2023, at 9:23 PM, Ray Andrews wrote: > And only PATH path is reported as 'export > -T' (as well as 'typeset -g -aT', but all the '-T' arrays have double > entries tho only PATH path has that unique 2nd version). > > $ typeset -p | grep --color=always -- '^export -T' > export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin > /usr/local/bin /usr/sbin /usr/bin ) > > ... so it is unique. No, that just means that PATH is the only global scalar that has been tied and exported. If you tie and export additional ones they'll show up too. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 6:11 ` Lawrence Velázquez @ 2023-01-21 15:18 ` Ray Andrews 2023-01-21 15:25 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-21 15:18 UTC (permalink / raw) To: zsh-users On 2023-01-20 22:11, Lawrence Velázquez wrote: > >> ... so it is unique. > No, that just means that PATH is the only global scalar that has > been tied and exported. If you tie and export additional ones > they'll show up too. > But if it is the only one then it is unique. I didn't suggest that the same situation might not be applied to another parameter, only that it has not been. It just served as a possible clue as to why no variation of 'typeset' will show you: 3 /aWorking/Zsh/Source/Wk 0 $ echo $PATH .:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin > No, "typeset -T" ties an array to a scalar, which is synthesized by joining the array's values with a separator character. Now that you mention it, $PATH is a scalar ... hasta be because there's no spaces. But all the others display as arrays, so that's where I went wrong there. But 'PATH path' always displays as an array too. It still seems to be an anomaly. So then if we had other tied scalars they too would only display as arrays? Anyway, perhaps this just isn't worth worrying about, $PATH is a special case (I think) because as you say it's 'synthesized' via the joining of members with the colon vs. the space. I dislike exceptions and special cases but perhaps this one is unavoidable. (Obviously the way $PATH works is by now fundamental, but I can't help wondering why a space separated array wouldn't work, like $path. IOW, given $path, why do we need $PATH at all?) Nevermind, I'm inclined to fret about things like this, it's not important I'd just like typeset to show me $PATH as it really is not pretend that's it's identical to $path when it isn't. Accuracy matters no? : $ set | grep -i "^path" PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... In fact I'm trying to write a function that will show me *both* the type of all variables (typeset) *and* their accurate values (set). I've got it nailed down except for $PATH and the one exception bothers me. But life is one big exception. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 15:18 ` Ray Andrews @ 2023-01-21 15:25 ` Roman Perepelitsa 2023-01-21 16:21 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-21 15:25 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023 at 4:18 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-20 22:11, Lawrence Velázquez wrote: > > > >> ... so it is unique. > > No, that just means that PATH is the only global scalar that has > > been tied and exported. If you tie and export additional ones > > they'll show up too. PATH isn't special. Here: % export -T FOO foo=( bar baz ) % typeset -p FOO export -T FOO foo=( bar baz ) The output of `typeset -p` is a command that you can evaluate to set the parameter to its current value. Do you see that everything works as intended? If not, what do you think `typeset -p FOO` should output here? Keep in mind that it must be a command that you can evaluate to set the parameter to its current value. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 15:25 ` Roman Perepelitsa @ 2023-01-21 16:21 ` Ray Andrews 2023-01-21 16:38 ` Roman Perepelitsa 2023-01-21 16:48 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-21 16:21 UTC (permalink / raw) To: zsh-users On 2023-01-21 07:25, Roman Perepelitsa wrote: > PATH isn't special. Here: I understand. One could create other variables that show as 'export -T ...' but this is not actually done in the raw shell, so PATH is unique even if not 'special' as you use the word. However it is 'special' in that 'typeset -p PATH' does not show it's accurate value. I suspect that, as Lawrence said, it's because PATH is an internally created modification of path, it's a scalar created from an array. So FOO is all fine, but PATH has a certain specialness -- no other tied parameter has one 'version' different from the other. This might be unfixable in as much as 'typeset -p' displays information via a sort of re-creation (as Bart explained a few months ago) -- which seems very strange to me but what do I know? IOW typeset *itself* might not even 'know' that PATH != path, all it knows is that the two are tied and that PATH points to path. It does not know that PATH is then modified. Stalemate. It bugs me but thereyago. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 16:21 ` Ray Andrews @ 2023-01-21 16:38 ` Roman Perepelitsa 2023-01-21 16:54 ` Ray Andrews 2023-01-21 16:48 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-21 16:38 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023 at 5:21 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > One could create other variables that show as 'export -T > ...' but this is not actually done in the raw shell, so PATH is unique > even if not 'special' as you use the word. I'm not sure what you are trying to say here. PATH has a unique name, yes, but it behaves like any other parameter. In particular, `typeset -p` works on PATH the same way as on any other parameter. Perhaps you want `typeset -p` to work differently for PATH? In other words, do you want PATH to be special? > However it is 'special' in that 'typeset -p PATH' does not show > it's accurate value. `typeset -p PATH` does show the precise and accurate value of PATH. It's so precise and accurate that you can literally evaluate the output to obtain exactly the same state of PATH in another shell. The job of `typeset -p` is to tell you precisely and accurately what a certain parameter is. The output of `typeset -p PATH` achieves that. There is no hidden "real" value that it doesn't show. It shows every bit of information related to PATH. Consider this snippet: % typeset foo=$'1\n2' % print -r -- $foo 1 2 % typeset -p foo typeset foo=$'1\n2' Is `typeset -p` also not printing the "real" value of the parameter here? I'll ask again: what do you think should be the output of `typeset -p PATH`? Roman. P.S. I think you perceive some difference between PATH and FOO from my previous email. There isn't any. There are some tools (commands and builtins) whose *behavior* depends on PATH, but that doesn't imply anything special about the parameter itself. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 16:38 ` Roman Perepelitsa @ 2023-01-21 16:54 ` Ray Andrews 2023-01-21 17:01 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-21 16:54 UTC (permalink / raw) To: zsh-users On 2023-01-21 08:38, Roman Perepelitsa wrote: > `typeset -p PATH` does show the precise and accurate value of PATH. 3 /aWorking/Zsh/Source/Wk 1 $ set | grep "^PATH" PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin 3 /aWorking/Zsh/Source/Wk 1 $ typeset -p PATH export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 16:54 ` Ray Andrews @ 2023-01-21 17:01 ` Roman Perepelitsa 2023-01-21 18:53 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-21 17:01 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023 at 5:54 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-21 08:38, Roman Perepelitsa wrote: > > `typeset -p PATH` does show the precise and accurate value of PATH. > > 3 /aWorking/Zsh/Source/Wk 1 $ set | grep "^PATH" > PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin > > 3 /aWorking/Zsh/Source/Wk 1 $ typeset -p PATH > export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin > /usr/local/bin /usr/sbin /usr/bin ) Can you elaborate? Do you believe that these two commands should have identical output? Does it bother you that in the following snippet the last two commands also don't have identical output? % export -i8 BAR=42 % typeset -p BAR export -i8 BAR=42 % env | grep BAR BAR=8#52 These are different commands and they have different output. Neither shows the "true" or "real" value of the parameter. `typeset -p` shows exactly and precisely what a zsh parameter is, while `env` shows the environment. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 17:01 ` Roman Perepelitsa @ 2023-01-21 18:53 ` Ray Andrews 2023-01-21 19:09 ` Roman Perepelitsa 2023-01-21 20:19 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-21 18:53 UTC (permalink / raw) To: zsh-users On 2023-01-21 09:01, Roman Perepelitsa wrote: > >> 3 /aWorking/Zsh/Source/Wk 1 $ set | grep "^PATH" >> PATH=.:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin >> >> 3 /aWorking/Zsh/Source/Wk 1 $ typeset -p PATH >> export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin >> /usr/local/bin /usr/sbin /usr/bin ) > Can you elaborate? Do you believe that these two commands should have > identical output? Yes. Both would seem to be displaying values. And in every case except PATH, that is exactly what happens. > > Does it bother you that in the following snippet the last two commands > also don't have identical output? > > % export -i8 BAR=42 > > % typeset -p BAR > export -i8 BAR=42 > > % env | grep BAR > BAR=8#52 > > These are different commands and they have different output. Neither > shows the "true" or "real" value of the parameter. `typeset -p` shows > exactly and precisely what a zsh parameter is, while `env` shows the > environment. That's a bit Byzantine isn't it? If 'env' displays the base of the number whereas typeset displays the command by which the base was forced, no I don't think that's a genuine comparison. It's nothing the same as PATH displaying with spaces when in fact it has colons. In your example one clearly anticipates the other; it's actually the same information just formatted differently. Bart: > The definition of a tied parameter is that one of the pair is a scalar string with an internal delimiter defaulting to a colon, and the other is an array of the delimited values. There's nothing magic about PATH in this respect. Ah! So now we're barking up the same tree. But ... all the other tied parameters look like merely the same array with two different names. Have I made the wrong pattern? ... Yes, I have: set | grep FPATH ... and what do I see but colons! NUTS! All the others, there's only one element so there's no chance for the colons to show up :( they define as arrays, but there's actually just the one element so that's where I lost the scent. I get it. Many thanks. So PATH is indeed unique but it isn't special :) ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 18:53 ` Ray Andrews @ 2023-01-21 19:09 ` Roman Perepelitsa 2023-01-21 20:50 ` Ray Andrews 2023-01-21 20:19 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-21 19:09 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023 at 7:54 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > It's nothing the same as PATH displaying with spaces when in fact it > has colons. Is the number 42 "in fact" 8#52? When you type `typeset -p PATH` you are asking zsh "what exactly is PATH parameter" and zsh answers *this* question precisely and accurately. When you type `printenv PATH`, you are asking "what is the value of PATH environment variable" and you get the answer to *this* question precisely and accurately. The two answers aren't the same because the questions aren't the same. Both answers are correct for the respective questions and they would be nonsense if the questions were swapped. I gotta say, in pretty much every thread where you asked a question I'm left wondering whether you understood what I was saying. From my point of view the answer is logical and in a sense obvious, but every response I can elicit from you leaves me doubtful. Do you see that `typeset -p PATH` prints the right answer to the question you are asking and that any other output would have been wrong? Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 19:09 ` Roman Perepelitsa @ 2023-01-21 20:50 ` Ray Andrews 2023-01-21 21:11 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-21 20:50 UTC (permalink / raw) To: zsh-users On 2023-01-21 11:09, Roman Perepelitsa wrote: > Is the number 42 "in fact" 8#52? Yes, it most certainly is -- in base 8, which is explicit. > I gotta say, in pretty much every thread where you asked a question > I'm left wondering whether you understood what I was saying. From my > point of view the answer is logical and in a sense obvious Ah, we'll that's the thing, one can misunderstand some basic premise which makes everything subsequent illogical. Bart cleared this up by disabusing me of the idea that that a tie was just another name for exactly the same thing, and that *appears* to be the case. It seemed so obviously the case that I didn't even ask the question. But no! a tie creates a scalar with the array elements joined by colons ... $PATH! But since typeset -p, in every other situation, shows you the value of a parameter I'm wanting the same for PATH. I'd use set -- which shows it accurately with the colons -- *but* I'd also like to see the type of the variable besides it's value which pushes me back to typeset -p. So, there's no easy answer. I just hafta remember that PATH, like any other tied param, will be a scalar created from an array and sorry, it can't be displayed like that by typeset -p. Dunno, maybe I can hack something together but probably not worth it. One might wish for an option to set that would include type as well as value. No typeset -p 'recreation', just the information. I sorta understand why typeset itself is not the vehicle for this since it's not by nature a 'viewer' but a 'creator'. Anyway I've wasted enough of you guy's time with this. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 20:50 ` Ray Andrews @ 2023-01-21 21:11 ` Roman Perepelitsa 0 siblings, 0 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-21 21:11 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023 at 9:51 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-21 11:09, Roman Perepelitsa wrote: > > Is the number 42 "in fact" 8#52? > Yes, it most certainly is -- in base 8, which is explicit. It's a different representation for the same thing, isn't it? Neither is the real thing or the actual value. The same goes for "A", "\x41" and "\101". These are different representations for the same object, with none being the object itself. Now, when `typeset -p` prints the value of a parameter, it has to choose some representations and there is no obvious choice, for no representation is "the true one". In this case it so happens that the representation for a tied parameter chosen by `typeset -p` is the array's elements, while you would prefer to see a different representation -- that of the scalar. Whenever you simply need to know what a parameter is, any representation will suffice and so you use `typeset -p`. When you need to see a specific representation, you should not use `typeset -p` and instead arrange for your preferred representation to be produced explicitly. In this case that could be: print -r -- "PATH=${(qqq)PATH}" Or maybe you'll prefer a different quoting scheme. In any case, if you want a specific representation, ask for that explicitly. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 18:53 ` Ray Andrews 2023-01-21 19:09 ` Roman Perepelitsa @ 2023-01-21 20:19 ` Bart Schaefer 2023-01-21 20:26 ` env arrays (was: Re: path PATH) zeurkous 2023-01-21 21:03 ` path PATH Ray Andrews 1 sibling, 2 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-21 20:19 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023 at 10:54 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > NUTS! All the others, there's only one element so there's no chance for > the colons to show up :( they define as arrays, but there's actually > just the one element so that's where I lost the scent. I get it. Many > thanks. So PATH is indeed unique but it isn't special :) It's actually the other way around; it's special (because it cannot be un-tied) but not unique. These scalar variables are tied, exported, and special: PATH MANPATH These scalars are tied and special but not (by default) exported: CDPATH FIGNORE FPATH MAILPATH MODULE_PATH PSVAR ZSH_EVAL_CONTEXT These all behave the same way with respect to the array value being joined by colons to form the scalar value, and they all remain tied even if you unset them (as in, both parts of each pair will reappear as soon as you assign a value to either the scalar or the array). The reason for this tied behavior is so that the scalar parts CAN be exported, because the environment cannot contain arrays. ^ permalink raw reply [flat|nested] 119+ messages in thread
* env arrays (was: Re: path PATH) 2023-01-21 20:19 ` Bart Schaefer @ 2023-01-21 20:26 ` zeurkous 2023-01-22 17:28 ` Bart Schaefer 2023-01-21 21:03 ` path PATH Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: zeurkous @ 2023-01-21 20:26 UTC (permalink / raw) To: Bart Schaefer, Ray Andrews; +Cc: zsh-users On Sat, 21 Jan 2023 12:19:51 -0800, Bart Schaefer <schaefer@brasslantern.com> wrote: > The > reason for this tied behavior is so that the scalar parts CAN be > exported, because the environment cannot contain arrays. It might not be able to contain arrays, but it's possible to have it contain array *elements*-- % env 'blaat[0]=scaahp' 'blaat[1]=mekker' env | tail -n 2 blaat[0]=scaahp blaat[1]=mekker % Can zsh work w/ such an approach? By default megets-- % setopt KSH_ARRAYS % blaat[0]=scaahp % export 'blaat[0]' % env [...no 'blaat[0]' in there...] % 'blaat[0]'=scaahp zsh: command not found: blaat[0]=scaahp % export 'blaat[0]'=scaahp % env [...no 'blaat[0]' in there either...] --zeurkous. -- Friggin' Machines! ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: env arrays (was: Re: path PATH) 2023-01-21 20:26 ` env arrays (was: Re: path PATH) zeurkous @ 2023-01-22 17:28 ` Bart Schaefer 0 siblings, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 17:28 UTC (permalink / raw) To: zeurkous; +Cc: Ray Andrews, zsh-users On Sat, Jan 21, 2023 at 12:38 PM <zeurkous@blaatscaahp.org> wrote: > > It might not be able to contain arrays, but it's possible to have it > contain array *elements*-- > > % env 'blaat[0]=scaahp' 'blaat[1]=mekker' env | tail -n 2 > blaat[0]=scaahp > blaat[1]=mekker > % > > Can zsh work w/ such an approach? It could be implemented, but unless we were to rewrite the internals to use sparse arrays, import of that syntax would allow the moral equivalent of a zip bomb: env 'kaboom[999999999999999999]=waytoobig' ... Generally speaking, for security you do not want environment strings to be "programmable" in any sense. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 20:19 ` Bart Schaefer 2023-01-21 20:26 ` env arrays (was: Re: path PATH) zeurkous @ 2023-01-21 21:03 ` Ray Andrews 2023-01-21 21:52 ` Lawrence Velázquez 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-21 21:03 UTC (permalink / raw) To: zsh-users On 2023-01-21 12:19, Bart Schaefer wrote: > > It's actually the other way around; it's special (because it cannot be > un-tied) but not unique. It's the only one that displays as 'export -T'. Here, anyway. > These scalar variables are tied, exported, > and special: > > PATH > MANPATH Here: MANPATH is: 'typeset -T' like several others. But it's good to know that indeed there are special values that will be treated differently. So I was right about PATH but for the wrong reason ... which is simply being wrong. > The > reason for this tied behavior is so that the scalar parts CAN be > exported, because the environment cannot contain arrays. Ah! That answers my question as to what all this tie-dying is about. I had no idea you can't export arrays. Marvelous. You know, when you understand why something is, then what it is becomes much easier. The clouds part. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 21:03 ` path PATH Ray Andrews @ 2023-01-21 21:52 ` Lawrence Velázquez 2023-01-22 0:42 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-21 21:52 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 21, 2023, at 4:03 PM, Ray Andrews wrote: > On 2023-01-21 12:19, Bart Schaefer wrote: >> >> It's actually the other way around; it's special (because it cannot be >> un-tied) but not unique. > It's the only one that displays as 'export -T'. Here, anyway. Why do you keep harping on this, despite everything we've said? Again, the fact that your shell only has one variable that "typeset -p" displays this way is incidental; you could create more any time you want. Imagine if I were trying to open some files in a text editor, but they all looked like gibberish except one, and then I confidently concluded that the editor must be treating that one file specially instead of considering that maybe I had only one text file. >> These scalar variables are tied, exported, >> and special: >> >> PATH >> MANPATH > > Here: MANPATH is: 'typeset -T' like several others. If you were to set it in a typical way... export MANPATH=/one/path:/another/path:/a/third/path ...then it would display as PATH does. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 21:52 ` Lawrence Velázquez @ 2023-01-22 0:42 ` Ray Andrews 2023-01-22 12:29 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-22 0:42 UTC (permalink / raw) To: zsh-users On 2023-01-21 13:52, Lawrence Velázquez wrote: > Why do you keep harping on this, despite everything we've said? > Again, the fact that your shell only has one variable that "typeset > -p" displays this way is incidental; you could create more any time > you want. I quite understand. It is unique HERE, and that's what lead me to think it was in a category all it's own. I was wrong. I get it now. Roman: > When you need to see a specific representation, you should not use `typeset -p` and instead arrange for your preferred representation to be produced explicitly. Exactly. But as I said, I want to display the types too, and had hoped it would be possible, but it isn't so that's that. But now that I know exactly how the scalar is created and what it must look like, the problem becomes trivial -- replace spaces with colons. My big error was thinking the tied names were just basically aliases for exactly the same array so PATH path *seemed* like a special case. Dunno, it was just a post-mortem on where I went astray. I've wasted enough of your time on this. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 0:42 ` Ray Andrews @ 2023-01-22 12:29 ` Roman Perepelitsa 2023-01-22 14:17 ` Ray Andrews 2023-01-22 19:20 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-22 12:29 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023 at 1:42 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > I want to display the types too, and had hoped it would be possible, but it isn't so that's that. Perhaps you can use something like this to describe parameters: describe-param() { emulate -L zsh [[ ARGC -eq 1 && -n $1 ]] || return set -- "$@" ${(Pt)1} [[ -$2- == *-hide-* ]] && return 1 print -rn -- "$2 ${(q-)1}" if [[ -$2- == *-hideval-* ]]; then print else set -- "$@" ${(M)2:#(array|association)(|-*)} print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}" fi } The output of this function is of the following shape: <TYPE> <NAME>[=<VALUE>] For example: % describe-param PWD scalar-export PWD="/home/romka" % describe-param MAILCHECK integer MAILCHECK="60" % describe-param PATH scalar-tied-export-special PATH="/home/romka/bin:..." % describe-param path array-tied-unique-special path=( "/home/romka/bin" ... ) You might want to customize how the type is printed. If you want to describe all parameters, you can do it like this: for name in ${(k)parameters}; do describe-param $name done Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 12:29 ` Roman Perepelitsa @ 2023-01-22 14:17 ` Ray Andrews 2023-01-22 16:15 ` Bart Schaefer 2023-01-22 19:20 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-22 14:17 UTC (permalink / raw) To: zsh-users On 2023-01-22 04:29, Roman Perepelitsa wrote: > > Perhaps you can use something like this to describe parameters: > > describe-param() { > emulate -L zsh > [[ ARGC -eq 1 && -n $1 ]] || return > set -- "$@" ${(Pt)1} > [[ -$2- == *-hide-* ]] && return 1 > print -rn -- "$2 ${(q-)1}" > if [[ -$2- == *-hideval-* ]]; then > print > else > set -- "$@" ${(M)2:#(array|association)(|-*)} > print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}" > fi > } > Fantastic. I've never seen parameter descriptions of that sort. So verbal, so helpful , so complete. Whoever coded that was a friend of humanity that day: 5 /aWorking/Zsh/Source/Wk 0 $ describe-param PATH scalar-tied-export-special PATH=".:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin" 5 /aWorking/Zsh/Source/Wk 0 $ describe-param path array-tied-special path=( "." "/aWorking/Zsh/System" "/aWorking/Bin" "/usr/local/bin" "/usr/sbin" "/usr/bin" ) ... ALL the information, all the time. I'll bet it even works on Tuesdays. Dunno, it's mostly a psychological thing but whereas most of the time brief, compact information is all you need, it is nice to know that when you hafta, you can get ALL the information. I learn that PATH is exported and path is not! Who knew? typeset -p obfuscates more than helps. But, as Bart was saying, we can't export arrays (why not? it seems arbitrary), so that's what PATH is for. Complete information explains itself. If I'd had that function from the getgo, this entire thread would have been unnecessary, the issue would have explained itself. It's going to be a good day. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 14:17 ` Ray Andrews @ 2023-01-22 16:15 ` Bart Schaefer 2023-01-22 17:23 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 16:15 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023 at 6:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Fantastic. I've never seen parameter descriptions of that sort. This is exactly what I suggested in zsh-users/28317 last November, except I wrote it as a one-liner using the $parameters variable. > But, as Bart was saying, we can't export arrays (why not? it > seems arbitrary) The operating system defines the environment as an array ("C" language) of strings; you can't nest the arrays. The way an array is represented in the environment is by convention to separate the elements with colons. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 16:15 ` Bart Schaefer @ 2023-01-22 17:23 ` Ray Andrews 0 siblings, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-22 17:23 UTC (permalink / raw) To: zsh-users On 2023-01-22 08:15, Bart Schaefer wrote: > This is exactly what I suggested in zsh-users/28317 last November, > except I wrote it as a one-liner using the $parameters variable. It can take a while for things to sink in. One has to be ready. There are times when some question or some mistake of mine leads to a tsunami of fixes, cascading mental adjustments -- mistakes within mistakes, new ideas, re-thinks -- a whole lot of dominos fall over and I can't stand them all back up again in one go. > The operating system defines the environment as an array ("C" > language) of strings; you can't nest the arrays. The way an array is > represented in the environment is by convention to separate the > elements with colons. I just love these deep insights. So this drills right down to a C limitation! Or should I say an OS limitation? C would permit a structure even if Linux won't countenance it. Mind, it's the sort of thing that's so deep in the bedrock that a change is hardly possible. Your answer cures me of any whinyness -- not zsh's issue. Death and taxes and no arrays in the environment, get used to it. But now I finally get the point of those colons, it seemed dumb -- PATH is 'naturally' an array. So we have $path :-) And I can confidently extrapolate that path is created from PATH, not visa versa, yes? (Cuz a given shell can only 'inherit' PATH, thus the friendlier path must be the derivative.) ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 12:29 ` Roman Perepelitsa 2023-01-22 14:17 ` Ray Andrews @ 2023-01-22 19:20 ` Bart Schaefer 2023-01-22 19:31 ` Roman Perepelitsa 2023-01-22 19:52 ` Ray Andrews 1 sibling, 2 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 19:20 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users On Sun, Jan 22, 2023 at 4:30 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > describe-param() { > emulate -L zsh > [[ ARGC -eq 1 && -n $1 ]] || return > set -- "$@" ${(Pt)1} > [[ -$2- == *-hide-* ]] && return 1 I'm curious why you chose to do this? The "hide" attribute means that a local does not preserve semantics of a special global, not that it's name is invisible. > print -rn -- "$2 ${(q-)1}" > if [[ -$2- == *-hideval-* ]]; then > print I'd guess that Ray would prefer to see the value even if it's normally hidden by "set" but this is more consistent. > else > set -- "$@" ${(M)2:#(array|association)(|-*)} > print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}" If you leave off the "${(q-)1}" in the earlier "print -rn", I think this is just typeset -m ${(q)1} (where I'm not even sure the (q) is necessary). > fi > } [...] > If you want to describe all parameters, you can do it like this: > > for name in ${(k)parameters}; do > describe-param $name > done If the $parameters array is thrown in to the function itself, we can make describe-param accept multiple names and patterns. describe-params () { emulate -L zsh -o extendedglob zmodload zsh/parameter set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} while ((ARGC)) do print -rn -- "${parameters[$1]} " if [[ -${parameters[$1]}- = *-hideval-* ]] then print -r -- ${(q-)1} else typeset -m ${(q)1} fi shift done } Now describing all parameters is just describe-params '*' and it'll also handle describe-params '*(#i)path' '(#i)zsh*' etc. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:20 ` Bart Schaefer @ 2023-01-22 19:31 ` Roman Perepelitsa 2023-01-22 19:51 ` Bart Schaefer 2023-01-22 19:52 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-22 19:31 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Sun, Jan 22, 2023 at 8:20 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sun, Jan 22, 2023 at 4:30 AM Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > > > describe-param() { > > emulate -L zsh > > [[ ARGC -eq 1 && -n $1 ]] || return > > set -- "$@" ${(Pt)1} > > [[ -$2- == *-hide-* ]] && return 1 > > I'm curious why you chose to do this? The "hide" attribute means that > a local does not preserve semantics of a special global, not that it's > name is invisible. That's a brainfart on my part. I even know what "hide" means but somehow I've coded it as if it meant something else. > > print -rn -- "$2 ${(q-)1}" > > if [[ -$2- == *-hideval-* ]]; then > > print > > I'd guess that Ray would prefer to see the value even if it's normally > hidden by "set" but this is more consistent. I mainly added this after seeing just how much output there is if you print values of all parameters. Made me appreciate the fact that `typeset` doesn't print those. > > else > > set -- "$@" ${(M)2:#(array|association)(|-*)} > > print -r -- "=${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}" > > If you leave off the "${(q-)1}" in the earlier "print -rn", I think this is just > typeset -m ${(q)1} Oh, I only now realized that the output of `typeset -m` isn't the same as of `typeset -p` (I now see that you've pointed this out in earlier emails but I missed it). This is definitely an improvement to the code but makes me wonder whether it's a good thing that typeset behaves this way. Intuitively, I expected that `typeset -m pat` is equivalent to `typeset -p [params]..` where `[params]..` is the names of all parameters matching `pat`. > (where I'm not even sure the (q) is necessary). I think it should be (b). > describe-params () { > emulate -L zsh -o extendedglob > zmodload zsh/parameter > set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} > while ((ARGC)) > do > print -rn -- "${parameters[$1]} " > if [[ -${parameters[$1]}- = *-hideval-* ]] > then > print -r -- ${(q-)1} > else > typeset -m ${(q)1} > fi > shift > done > } This looks great! Simpler and more powerful than my version. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:31 ` Roman Perepelitsa @ 2023-01-22 19:51 ` Bart Schaefer 2023-01-22 19:56 ` Roman Perepelitsa ` (2 more replies) 0 siblings, 3 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 19:51 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users On Sun, Jan 22, 2023 at 11:31 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > Intuitively, I expected that `typeset -m pat` is equivalent > to `typeset -p [params]..` where `[params]..` is the names of all > parameters matching `pat`. You can get this by combining -p and -m, which I think is one reason why -m is different. > > (where I'm not even sure the (q) is necessary). > > I think it should be (b). Are there valid characters in an identifier name that would be quoted differently by (b) and (q)? I did find a bug: describe-params - Revised: describe-params () { emulate -L zsh -o extendedglob set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} while ((ARGC)) do print -rn -- "${parameters[$1]} " if [[ -${parameters[$1]}- = *-hideval-* ]] then print -r -- ${(q-)1} else typeset -m -- ${(b)1} fi shift done } ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:51 ` Bart Schaefer @ 2023-01-22 19:56 ` Roman Perepelitsa 2023-01-22 20:03 ` Bart Schaefer 2023-01-22 20:12 ` Ray Andrews 2023-01-24 20:00 ` Ray Andrews 2023-01-24 23:28 ` Ray Andrews 2 siblings, 2 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-22 19:56 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Sun, Jan 22, 2023 at 8:51 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sun, Jan 22, 2023 at 11:31 AM Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > > > Intuitively, I expected that `typeset -m pat` is equivalent > > to `typeset -p [params]..` where `[params]..` is the names of all > > parameters matching `pat`. > > You can get this by combining -p and -m, which I think is one reason > why -m is different. It's still weird. I would accept this reasoning if `typeset path` produced the same output as `typeset -m path` but it doesn't. Something feels off. > > > (where I'm not even sure the (q) is necessary). > > > > I think it should be (b). > > Are there valid characters in an identifier name that would be quoted > differently by (b) and (q)? I don't know. I said it should be (b) because it would be correct by design while (q) could only be correct by coincidence. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:56 ` Roman Perepelitsa @ 2023-01-22 20:03 ` Bart Schaefer 2023-01-22 21:56 ` Bart Schaefer 2023-01-22 20:12 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 20:03 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: zsh-users On Sun, Jan 22, 2023 at 11:56 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > On Sun, Jan 22, 2023 at 8:51 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > > > You can get this by combining -p and -m, which I think is one reason > > why -m is different. > > It's still weird. I would accept this reasoning if `typeset path` > produced the same output as `typeset -m path` but it doesn't. Well, the other reason is that "typeset -m" pre-dates "typeset -p" and had existing expected behavior. > I don't know. I said it should be (b) because it would be correct by > design while (q) could only be correct by coincidence. Fiddling with this and some patterns also brought up another question: % describe-params 0 scalar-special 0=describe-params Would it be better to use POSIX_ARGZERO to reveal the name of the shell itself? There's no way from inside a function to grab $0 from the caller unless the caller itself asserts NO_FUNCTION_ARGZERO. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 20:03 ` Bart Schaefer @ 2023-01-22 21:56 ` Bart Schaefer 2023-01-22 22:02 ` Roman Perepelitsa 2023-01-22 23:03 ` Ray Andrews 0 siblings, 2 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 21:56 UTC (permalink / raw) To: zsh-users On Sun, Jan 22, 2023 at 12:03 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > % describe-params 0 > scalar-special 0=describe-params > > Would it be better to use POSIX_ARGZERO to reveal the name of the > shell itself? There's no way from inside a function to grab $0 from > the caller unless the caller itself asserts NO_FUNCTION_ARGZERO. Similar silliness that it may not be possible to fix, so maybe the above isn't worth considering: % describe-params '(#i)arg*' \? integer-readonly-special '!'=0 integer-readonly-special '#'=10 array-readonly-special '*'=( '*' - '?' @ _ '$' 0 ARGC argv ) scalar-readonly-special -=569XZfims integer-readonly-special '?'=1 array-readonly-special @=( @ _ '$' 0 ARGC argv ) scalar-special _=_ integer-readonly-special '$'=394907 scalar-special 0=describe-params integer-readonly-special ARGC=2 array-special argv=( argv ) In case not obvious what I mean, $* and $@ and $argv should all have the same elements, and $# and $ARGC should be equal to one another and to the number of elements in the first three, but this can't be preserved while using ARGC and shift to walk the names. Also, $? is nonzero because of the "if" test, and $_ is _ because that's the last word of the command that prints the value of $_. It's like trying to examine quantum superposition. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 21:56 ` Bart Schaefer @ 2023-01-22 22:02 ` Roman Perepelitsa 2023-01-22 22:27 ` Bart Schaefer 2023-01-22 23:03 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-22 22:02 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On Sun, Jan 22, 2023 at 10:57 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sun, Jan 22, 2023 at 12:03 PM Bart Schaefer > <schaefer@brasslantern.com> wrote: > > > > % describe-params 0 > > scalar-special 0=describe-params > > > > Would it be better to use POSIX_ARGZERO to reveal the name of the > > shell itself? There's no way from inside a function to grab $0 from > > the caller unless the caller itself asserts NO_FUNCTION_ARGZERO. > > Similar silliness that it may not be possible to fix, so maybe the > above isn't worth considering: > > % describe-params '(#i)arg*' \? > integer-readonly-special '!'=0 > integer-readonly-special '#'=10 > array-readonly-special '*'=( '*' - '?' @ _ '$' 0 ARGC argv ) > scalar-readonly-special -=569XZfims > integer-readonly-special '?'=1 > array-readonly-special @=( @ _ '$' 0 ARGC argv ) > scalar-special _=_ > integer-readonly-special '$'=394907 > scalar-special 0=describe-params > integer-readonly-special ARGC=2 > array-special argv=( argv ) > > In case not obvious what I mean, $* and $@ and $argv should all have > the same elements, and $# and $ARGC should be equal to one another and > to the number of elements in the first three, but this can't be > preserved while using ARGC and shift to walk the names. Also, $? is > nonzero because of the "if" test, and $_ is _ because that's the last > word of the command that prints the value of $_. It's like trying to > examine quantum superposition. I think it would be better for this function to pretend that those function-scoped parameters don't exist. If it were a builtin, it could describe parameters such as `ARGC` or `1` in a way that makes sense, but here the caller can only get confused if any answer is returned for them at all. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 22:02 ` Roman Perepelitsa @ 2023-01-22 22:27 ` Bart Schaefer 0 siblings, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 22:27 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: zsh-users On Sun, Jan 22, 2023 at 2:03 PM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > I think it would be better for this function to pretend that those > function-scoped parameters don't exist. I'm not happy about that because there's no way to distinguish them without hard-coding a list of names, which (unlikely as this might be) is not future-proof. If they were tagged -local in $parameters that would make more sense (but that'd mean adding a bunch of extra cases to zsh/parameter, it just moves the problem). And $? $_ $- aren't really function-scoped anyway. > If it were a builtin, it could > describe parameters such as `ARGC` or `1` in a way that makes sense Don't have to worry about positionals, they're not in $parameters to begin with. > but here the caller can only get confused if any answer is returned > for them at all. There's no reason not to return the ${(t)...} info. I'm tempted to just decide that if that includes "special" then any reported value is caller-beware. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 21:56 ` Bart Schaefer 2023-01-22 22:02 ` Roman Perepelitsa @ 2023-01-22 23:03 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-22 23:03 UTC (permalink / raw) To: zsh-users On 2023-01-22 13:56, Bart Schaefer wrote: > It's like trying to > examine quantum superposition. > Obviously you guys decide these things, but from here it is ... well, how to say it ... I"d never dream that DP would be reporting the positional params. What you've done is pretty fine, that stuff that you call 'silliness' looks like exactly that. Leave '$*' out of it. No point in answering a question that nobody is ever going to ask. Dunno, maybe someone, somewhere wants 'DP #' but I sure don't, I'd find some way of filtering stuff like that out. But I shouldn't say anything. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:56 ` Roman Perepelitsa 2023-01-22 20:03 ` Bart Schaefer @ 2023-01-22 20:12 ` Ray Andrews 2023-01-22 21:11 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-22 20:12 UTC (permalink / raw) To: Roman Perepelitsa, Bart Schaefer; +Cc: zsh-users On 2023-01-22 11:56, Roman Perepelitsa wrote: > It's still weird. I would accept this reasoning if `typeset path` > produced the same output as `typeset -m path` but it doesn't. > Something feels off. > typeset basically sux. I know my opinion is unwashed, but typeset leads me astray in every way. What you and Bart are writing just now is what 'typeset -p' should basically be doing. This 'display' via re-creation' -- which gives us those useless 'typeset -g ...' outputs within a function -- And the m and p switches don't play well together. Nope, it's hard to love typeset. Dunno, if I ask you your middle name, should the answer be to re-create your birth certificate? Just tell me. typeset -p is a very busted way of getting information. OK, it's not *meant* for getting information but, prior to describe-param it's where you had to go. Finally we have a real solution! ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 20:12 ` Ray Andrews @ 2023-01-22 21:11 ` Bart Schaefer 2023-01-22 22:44 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-22 21:11 UTC (permalink / raw) To: Ray Andrews; +Cc: Roman Perepelitsa, zsh-users On Sun, Jan 22, 2023 at 12:12 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > typeset -p is a very busted way of getting information. OK, it's not > *meant* for getting information but, prior to describe-param it's where > you had to go. That's obviously not true, or it would not have been possible to write describe-params. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 21:11 ` Bart Schaefer @ 2023-01-22 22:44 ` Ray Andrews 2023-01-22 23:35 ` Lawrence Velázquez ` (2 more replies) 0 siblings, 3 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-22 22:44 UTC (permalink / raw) To: zsh-users On 2023-01-22 13:11, Bart Schaefer wrote: > That's obviously not true, or it would not have been possible to write > describe-params. Roman's version didn't reference typeset at all (tho yours does). Not that typeset might not be *part* of the solution, but by itself it is poor -- thus the value of DP. You and Roman have both pointed out that typeset -p is more a way of recreating variables than it is of displaying them with type and value. And if it is already adequate, why would DP even need to be written? But it isn't and it did. Pardon Sensei, but you and Roman have solved a problem while at the same time you're claiming there was/is no problem to solve. Nope, DP is this dolphin's idea of a well written utility -- focused, simple, understandable, informative, complete, helpful and (I expect) with no ands, buts, ifs, maybes, exceptions, entanglements or gotchas of any kind. man page will be a couple of sentences. Software for mortals. Superb. Many thanks! IMHO DP should be standard equipment -- part of the release. (BTW, haven't run your version yet, waiting for Roman to sign off on it, but it will only get better.) Dunno, but if it was up to me it would be built in as: typeset -D man page: ... To display the type and the value of any parameter: typeset -D PARAM (wildcards accepted). That simple. Love it. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 22:44 ` Ray Andrews @ 2023-01-22 23:35 ` Lawrence Velázquez 2023-01-22 23:58 ` Ray Andrews 2023-01-23 1:11 ` Bart Schaefer 2023-01-23 10:37 ` Roman Perepelitsa 2 siblings, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-22 23:35 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023, at 5:44 PM, Ray Andrews wrote: > You and Roman have both pointed out that > typeset -p is more a way of recreating variables than it is of > displaying them with type and value. And if it is already adequate, why > would DP even need to be written? It was not written to "fix" typeset -p; it was written to satisfy your idiosyncratic preferences. > Dunno, but if it was up to me it would be built in as: typeset -D > > man page: > > ... To display the type and the value of any parameter: typeset -D PARAM > (wildcards accepted). This should absolutely not be done. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 23:35 ` Lawrence Velázquez @ 2023-01-22 23:58 ` Ray Andrews 2023-01-23 0:49 ` Lawrence Velázquez 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-22 23:58 UTC (permalink / raw) To: zsh-users On 2023-01-22 15:35, Lawrence Velázquez wrote: > > It was not written to "fix" typeset -p; it was written to satisfy > your idiosyncratic preferences. Neither Bart nor Roman would indulge me if there was no merit at all to what I want. Spare the rod and spoil the child. No ice-cream for breakfast. If I'm wrong then I hafta buck up and learn to do things the way they are done. But in this case I'm right -- what's idiosyncratic about wanting full information about a parameter along with it's value? What's ever wrong with complete information? > This should absolutely not be done. Why not? Honest question. DP can of course remain as a stand-alone function, but what would harm if it were bolted in to typeset? No axe to grind here, I have what I want, so I'm just wondering why other's shouldn't have it too. Mind, I suppose core code should not be altered trivially. So, sure, leave it as a function. Devs decision. But I hope the masses get decribe-params one way or another. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 23:58 ` Ray Andrews @ 2023-01-23 0:49 ` Lawrence Velázquez 2023-01-23 1:33 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-23 0:49 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023, at 6:58 PM, Ray Andrews wrote: > On 2023-01-22 15:35, Lawrence Velázquez wrote: >> >> It was not written to "fix" typeset -p; it was written to satisfy >> your idiosyncratic preferences. > Neither Bart nor Roman would indulge me if there was no merit at all to > what I want. They are performing a kindness by giving you a tool that suits your personal tastes. Their generosity does not carry any broader implications about how the shell should or should not behave. > But in this case I'm right Proclaiming your righteousness ad nauseam is not persuasive, and you should stop doing it. > what's idiosyncratic > about wanting full information about a parameter along with it's value? > What's ever wrong with complete information? The shell already provides multiple methods of obtaining all this information. The fact that you don't like any of them does not mean that it needs to sprout a new one. Again, there's nothing wrong with that. One of the purposes of a shell is to empower users to construct their own tools. This is as it should be. >> This should absolutely not be done. > > Why not? Honest question. DP can of course remain as a stand-alone > function, but what would harm if it were bolted in to typeset? Adding functionality always imposes a variety of costs, and typeset is already overly complex. The functionality you want to add is just a repackaged version of existing functionality, so it does not justify those costs. > I'm just wondering why other's shouldn't have it too. The zsh distribution is not the place to publish scripts written to scratch your itches. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 0:49 ` Lawrence Velázquez @ 2023-01-23 1:33 ` Bart Schaefer 2023-01-23 1:49 ` Lawrence Velázquez 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-23 1:33 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users On Sun, Jan 22, 2023 at 4:51 PM Lawrence Velázquez <larryv@zsh.org> wrote: > > They are performing a kindness by giving you a tool that suits your > personal tastes. Well, that, and once Roman had started on it, it became an interesting programming exercise. > The zsh distribution is not the place to publish scripts written > to scratch your itches. However, there are plenty of scripts in Functions/Misc that fit this description (e.g. ztodo, sticky-note) or in Functions/Example that are just interesting for tutorial purposes (zless, zpgrep). In fact we ought to see if some of them have become obsolete (promptnl). This might fit there somewhere just because "interesting exercise." ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 1:33 ` Bart Schaefer @ 2023-01-23 1:49 ` Lawrence Velázquez 0 siblings, 0 replies; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-23 1:49 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Sun, Jan 22, 2023, at 8:33 PM, Bart Schaefer wrote: > On Sun, Jan 22, 2023 at 4:51 PM Lawrence Velázquez <larryv@zsh.org> wrote: >> The zsh distribution is not the place to publish scripts written >> to scratch your itches. > > However, there are plenty of scripts in Functions/Misc that fit this > description (e.g. ztodo, sticky-note) or in Functions/Example that are > just interesting for tutorial purposes (zless, zpgrep). Ah! I had an notion that there was a "Contrib" directory, but when I didn't see one I assumed I'd gotten confused by another project. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 22:44 ` Ray Andrews 2023-01-22 23:35 ` Lawrence Velázquez @ 2023-01-23 1:11 ` Bart Schaefer 2023-01-23 1:56 ` Ray Andrews 2023-01-23 10:37 ` Roman Perepelitsa 2 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-23 1:11 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023 at 2:44 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-22 13:11, Bart Schaefer wrote: > > > That's obviously not true, or it would not have been possible to write > > describe-params. > > Roman's version didn't reference typeset at all (tho yours does). That's actually exactly my point: It is not true that you had to resort to "typeset" to get this information. Everything you wanted except the output formatting is available given the parameter name itself, you don't even need the zsh/parameter module. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 1:11 ` Bart Schaefer @ 2023-01-23 1:56 ` Ray Andrews 2023-01-23 2:59 ` Lawrence Velázquez 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-23 1:56 UTC (permalink / raw) To: zsh-users On 2023-01-22 17:11, Bart Schaefer wrote: > That's actually exactly my point: It is not true that you had to > resort to "typeset" to get this information. Everything you wanted > except the output formatting is available given the parameter name > itself, you don't even need the zsh/parameter module. > Whatever. However. I'm just happy to have something that works. Obviously the building blocks were there, I just didn't know how to find them. Everything *seemed* to suggest that typeset -p was where you went for that kind of information. I'm glad to learn otherwise. Seems I was driving nails with a crosscut saw. Now I have a hammer. It's that simple and thanks again. If I'd had DP ab ovo, this thread, and a few others like it, would never have been started cuz things would have been clear from the getgo. > However, there are plenty of scripts in Functions/Misc that fit this I don't understand Lawrence's perspective on this. Can one have too many tools? I suppose something could be so marginal that it's not worth it's weight but is DP really like that? I doubt I'm the only person who finds that kind of information useful. Lawrence spins it as some sort of fetish to want to see the type of a param and it's value at the same time. I don't see this as anything like a contest. The devs will make the right decision. But from the peanut gallery I myself will always vote for what's simple, informative, and clear. Those who like things that are convoluted, confusing, incomplete and obscure can have those things too. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 1:56 ` Ray Andrews @ 2023-01-23 2:59 ` Lawrence Velázquez 2023-01-23 3:47 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-23 2:59 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023, at 8:56 PM, Ray Andrews wrote: > On 2023-01-22 17:11, Bart Schaefer wrote: >> However, there are plenty of scripts in Functions/Misc that fit this > > I don't understand Lawrence's perspective on this. Can one have too > many tools? I would actually argue that the answer to your strawman question is "yes", but as I implied in another message, I had been unaware of (or had forgotten about) Functions/{Examples,Misc}. Since those directories already exist, I'd have no particular objection to shipping your toy in one of them, if so desired. > Lawrence spins it as some sort of fetish to want to see the type > of a param and it's value at the same time. What I actually said (as opposed to the lie you just told) is that I think it is inappropriate for the shell to natively duplicate functionality that already exists, merely to provide an alternate visual representation that you personally like better. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 2:59 ` Lawrence Velázquez @ 2023-01-23 3:47 ` Ray Andrews 0 siblings, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-23 3:47 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: zsh-users On 2023-01-22 18:59, Lawrence Velázquez wrote: > > I would actually argue that the answer to your strawman question > is "yes", Sure. Sometimes merely the disk space used by a useless function should recommend it be purged. I'll leave it to wiser people to make that decision in this case. I like it, but it's 'official' fate is not my decision. > > What I actually said (as opposed to the lie you just told) is that > I think it is inappropriate for the shell to natively duplicate > functionality that already exists, merely to provide an alternate > visual representation that you personally like better. The output given by DP is unique otherwise it wouldn't have been written. I'd rather say it harnesses exiting functionality in a useful way. Every line of computer software ever written is in some way a duplication of something that might be done by more primitive (using the term non-pejoratively I just mean by more basic) methods. Programmers assemble simple instructions into more complex collections of instructions to achieve efficiency. DP is an example. A dozen lines that give a very nice output IMHO. BTW I'm not righteous, I'm a greasy plebe. I'm usually wrong. This entire thread is a chain of mistakes on my part. Mistakes within mistakes. I've been with zsh almost 10 years and I still rate myself a C-. But I have a talent for clarity and I know it when I see it. Occasionally I'm right, and this is one of those times. But there's nothing to argue about, I'm not a dev and the decision is not mine. Your voice will carry far more weight than mine and that's as it should be. But I like it. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 22:44 ` Ray Andrews 2023-01-22 23:35 ` Lawrence Velázquez 2023-01-23 1:11 ` Bart Schaefer @ 2023-01-23 10:37 ` Roman Perepelitsa 2023-01-23 15:28 ` Ray Andrews 2023-01-23 16:26 ` Bart Schaefer 2 siblings, 2 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-23 10:37 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 22, 2023 at 11:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-22 13:11, Bart Schaefer wrote: > > > That's obviously not true, or it would not have been possible to write > > describe-params. > > [...] > > (BTW, haven't run your version yet, waiting for Roman to sign off on it, > but it will only get better.) Me to sign off on Bart's code? Ha-ha :) I started using zsh in 2019 while Bart has been a contributor since the previous century. When Bart and I disagree, it would be wise to go with his opinion by default. By the way, one thing bothers me about tied parameters. Is there really no way (other than parsing the output of `typeset -p`) to retrieve the name of the tied counterpart? Here's what I mean: % typeset -T FOO foo % tied-counterpart FOO foo % tied-counterpart foo FOO How do you implement `tied-counterpart` that behaves as in the (imaginary) transcript above? Now that I think of it, there are a few more parameter properties that aren't exposed through anything other than `typeset -p`. % typeset -i8 -R10 foo % typeset -p foo typeset -i8 -R10 foo=0 % print -r -- ${(t)foo} integer-right_blanks The numbers 8 and 10 cannot be retried from anywhere, right? There is also at least one case where `typeset -p` is lossy. % typeset -F2 foo % typeset -p foo typeset -F foo=0.00 Note that the output is missing "2". Is this intended? Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 10:37 ` Roman Perepelitsa @ 2023-01-23 15:28 ` Ray Andrews 2023-01-23 15:40 ` zeurkous 2023-01-23 16:26 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-23 15:28 UTC (permalink / raw) To: zsh-users On 2023-01-23 02:37, Roman Perepelitsa wrote: > Me to sign off on Bart's code? Ha-ha :) I started using zsh in 2019 > while Bart has been a contributor since the previous century. When > Bart and I disagree, it would be wise to go with his opinion by > default. NO! 2019? And you've developed your skills this far? In 4 years? Nuts, I have more 'seniority' that you? That really does make me feel like a moron ;-) > Now that I think of it, there are a few more parameter properties that > aren't exposed through anything other than `typeset -p`. That's the sort of thing that steams me. Just for the principal of it. There are always these leaks and exceptions and maybes. I suppose that such a big project must develop imperfections of that sort as it grows, still one could wish for one-stop shopping -- one command that shows you *every* property. Dunno, surely this data is all stored in one place? Anyway, in practice DP is 99% of the way there. ^ permalink raw reply [flat|nested] 119+ messages in thread
* RE: Re: path PATH 2023-01-23 15:28 ` Ray Andrews @ 2023-01-23 15:40 ` zeurkous 2023-01-23 16:02 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: zeurkous @ 2023-01-23 15:40 UTC (permalink / raw) To: Ray Andrews, zsh-users [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 527 bytes --] On Mon, 23 Jan 2023 07:28:11 -0800, Ray Andrews <rayandrews@eastlink.ca> wrote: > That's the sort of thing that steams me. Just for the principal of it. principle* But yeah... > There are always these leaks and exceptions and maybes. I suppose that > such a big project must develop imperfections of that sort as it grows, ...you got it. (In fact, me'd even argue that UNIX could use a "lessons-learned" rewrite altogether. But that's once again beyond our purview.) --zeurkous. -- Friggin' Machines! ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 15:40 ` zeurkous @ 2023-01-23 16:02 ` Ray Andrews 2023-01-23 16:25 ` zeurkous 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-23 16:02 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 480 bytes --] On 2023-01-23 07:40, zeurkous@blaatscaahp.org wrote: > (In fact, me'd even argue that UNIX could use a "lessons-learned" > rewrite altogether. But that's once again beyond our purview.) > > --zeurkous. You've read 'the cathedral and the bazaar' of course. If I were a gazilionaire I'd pay some hotshots to rewrite the whole thing from the bedrock up -- build a cathedral. Same with zsh -- pay the devs to really get things right. Think Haussmann redoing Paris. [-- Attachment #2: Type: text/html, Size: 1135 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* RE: Re: path PATH 2023-01-23 16:02 ` Ray Andrews @ 2023-01-23 16:25 ` zeurkous 0 siblings, 0 replies; 119+ messages in thread From: zeurkous @ 2023-01-23 16:25 UTC (permalink / raw) To: Ray Andrews, zsh-users [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2351 bytes --] On Mon, 23 Jan 2023 08:02:10 -0800, Ray Andrews <rayandrews@eastlink.ca> wrote: > This is a multi-part message in MIME format. > --------------s8tUpr0M54E8X0ltYkQwh4uy > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit Sigh. > On 2023-01-23 07:40, zeurkous@blaatscaahp.org wrote: >> (In fact, me'd even argue that UNIX could use a "lessons-learned" >> rewrite altogether. But that's once again beyond our purview.) >> >> --zeurkous. > You've read 'the cathedral and the bazaar' of course. Yes, *many* moons ago. It is a remarkable work of apologism (a not unknown feature of many of esr's writings), and as such rightfully did not influence me opinion all that much. --zeurkous. > If I were a > gazilionaire I'd pay some hotshots to rewrite the whole thing from the > bedrock up -- build a cathedral. Same with zsh -- pay the devs to > really get things right. Think Haussmann redoing Paris. > --------------s8tUpr0M54E8X0ltYkQwh4uy > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > <html> > <head> > <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> > </head> > <body> > <p><br> > </p> > <div class="moz-cite-prefix">On 2023-01-23 07:40, > <a class="moz-txt-link-abbreviated" href="mailto:zeurkous@blaatscaahp.org">zeurkous@blaatscaahp.org</a> wrote:<br> > </div> > <blockquote type="cite" > cite="mid:thinkcrap!zeurkous!1674488400.13351@uucp">(In fact, me'd > even argue that UNIX could use a "lessons-learned" > <pre class="moz-quote-pre" wrap="">rewrite altogether. But that's once again beyond our purview.) > > --zeurkous. > </pre> > </blockquote> > You've read 'the cathedral and the bazaar' of course. If I were a > gazilionaire I'd pay some hotshots to rewrite the whole thing from > the bedrock up -- build a cathedral. Same with zsh -- pay the devs > to really get things right. Think <span > class="js-about-item-abstr">Haussmann redoing Paris. <br> > </span> > <blockquote type="cite" > cite="mid:thinkcrap!zeurkous!1674488400.13351@uucp"> > <pre class="moz-quote-pre" wrap=""> > </pre> > </blockquote> > </body> > </html> > > --------------s8tUpr0M54E8X0ltYkQwh4uy-- > -- Friggin' Machines! ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-23 10:37 ` Roman Perepelitsa 2023-01-23 15:28 ` Ray Andrews @ 2023-01-23 16:26 ` Bart Schaefer 1 sibling, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-23 16:26 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users On Mon, Jan 23, 2023 at 2:37 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > Me to sign off on Bart's code? Ha-ha :) I started using zsh in 2019 > while Bart has been a contributor since the previous century. When > Bart and I disagree, it would be wise to go with his opinion by > default. On the other hand, that means there's a lot of stuff I've forgotten that's fresh in your memory, and things I might take for granted that you dig into. > By the way, one thing bothers me about tied parameters. Is there > really no way (other than parsing the output of `typeset -p`) to > retrieve the name of the tied counterpart? % typeset +m path array tied PATH path This DOES represent something that you can't get without "typeset", and it's not exceptionally well documented: Except when assignments are made with NAME=VALUE, using +m forces the matching parameters and their attributes to be printed, even inside a function. Note that -m is ignored if no patterns are given, so 'typeset -m' displays attributes but 'typeset -a +m' does not. Ordinary scalar string parameters have no attributes, so for those +m prints only the names. > Now that I think of it, there are a few more parameter properties that > aren't exposed through anything other than `typeset -p`. % typeset -i8 -R10 foo % typeset +m foo integer 8 right justified 10 foo > % typeset -F2 foo > % typeset -p foo > typeset -F foo=0.00 > > Note that the output is missing "2". Is this intended? Almost certainly not. % typeset +m foo float foo ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:51 ` Bart Schaefer 2023-01-22 19:56 ` Roman Perepelitsa @ 2023-01-24 20:00 ` Ray Andrews 2023-01-24 20:42 ` Bart Schaefer 2023-01-24 23:28 ` Ray Andrews 2 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-24 20:00 UTC (permalink / raw) To: zsh-users Bart: I'm chewing on your code, I understand everything but this: > set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} It can be omitted seemingly without consequence if there's only one arg, but it's needed if multiple. Would you be so patient as to explain what's going on there? It's too thick for me. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-24 20:00 ` Ray Andrews @ 2023-01-24 20:42 ` Bart Schaefer 2023-01-24 20:50 ` Bart Schaefer 2023-01-24 20:54 ` Ray Andrews 0 siblings, 2 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-24 20:42 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Tue, Jan 24, 2023 at 12:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} $parameters is an associative array, so you can subscript it with [ ] to get the elements. The keys of this array are parameter names. ${(.|.)var} means to join an array with vertical bars; here the var is @ for the positional parameters. ${~something} means the value of something can be treated as a pattern, so the |-joined positional parameters form a pattern. (I) in an associative array subscript means to return every element whose key matches a pattern, so instead of getting just one element it is an array of elements. (k) prefixing an associative array reference means to return the keys (normally the values would be returned), so now we have an array of parameter names. (o) prefixing any array reference means to sort ("order") the results, so we get the matching parameter names in alphabetical order. "set --" replaces the original positional parameters with this array of parameter names. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-24 20:42 ` Bart Schaefer @ 2023-01-24 20:50 ` Bart Schaefer 2023-01-24 20:54 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-24 20:50 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Tue, Jan 24, 2023 at 12:42 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > ${(.|.)var} means to join an array with vertical bars (j.|.) that is. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-24 20:42 ` Bart Schaefer 2023-01-24 20:50 ` Bart Schaefer @ 2023-01-24 20:54 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-24 20:54 UTC (permalink / raw) To: zsh-users On 2023-01-24 12:42, Bart Schaefer wrote: > >>> set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} > $parameters is an associative array, so you can subscript it with [ ] Thanks. Would have taken me a week to figure it all out. One simply can't search for '(j.|.)' and home in on the answer, you hafta know head of time what kind of animal it is. Inside out, vs. outside in. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:51 ` Bart Schaefer 2023-01-22 19:56 ` Roman Perepelitsa 2023-01-24 20:00 ` Ray Andrews @ 2023-01-24 23:28 ` Ray Andrews 2023-01-24 23:42 ` Bart Schaefer 2 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-24 23:28 UTC (permalink / raw) To: zsh-users On 2023-01-22 11:51, Bart Schaefer wrote: if [[ -${parameters[$1]}- = *-hideval-* ]] The things we come across poking our noses into the workings: 'hideval' surely is clearly helpful when some params have values that no moral should ever look at. But maybe half of the hideval params are also marked 'hide', which ... well, what does that add? Manual has nothing to say about it. BTW I'd often wondered why so many params had 'no value'. They do! Just hidden. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-24 23:28 ` Ray Andrews @ 2023-01-24 23:42 ` Bart Schaefer 2023-01-25 0:14 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-24 23:42 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Tue, Jan 24, 2023 at 3:28 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > 'hideval' surely is clearly helpful when some params have values that no > moral should ever look at. But maybe half of the hideval params are also > marked 'hide', which ... well, what does that add? Manual has nothing > to say about it. This was actually mentioned earlier in this same thread. On Sun, Jan 22, 2023 at 11:20 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sun, Jan 22, 2023 at 4:30 AM Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > > > [[ -$2- == *-hide-* ]] && return 1 > > I'm curious why you chose to do this? The "hide" attribute means that > a local does not preserve semantics of a special global, not that it's > name is invisible. The manual DOES explain this. Search "man zshall" for "hide", it's about the 5th occurrence. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-24 23:42 ` Bart Schaefer @ 2023-01-25 0:14 ` Ray Andrews 2023-01-25 16:38 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-25 0:14 UTC (permalink / raw) To: zsh-users On 2023-01-24 15:42, Bart Schaefer wrote: > This was actually mentioned earlier in this same thread. To be honest, when you guys have an issue in hand, I just wait for you to be finished before I try figure out what's going on. It's too hard to follow in real time. Sorry for the duplication tho. The manual DOES explain this. Search "man zshall" for "hide", it's > about the 5th occurrence. > To be honest again, I searched for 'hideval' and scanned up and down from there. 'hide' is referred to but not explained. And since 'hideval' only occurs the one time (that I can see) and isn't explained I figured that 'hide' would be no different. And that 'hide' out of context would probably show up a hundred times. Pardon, that's just lazy on my part. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 0:14 ` Ray Andrews @ 2023-01-25 16:38 ` Ray Andrews 2023-01-25 16:43 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-25 16:38 UTC (permalink / raw) To: zsh-users For purposes of cleaning up dead variables I sometimes want to list any unset params. Before recent education I thought: $ set | grep -E "bg$" bg ... meant that bg was unset and now I know it's hidden. (Nice if that was made more explicit.) So what would be a complete list of unset params? This is close: $ typeset -mp "*" | grep -e "=( )$" -e "=''$" -e "=0$" typeset ZLE_LINE_ABORTED='' typeset -aT CDPATH cdpath=( ) typeset -T CDPATH cdpath=( ) typeset -aT MAILPATH mailpath=( ) typeset -aT MANPATH manpath=( ) typeset -T MANPATH manpath=( ) typeset -a compprefuncs=( ) typeset -aT WATCH watch=( ) typeset cc=0 typeset -a zzz=( ) typeset OPTARG='' typeset -i10 UID=0 typeset KEYBOARD_HACK='' typeset -i10 GID=0 typeset zz='' typeset -aT FIGNORE fignore=( ) typeset -T WATCH watch=( ) typeset MATCH_FOUND='' typeset -T MAILPATH mailpath=( ) typeset -i zzzz=0 typeset -a comppostfuncs=( ) typeset -T FIGNORE fignore=( ) typeset _execute_input='' typeset _execute_history='' typeset -aT PSVAR psvar=( ) typeset _execute_output='' typeset -a z=( ) typeset -a argv=( ) typeset _execute_linecount='' typeset varis_switches='' typeset -T PSVAR psvar=( ) typeset -i10 EUID=0 typeset -i10 EGID=0 ... but probably there's others. BTW, I very much doubt anything can be done about it, but I trust there's no way to distinguish between an unset integer and one explicitly set to zero? Not that much will ever hinge on it. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 16:38 ` Ray Andrews @ 2023-01-25 16:43 ` Roman Perepelitsa 2023-01-25 16:56 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-25 16:43 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Jan 25, 2023 at 5:38 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > So what would be a complete list of unset > params? This is close: > > $ typeset -mp "*" | grep -e "=( )$" -e "=''$" -e "=0$" > > typeset ZLE_LINE_ABORTED='' > [...] > typeset -i10 EGID=0 All of these parameters are set. Here's how an unset parameter looks like: % typeset -p blah typeset: no such variable: blah % [[ -v blah ]] || print unset unset % (( ${+blah} )) || print unset unset You can print the list of all unset parameters but the output will be infinite. To do that, you start by enumerating all one-character names and checking them against `[[ -v ]]`. Proceed with two-character names, etc. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 16:43 ` Roman Perepelitsa @ 2023-01-25 16:56 ` Ray Andrews 2023-01-25 17:02 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-25 16:56 UTC (permalink / raw) To: zsh-users On 2023-01-25 08:43, Roman Perepelitsa wrote: > > All of these parameters are set. Here's how an unset parameter looks like: Maybe I'm using the wrong word. How do we say set to nothing? 5 /aWorking/Zsh/Source/Wk 0 $ zzz=; typeset -m zzz zzz='' 5 /aWorking/Zsh/Source/Wk 0 $ integer zzz=; typeset -m zzz zzz=0 ... param exists, but has no value (excepting the default zero for integers). ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 16:56 ` Ray Andrews @ 2023-01-25 17:02 ` Roman Perepelitsa 2023-01-25 17:34 ` Ray Andrews 2023-01-25 22:18 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-25 17:02 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Jan 25, 2023 at 5:58 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > On 2023-01-25 08:43, Roman Perepelitsa wrote: > > > > All of these parameters are set. Here's how an unset parameter looks like: > > Maybe I'm using the wrong word. How do we say set to nothing? > > 5 /aWorking/Zsh/Source/Wk 0 $ zzz=; typeset -m zzz > zzz='' > > 5 /aWorking/Zsh/Source/Wk 0 $ integer zzz=; typeset -m zzz > zzz=0 > > ... param exists, but has no value (excepting the default zero for > integers). These parameters have values. The following three lines are equivalent (assuming that foo isn't set beforehand): typeset foo typeset foo= typeset foo="" These are also equivalent: typeset -i foo typeset -i foo= typeset -i foo="" typeset -i foo=0 Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 17:02 ` Roman Perepelitsa @ 2023-01-25 17:34 ` Ray Andrews 2023-01-25 17:37 ` Roman Perepelitsa 2023-01-25 22:18 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-25 17:34 UTC (permalink / raw) To: zsh-users On 2023-01-25 09:02, Roman Perepelitsa wrote: > These parameters have values. The following three lines are equivalent 5 /aWorking/Zsh/Source/Wk 1 $ zzz= 5 /aWorking/Zsh/Source/Wk 1 $ echo "'$zzz'" '' What is the value of zzz? How can it be called anything but nothing? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 17:34 ` Ray Andrews @ 2023-01-25 17:37 ` Roman Perepelitsa 2023-01-25 18:26 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-25 17:37 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Jan 25, 2023 at 6:34 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > On 2023-01-25 09:02, Roman Perepelitsa wrote: > > These parameters have values. The following three lines are equivalent > > 5 /aWorking/Zsh/Source/Wk 1 $ zzz= > > 5 /aWorking/Zsh/Source/Wk 1 $ echo "'$zzz'" > '' > > What is the value of zzz? How can it be called anything but nothing? This value is usually called "empty" or "null". The parameter is not unset though. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 17:37 ` Roman Perepelitsa @ 2023-01-25 18:26 ` Ray Andrews 2023-01-25 18:34 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-25 18:26 UTC (permalink / raw) To: zsh-users On 2023-01-25 09:37, Roman Perepelitsa wrote: > > This value is usually called "empty" or "null". The parameter is not > unset though. > Ah. Ok, that's the correct terminology. Yeah. 'unset' implies the var itself does not exist vs. having a null value. So how can I check for all null parameters? As previous, I think I'm pretty close. I've noticed that over time editing functions, they can accumulate dead variables and the above is an effort to catch them. Man, I thought this little exploration of the params was going to be simple ... not so! Come to that, how many fundamental types are there? I mean an exported array is still, fundamentally an array. A tied array is still an array. But an associative array is a different sort of animal, so I have: scalar, integer, array, A array, .... what else? There'll only be so many displays for null params and when I know them all I can catch them all. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 18:26 ` Ray Andrews @ 2023-01-25 18:34 ` Roman Perepelitsa 2023-01-25 19:00 ` Ray Andrews 2023-01-26 2:13 ` Ray Andrews 0 siblings, 2 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-25 18:34 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Jan 25, 2023 at 7:26 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-25 09:37, Roman Perepelitsa wrote: > > > > This value is usually called "empty" or "null". The parameter is not > > unset though. > > > Ah. Ok, that's the correct terminology. Yeah. 'unset' implies the var > itself does not exist vs. having a null value. So how can I check for > all null parameters? You can use [[ -z ]] for that. for name in ${(k)parameters}; do if [[ -z ${(P)name} ]]; then print -r -- $name fi done > Come to that, how many fundamental types are there? There is ‘scalar’, ‘array’, ‘integer’, ‘float’ or ‘association’. I copied it straight from the docs. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 18:34 ` Roman Perepelitsa @ 2023-01-25 19:00 ` Ray Andrews 2023-01-26 2:13 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-25 19:00 UTC (permalink / raw) To: zsh-users On 2023-01-25 10:34, Roman Perepelitsa wrote: > You can use [[ -z ]] for that. > for name in ${(k)parameters}; do > if [[ -z ${(P)name} ]]; then > print -r -- $name > fi > done Excellent, it beats grepping for various endings. > There is ‘scalar’, ‘array’, ‘integer’, ‘float’ or ‘association’. I > copied it straight from the docs. Section? I'd like to read up on that. As usual the biggest problem is knowing where to look for stuff. Thanks Roman. ... Stop being quite so lazy Ray .... found it :-) ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 18:34 ` Roman Perepelitsa 2023-01-25 19:00 ` Ray Andrews @ 2023-01-26 2:13 ` Ray Andrews 2023-01-26 2:37 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-26 2:13 UTC (permalink / raw) To: zsh-users On 2023-01-25 10:34, Roman Perepelitsa wrote: > You can use [[ -z ]] for that. > for name in ${(k)parameters}; do > if [[ -z ${(P)name} ]]; then > print -r -- $name > fi > done One small problem with that. It seems to print all the values alright, but ends with: "failed to find end of command substitution" ... you'd have tested it of course, so why that msg here? Virgin shell reports the same msg. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 2:13 ` Ray Andrews @ 2023-01-26 2:37 ` Bart Schaefer 2023-01-26 4:27 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-26 2:37 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Jan 25, 2023 at 6:13 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > "failed to find end of command substitution" You've copy-pasted wrong somewhere and have $( where you should have ${ ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 2:37 ` Bart Schaefer @ 2023-01-26 4:27 ` Ray Andrews 2023-01-26 20:26 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-26 4:27 UTC (permalink / raw) To: zsh-users On 2023-01-25 18:37, Bart Schaefer wrote: > On Wed, Jan 25, 2023 at 6:13 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> "failed to find end of command substitution" > You've copy-pasted wrong somewhere and have $( where you should have ${ > > for name in ${(k)parameters}; do > if [[ -z ${(P)name} ]]; then > print -r -- $name > fi > done > That's what I'm running. I suspected the same thing but .... ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 4:27 ` Ray Andrews @ 2023-01-26 20:26 ` Ray Andrews 2023-01-26 20:29 ` Roman Perepelitsa 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-26 20:26 UTC (permalink / raw) To: zsh-users On 2023-01-25 20:27, Ray Andrews wrote: > You've copy-pasted wrong somewhere and have $( where you should have ${ >> > >> for name in ${(k)parameters}; do >> if [[ -z ${(P)name} ]]; then >> print -r -- $name >> fi >> done >> > That's what I'm running. I suspected the same thing but .... Strange, I fired up the computer today, run exactly the same command and no message. Fool around for a while and it comes back. Restart shell ... no change. Restart terminal and it goes away. I'll try to figure out exactly what triggers it. Must be some environment corruption. Bart: In your (temporarily name-shortened) describe-params, I'm trying to capture the output to a variable for further processing: #describe-params () dp () { emulate -L zsh -o extendedglob ddescribeparams=() local line= set -- ${(ok)parameters[(I)${~${(j.|.)@}}]} while ((ARGC)) do # print -rn -- "${parameters[$1]} " line+="${parameters[$1]} " if [[ -${parameters[$1]}- = *-hideval-* ]] then # If param is hidden, typeset won't show anything so use this: # print -r -- ${(q-)1} line+="${(q-)1}" else # typeset -m -- ${(b)1} line+=$( typeset -m -- ${(b)1} ) fi ddescribeparams+="$line" line= shift done print -l -- $ddescribeparams } ... line+=$( typeset -m -- ${(b)1} ) ... isn't working with eg: $ typeset -m yellow yellow=$'\C-[[33;1m' ... the predictable thing is happening and the color code gets applied and my terminal turns yellow. How can I capture the value of yellow without that problem? I've run into this before but I can't remember the solution. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 20:26 ` Ray Andrews @ 2023-01-26 20:29 ` Roman Perepelitsa 2023-01-26 20:59 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-26 20:29 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Jan 26, 2023 at 9:27 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > print -l -- $ddescribeparams Add -r. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 20:29 ` Roman Perepelitsa @ 2023-01-26 20:59 ` Ray Andrews 2023-01-26 21:17 ` Bart Schaefer 2023-01-26 21:41 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-26 20:59 UTC (permalink / raw) To: zsh-users On 2023-01-26 12:29, Roman Perepelitsa wrote: > On Thu, Jan 26, 2023 at 9:27 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> print -l -- $ddescribeparams > Add -r. > > Roman. > Ah! Damn, I know that. I was fooling around with quotes and single quotes and protected quotes and '${(Q-continuum) }| ' ... barking up every tree but the right one. And I know better! Tx. BTW, reading up on the types, the doc seems rather incomplete. I identify: scalar, array, association, integer, float, float-double, and modifiers: hideval, hide, readonly, special, tied, unique, export(ed), undefined and local ... but the doc only mentions some of them in passing, there's only explicit explanation of a few of them -- that I can find. eg 'hideval' is only mentioned twice and then only in passing. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 20:59 ` Ray Andrews @ 2023-01-26 21:17 ` Bart Schaefer 2023-01-26 21:41 ` Bart Schaefer 1 sibling, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-26 21:17 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Jan 26, 2023 at 1:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > => BTW, reading up on the types, the doc seems rather incomplete. I > identify: scalar, array, association, integer, float, float-double, and "double" is effectively just a modifier also, the basic type is still float. > modifiers: hideval, hide, readonly, special, tied, unique, export(ed), > undefined and local ... but the doc only mentions some of them in > passing, there's only explicit explanation of a few of them -- that I > can find. That's because those words were chosen to have an obvious mapping onto the switches accepted by the typeset command, and it didn't seem necessary to explain the switches twice. double = -E hideval = -H hide = -h readonly = -r etc. The only one that doesn't have such a direct mapping is "special", which just means it's known internally to zsh so referencing or changing its value might have side-effects. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 20:59 ` Ray Andrews 2023-01-26 21:17 ` Bart Schaefer @ 2023-01-26 21:41 ` Bart Schaefer 2023-01-26 21:44 ` Bart Schaefer 2023-01-26 22:18 ` Ray Andrews 1 sibling, 2 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-26 21:41 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Jan 26, 2023 at 1:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > undefined and local ... but the doc only mentions some of them Where did you find "undefined" that led you to think it's a parameter modifier? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 21:41 ` Bart Schaefer @ 2023-01-26 21:44 ` Bart Schaefer 2023-01-26 22:36 ` Ray Andrews 2023-01-26 22:18 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-26 21:44 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Jan 26, 2023 at 1:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > Where did you find "undefined" that led you to think it's a parameter modifier? Oh ... parameters autoloadable from a module that haven't yet been loaded. That's a bit of an odd case. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 21:44 ` Bart Schaefer @ 2023-01-26 22:36 ` Ray Andrews 2023-01-26 22:43 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-26 22:36 UTC (permalink / raw) To: zsh-users On 2023-01-26 13:44, Bart Schaefer wrote: > On Thu, Jan 26, 2023 at 1:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote: >> Where did you find "undefined" that led you to think it's a parameter modifier? > Oh ... parameters autoloadable from a module that haven't yet been > loaded. That's a bit of an odd case. With no one place where all these modifiers are discussed, it's sorta like an Easter egg hunt -- one collects modifiers as one finds new examples here and there. I probably still haven't found all of them. I admit that it becomes a bit of an obsession more than a practical matter but when I decide I want a list of *all* of the types/modifiers, I want a list of *all* of them. Dunno, it's the stamp-collector's mentality I suppose. And to think that I thought that typeset -p gave us the complete story. BTW, trivial bit of hair-splitting, but the doc says that, eg, integers *are* scalars -- uses scalar like a category -- I thought a var was a scalar *or* an integer. That is, scalar is a type, not a family of types. I think that's what we do in practice anyway so it's a bit unimportant. > ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 22:36 ` Ray Andrews @ 2023-01-26 22:43 ` Bart Schaefer 2023-01-27 0:19 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-26 22:43 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Jan 26, 2023 at 2:36 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > BTW, trivial bit of hair-splitting, but the doc says that, eg, integers > *are* scalars -- uses scalar like a category This is true. A scalar is anything that substitutes only a single value, as distinct from an array that substitutes multiple values. scalar (string, the default and not given a distinct name) integer float (including double-precision) array (of string, the default) associative array (aka "association" or "hash" or "hash table") Any single element of an array is also a scalar, at least at this time -- we don't support compound data types. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 22:43 ` Bart Schaefer @ 2023-01-27 0:19 ` Ray Andrews 2023-01-27 3:36 ` Ray Andrews 2023-01-27 17:51 ` Ray Andrews 0 siblings, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-27 0:19 UTC (permalink / raw) To: zsh-users On 2023-01-26 14:43, Bart Schaefer wrote: > > This is true. A scalar is anything that substitutes only a single > value, as distinct from an array that substitutes multiple values. Now that you mention it, that's logical. Mind, then we need a word for a 'plain' scalar, vs. say in integer. Yeah, I see the point. Mind, in practice context pretty much makes the meaning clear. OTOH, for a C coder the ambiguity of shell data types is disturbing, but I guess that's the way it always has been and always will be. I still find myself 'declaring' all my variables even if I don't have to. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-27 0:19 ` Ray Andrews @ 2023-01-27 3:36 ` Ray Andrews 2023-01-27 17:51 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-27 3:36 UTC (permalink / raw) To: zsh-users 4 /aWorking/Zsh/Source/Wk 0 $ typeset -F zzz 4 /aWorking/Zsh/Source/Wk 0 $ typeset -E zzzz 4 /aWorking/Zsh/Source/Wk 0 $ dp "zzz*" float zzz = 0.0000000000 float zzzz = 0.000000000e+00 ... wouldn't it make sense to identify the double float as 'double'? Or something to distinguish it from the other? These long-form type descriptions would seem to be crisply unambiguous apart from that exception. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-27 0:19 ` Ray Andrews 2023-01-27 3:36 ` Ray Andrews @ 2023-01-27 17:51 ` Ray Andrews 2023-01-27 20:45 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-27 17:51 UTC (permalink / raw) To: zsh-users Finally have what I thought I had: the full story on PATH path: 3 /aWorking/Zsh/Source/Wk 0 $ . test1; vv path Stes PATH = .:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin Ats path = ( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... Here's the legend, from the accompanying help: TYPES: These are condensed from the detailed information you can see like this: '$ print ${(t)path}'. Basic types are capitalized, modifiers are in lower case: S: An ordinary scalar (not an integer or float). I: An integer. F: A float ('typeset -F:' decimal display or 'typeset -E': scientific display). A: A normal array. H: An associative array or 'association' or 'hash' (always 'hideval' as well). e: The variable has been exported to the environment and is thus persistent within that terminal -- it will be inherited by subshells. l: The variable is local to the running function. t: The variable is 'tied' to another variable (see docs: 'typeset -T'). s: The variable is special to the shell. r: The variable is read-only (this often goes with 'special'). v: 'hideval': the value of the variable will be hidden -- there are things we really don't want to see, like lists of color codes. This tends to go with 'special' and 'hide'. h: Hide: Used with 'special' (see docs: 'typeset -h'). u: Unique: ??(no documentation found). ?: Undefined: For autoloaded parameters not yet loaded (whatever that means). " ... edits and corrections most welcome. Have I missed any? 3 /aWorking/Zsh/Source/Wk 0 $ vv "z*" S Z = /aWorking/Zsh A zle_bracketed_paste = ( $'\C-[[?2004h' $'\C-[[?2004l' ) S ZSH_ARGZERO = zsh S ZSHBOOT = /aWorking/Zsh/Boot Srts ZSH_EVAL_CONTEXT = toplevel:shfunc:cmdsubst Arts zsh_eval_context = ( toplevel shfunc cmdsubst ) S ZSH_NAME = zsh S ZSH_PATCHLEVEL = debian/5.8-6+deb11u1 Arhvs zsh_scheduled_events = !hidden! Irs ZSH_SUBSHELL = 1 S ZSH_VERSION = 5.8 ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-27 17:51 ` Ray Andrews @ 2023-01-27 20:45 ` Bart Schaefer 2023-01-27 21:09 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-27 20:45 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Jan 27, 2023 at 9:51 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > t: The variable is 'tied' to another variable (see docs: 'typeset -T'). > > ... edits and corrections most welcome. Have I missed any? You'll probably never see it, but "typeset -t" puts a "tag" on the variable. This is completely meaningless to anything/anyone except program(mer)s using "typeset -t" and I have no recollection of the use-case for which it was added. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-27 20:45 ` Bart Schaefer @ 2023-01-27 21:09 ` Ray Andrews 2023-01-27 23:45 ` scowles 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-27 21:09 UTC (permalink / raw) To: zsh-users On 2023-01-27 12:45, Bart Schaefer wrote: > On Fri, Jan 27, 2023 at 9:51 AM Ray Andrews <rayandrews@eastlink.ca> wrote: >> t: The variable is 'tied' to another variable (see docs: 'typeset -T'). >> >> ... edits and corrections most welcome. Have I missed any? > You'll probably never see it, but "typeset -t" puts a "tag" on the > variable. This is completely meaningless to anything/anyone except > program(mer)s using "typeset -t" and I have no recollection of the > use-case for which it was added. There's always one more thing. As you say, it sounds pretty marginal. Anyway I'm happy that: 0 /aWorking/Zsh/Source/Wk 0 $ typeset -p path typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) is now: 1 /aWorking/Zsh/Source/Wk 0 $ v path Stes PATH = .:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin Ats path = ( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... ... so all the confusions and incorrect assumptions the former lead me to are now clarified. Thanks for the help, it was a trail of tears. More work un-learning the wrong stuff than learning the right stuff. > ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-27 21:09 ` Ray Andrews @ 2023-01-27 23:45 ` scowles 2023-01-28 0:12 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: scowles @ 2023-01-27 23:45 UTC (permalink / raw) To: zsh-users; +Cc: Ray Andrews On Fri, 27 Jan 2023, Ray Andrews wrote: > Date: Fri, 27 Jan 2023 13:09:41 > From: Ray Andrews <rayandrews@eastlink.ca> > To: zsh-users@zsh.org > Subject: Re: path PATH > > On 2023-01-27 12:45, Bart Schaefer wrote: >> On Fri, Jan 27, 2023 at 9:51 AM Ray Andrews <rayandrews@eastlink.ca> wrote: >>> t: The variable is 'tied' to another variable (see docs: 'typeset -T'). >>> >>> ... edits and corrections most welcome. Have I missed any? >> You'll probably never see it, but "typeset -t" puts a "tag"... > > ... > Anyway I'm happy that: > > 0 /aWorking/Zsh/Source/Wk 0 $ typeset -p path > typeset -aT PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin > /usr/sbin /usr/bin ) > > is now: > > 1 /aWorking/Zsh/Source/Wk 0 $ v path > ... as a lurker on the list, i am very grateful that you, ray, persevered through this thread. if dp(){} has changed since yesterday, would you mind posting your latest version? the details from bart, roman, and mikael in both of these related threads ( -Re: path PATH, -Re: A way to untie -T vars?) have been quite helpful. -- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-27 23:45 ` scowles @ 2023-01-28 0:12 ` Ray Andrews 2023-01-28 3:47 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-28 0:12 UTC (permalink / raw) To: zsh-users On 2023-01-27 15:45, scowles@ckhb.org wrote: > > as a lurker on the list, i am very grateful that you, ray, persevered > through this thread. if dp(){} has changed since yesterday, would you > mind posting your latest version? > The guts of it are almost exactly as Bart left it, but my version tarts it up a little bit: A few notes: 'infomsg' is just a colored message, 'echo' is fine. ${cyn} is just the color code for cyan, and ${nrm} is the code for 'normal'. I like colored output. As I have it, the accumulated output goes to a variable instead of printing directly but the old code is there too. And I've shortened the type-strings to single letters but that's easy to cut out if you want. Oh, and I also truncate at screen width but that's also easy to cut out. I Don't need to see those huge variables full length: function v () # For 'variables'. { [[ "$1" = '-h' || "$1" = '-s' ]] && \ { infomsg " List attributes and values of all variables indicated by FILTER. v ,CSsp [FILTER] v ,C: SENS: (if FILTER is given). v ,S: Show only if the value is not hidden. v ,s: Show only if the value IS hidden. v ,p: Plain, no color, this is good when the output needs to be sent to a file. FILTER: if given, is a pattern of variable names. If wildcards are given then the argument must be quoted to avoid expansion by the shell. TYPES: These are condensed from the detailed information you can see like this: '$ print ${(t)path}'. Basic types are capitalized, modifiers are in lower case: S: An ordinary scalar (not an integer or float). I: An integer. F: A float ('typeset -F:' decimal display or 'typeset -E': scientific display). A: A normal array. H: An associative array or 'association' or 'hash' (always 'hideval' as well). e: The variable has been exported to the environment and is thus persistent within that terminal -- it will be inherited by subshells. l: The variable is local to the running function. t: The variable is 'tied' to another variable (see docs: 'typeset -T'). s: The variable is special to the shell. r: The variable is read-only (this often goes with 'special'). v: 'hideval': the value of the variable will be hidden -- there are things we really don't want to see, like lists of color codes. This tends to go with 'special' and 'hide'. h: Hide: Used with 'special' (see docs: 'typeset -h'). u: Unique: ?? ?: Undefined: For autoloaded parameters not yet loaded (whatever that means). " return } local ccolored=( sed -r "s/^(.{6})([^ = ]*)/\1${cyn}\2${nrm}/" ) local hhidden=( ) local case='(#i)' local width=$(( COLUMNS - 5 )) local line= typeset -ga VARIABLES=() if [[ ${1:0:1} == ',' ]]; then for ((i=1; i < ${#1}; i++)); do case ${1:$i:1} in C ) case= ;; # Enable case sensitive. p ) ccolored= ;; # 'plain': no color. S ) hhidden=( grep -v ' = !hidden!' ) ;; # Show only if a value is set. s ) hhidden=( grep ' = !hidden!' ) ;; # Show only if a value is NOT set. * ) errormsg "No such switch \",${1:$i:1}\""; return 1 ;; esac done shift fi # End: process ',' switches. # If a capital letter is given then force case sensitivity: [[ $@ == *[[:upper:]]* ]] && case= # Default is all params: [ ! "$@" ] && set 1 '*' set -- ${(ok)parameters[(I)${case}${~${(j.|.)@}}]} while ((ARGC)); do # Type eg: 'scalar ' # print -rn -- "${parameters[$1]} " line+="${parameters[$1]} " if [[ -${parameters[$1]}- = *-hideval-* ]] then # Append name and '=-hidden-' # If param is hidden, typeset won't show anything so use this: # print -r -- ${(q-)1} line+="${(q-)1}=!hidden!" else # Append name and value eg: 'ZSH_VERSION=5.8': # typeset -m -- ${(b)1} line+=$( typeset -m -- ${(b)1} ) fi VARIABLES+="$line" line= shift done echo [ ! "$VARIABLES" ] && warningmsg "Nothing found" && return 1 print -rl -- $VARIABLES | sed \ -re "s/(^[^ ]*) ([^=]*)=(.*)/\1 \2 = \3/" \ -e "s/scalar[ |-]/S/" \ -e "s/integer[ |-]/I/" \ -e "s/float[ |-]/F/" \ -e "s/array[ |-]/A/" \ -e "s/association[ |-]/H/" \ -e "s/export[ |-]/e/" \ -e "s/local[ |-]/l/" \ -e "s/special[ |-]/s/" \ -e "s/readonly[ |-]/r/" \ -e "s/hideval[ |-]/v/" \ -e "s/hide[ |-]/h/" \ -e "s/tied[ |-]/t/" \ -e "s/unique[ |-]/u/" \ -e "s/undefined[ |-]/?/" \ -e "s/^([^ ]*)/\1 /" \ -e "s/^(.{6}) */\1/" \ -e "s/^(.{1,${width}}).*/\1/" \ -e "s/^(.{$width})/\1 .../" \ | ${ccolored:-cat} | ${hhidden:-cat} } # END: v() allvars () { # Name and type: print -l -- "\n${cyn}ALL VARIABLES AND THEIR TYPES:${nrm} \n" printf "%-25s %s\n" ${(kv)parameters} | sort # Types only: # printf "%s\n" ${(v)parameters} | sort } nullvars () { # emulate -L zsh -o extendedglob nnullvars=() for name in ${(k)parameters}; do if [[ -z ${(P)name} ]]; then # print -r -- $name nnullvars+="$name" fi done print -l -- "\n${cyn}NULL VARIABLES:${nrm} \n" print -l -- "$nnullvars[@]" | sort } ... hope you like it! ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-28 0:12 ` Ray Andrews @ 2023-01-28 3:47 ` Bart Schaefer 2023-01-28 16:42 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-28 3:47 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Jan 27, 2023 at 4:12 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > local ccolored=( sed -r "s/^(.{6})([^ = ]*)/\1${cyn}\2${nrm}/" ) > local hhidden=( ) > > local case='(#i)' > local width=$(( COLUMNS - 5 )) > local line= > typeset -ga VARIABLES=() All of these are going to obscure the types of any variables in the surrounding scope that share those names. That's one reason I was careful not to use any locals in my function. > print -rl -- $VARIABLES | sed \ Does this do the right thing if you have a variable named $scalar (or $array, etc.?) It'd be better to convert the value of ${parameters[$1]} as you find it, rather than build the whole output and then rewrite it. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-28 3:47 ` Bart Schaefer @ 2023-01-28 16:42 ` Ray Andrews 2023-01-28 22:51 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-28 16:42 UTC (permalink / raw) To: zsh-users On 2023-01-27 19:47, Bart Schaefer wrote: > typeset -ga VARIABLES=() > All of these are going to obscure the types of any variables in the > surrounding scope that share those names. That's one reason I was > careful not to use any locals in my function. I noticed that. The only 'local's shown are the funcs internal ones. Could give 'em names unlikely to be used elsewhere. I've seen that sort of thing. Or is there a better way? Given the branching and switches, I can't think how to do it in one string of pipes w.o. intermediate variables. And variables to hold the switches. > >> print -rl -- $VARIABLES | sed \ > Does this do the right thing if you have a variable named $scalar (or > $array, etc.?) I take it for granted that my colorizing and various condensations and formattings are always going to leak, but they're not mission critical just efforts to make things look better most of the time. When I find a leak I patch it if I can. Still it's a good thing to do things in the most robust way of course. > > It'd be better to convert the value of ${parameters[$1]} as you find > it, rather than build the whole output and then rewrite it. Well, the paint isn't even dry on that effort I posted. Improvements most welcome. As I have it now, it's just sequential thinking -- first get the core functionality, then add the switches (case, etc.) then massage the output. No doubt it can be handled better. It's C- coding. Anyway the whole exercise is just a 'cry for help' -- typeset -p (or typeset -P) should give us full disclosure. display-params() should be hard coded and, IMHO, accessed via a switch to typeset. Wiser people disagree, but that's my two cents. Nuts, there's already, what? three or five functions that sorta attempt to display this information but none of them shows it all. Seems to me a full listing of params with *all* attributes and values is core functionality. And the doc should discuss *all* the attributes in one place. Every last one. </whine> :-) ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-28 16:42 ` Ray Andrews @ 2023-01-28 22:51 ` Bart Schaefer 2023-01-29 2:30 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-28 22:51 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 28, 2023 at 8:42 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Could give 'em names unlikely to be used elsewhere. I've seen that sort > of thing. Or is there a better way? Given the branching and switches, > I can't think how to do it in one string of pipes w.o. intermediate > variables. And variables to hold the switches. You're already resorting to a subshell for > line+=$( typeset -m -- ${(b)1} ) So why not get rid of "line", go back to printing everything to stdout, and (if you still need to) put the entire function call in $(...) ? Instead of forking for each parameter, fork once for the whole main body of the function. As far as I can tell, "case" is the only bit that matters to finding the parameter names (although you could do hidden/not without piping to grep). So your $case is for example ${~${1:#*C*}:-'(#i)'} which you can feed into the arguments of dp. Take a look at the way the "untie" function I posted elsewhere takes care of managing the list of typeset switches needed to preserve the attributes of the parameter that's left behind after untying. > Anyway the whole exercise is just a 'cry for help' -- typeset -p (or > typeset -P) should give us full disclosure. You're the first person in 30+ years to ask for this, so it's not surprising that it hasn't been done so far. I still don't really grasp why this is helpful to you (especially when what you do with is it squash it down to a bunch of cryptic one-letter abbreviations). > And the doc should discuss *all* the attributes in one place. They are all discussed in the documentation for "typeset", they're just not all laid out in a table. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-28 22:51 ` Bart Schaefer @ 2023-01-29 2:30 ` Ray Andrews 2023-01-29 3:03 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-29 2:30 UTC (permalink / raw) To: zsh-users On 2023-01-28 14:51, Bart Schaefer wrote: > So why not get rid of "line", go back to printing everything to ... Heavy duty suggestions. The difference between your level and my level. If it wasn't presumptuous I'd just ask you to clean it up for me and then I'd study the changes. Otherwise I'll see if I can understand and implement. I know my code is amateurish. Ah, for a master class, where I could have all my code critiqued. > You're the first person in 30+ years to ask for this, so it's not > surprising that it hasn't been done so far. Can't argue with that. OTOH most people conform their expectations to what's currently available -- basically they only ask for what they have. But if better information were available, they might very well come to value and expect that. Not to wander too far off topic but Windows users think that Windows is 'the universe' and that there's nothing more or better to even be contemplated. And when you tell them that there is more and better, they aren't even interested cuz it would involve expanding their tiny minds. > I still don't really > grasp why this is helpful to you (especially when what you do with is > it squash it down to a bunch of cryptic one-letter abbreviations). 1 /aWorking/Zsh/Source/Wk 1 $ v path Stes PATH = .:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin Ats path = ( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... ... because the above is accurate. If that information had been (easily) available to me, this thread would never have been started. What is a tied variable? As we see, a scalar is created from an array, named in all caps, and then exported. As it was: 0 /aWorking/Zsh/Source/Wk 0 $ typeset -p PATH export -T PATH path=( . /aWorking/Zsh/System /aWorking/Bin /usr/local/bin /usr/sbin /usr/bin ) ... and I'm interpreting that as saying that PATH and path are two different names for the same var. It seems like so long ago :( The expanded 'full-word' descriptions are of course available, but with the compressed form one has room for the value too. Once I sort out your suggestions above I think I'll add a 'full word' switch, but without the values. Mind I already have that with: 0 /aWorking/Zsh/Source/Wk 0 $ allvars ALL VARIABLES AND THEIR TYPES: $ integer-readonly-special 0 scalar-special aa scalar a integer aliases undefined ARGC integer-readonly-special ... zsh_eval_context array-readonly-tied-special ZSH_EVAL_CONTEXT scalar-readonly-tied-special ZSH_NAME scalar ZSH_PATCHLEVEL scalar zsh_scheduled_events undefined ZSH_SUBSHELL integer-readonly-special ZSH_VERSION scalar ... work in progress of course. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 2:30 ` Ray Andrews @ 2023-01-29 3:03 ` Bart Schaefer 2023-01-29 3:44 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-29 3:03 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 28, 2023 at 6:31 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-01-28 14:51, Bart Schaefer wrote: > > > I still don't really > > grasp why this is helpful to you > > ... because the above is accurate. That's not an answer to the question. Other available information is also accurate, just not (what you consider) complete. > ... and I'm interpreting that as saying that PATH and path are two > different names for the same var. Still not an answer. They actually ARE two different names for the same operation of the shell, so what difference did it make to you? When do you ever need to know this for a variable you can't look up by name in the docs? If the answer is just because you're curious, that's perfectly fine, but it isn't necessarily a justification for adding something to the C code of the shell. Incidentally, "typeset -P" is already co-opted by the zsh/param/private module. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 3:03 ` Bart Schaefer @ 2023-01-29 3:44 ` Ray Andrews 2023-01-29 4:35 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-29 3:44 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On 2023-01-28 19:03, Bart Schaefer wrote: > > That's not an answer to the question. Other available information is > also accurate, just not (what you consider) complete. Hmmm ... OK, as you use the word. As I was using it 'accurate' includes complete and unambiguous and helpful. Short of dp, there was no direct way of seeing *all* the attributes. I don't get it Bart, you and Roman provided a very nice function and at the same time you're speaking as if there was nothing for it to do. > If the answer is just because you're curious, that's perfectly fine, > but it isn't necessarily a justification for adding something to the C > code of the shell. That's for the dev's judgement of course. I have what I want in any case. Dunno, I guess it's just my mentality. I like complete information estheticaly displayed. Matter of principle mostly, but sometimes of practice. As in this case, I'm occasionally thrown off the scent by something misleading or incomplete. I've had two private messages thanking *me* for dp even tho I didn't write it. So I'm not the only guy liking that display. I still think it should be a core competence. > > Incidentally, "typeset -P" is already co-opted by the zsh/param/private module. I picked '-P' as a for instance -- sorta 'p' on steroids. Come to that, just philosophically speaking, I don't like commands having both active and passive functionality anyway, so it shouldn't be attached to typeset. You don't want to type a command to 'see' something and end up 'doing' something by accident. Imagine if 'rm' had a passive usage: 'rm -V' ... view previous deletions ... and you type 'rm -r' by mistake and ... Nope, I was wrong to use typeset to display information from the getgo. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 3:44 ` Ray Andrews @ 2023-01-29 4:35 ` Bart Schaefer 2023-01-29 15:54 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-29 4:35 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sat, Jan 28, 2023 at 7:45 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > I don't get it Bart, you and Roman > provided a very nice function and at the same time you're speaking as > if there was nothing for it to do. It's the other way around. The function gave you what you want, so there's nothing for a built-in to the shell to do. If NO function could give you what you wanted, that's a different question. E.g., it's a valid point that a parameter declared with "typeset -E" could be more accurately described by $parameters / ${(t)var}, or that justification width could be more obviously obtainable than just "typeset +m", or even that the documentation could do a better job of relating ${(t)var} to the options of "typeset" (I've submitted a patch for that last, incidentally). ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 4:35 ` Bart Schaefer @ 2023-01-29 15:54 ` Ray Andrews 2023-01-29 21:21 ` Lawrence Velázquez 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-29 15:54 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 4491 bytes --] On 2023-01-28 20:35, Bart Schaefer wrote: > > It's the other way around. The function gave you what you want, so > there's nothing for a built-in to the shell to do. Sure, that's a design decision. How useful does something have to be before it's hard-coded. Matter of judgement. Tho I'm vocal with my opinion, at the end of the day it's not my call, nor should it be. However a guy like you is so conformed to the status quo -- nuts, you built it -- that you no longer 'see' the defects as defects (this presuming I'll right when in fact I am often wrong). Where a guy like me can be useful is in providing a fresh view of things. I advocate for spelling reform. Folks who's spelling is perfect say that spelling reform isn't needed. > If NO function could give you what you wanted, that's a different > question. E.g., it's a valid point that a parameter declared with > "typeset -E" could be more accurately described by $parameters / > ${(t)var}, or that justification width could be more obviously > obtainable than just "typeset +m", That's another interesting question. IMHO core functionality is not -- or not hugely -- concerned with appearance -- the individual tarts things up as he sees fit -- but *complete* information is a core function. OTOH, a justification option would be very nice -- saves me the trouble. But, for example, I'd put spaces around the equal signs cuz it then breaks the output into logical words and thus makes it very much easier to, say, columnize the display. > or even that the documentation > could do a better job of relating ${(t)var} to the options of > "typeset" (I've submitted a patch for that last, incidentally). In that case my opinion is that the 'Parameters' section of the manual should tell the whole story vs. the information being attached to individual commands, since there are several commands -- not to mention ${(t)...} -- that have a duplicated use/reference to the attributes; so they should all refer back to Mother. IOW, the fact that parameters have attributes is a fundamental feature of the shell irrespective of any particular command, not an incidental collection of details pertaining to this command or that command. That could be said better. In the crudest, outline form, add something like the 'help' for my function: 15.1 Description A parameter has a name, a value, and a number of attributes. A name may be any sequence of alphanumeric characters and underscores, or the single characters ‘*’, ‘@’, ‘#’, ‘?’, ‘-’, ‘$’, or ‘!’. A parameter whose name begins with an alphanumeric or underscore is also referred to as a /variable/. The attributes of a parameter determine the /type/ of its value, often referred to as the parameter type or variable type, and also control other processing that may be applied to the value when it is referenced. The value type may be a /scalar/ (a string, an integer, or a floating point number), an array (indexed numerically), or an /associative/ array (an unordered set of name-value pairs, indexed by name, also referred to as a /hash/). Here's a complete list of the types and the attributes ( with their single-letter designations as used in various commands [ maybe not but .... ] ): TYPES: S: An ordinary scalar (not an integer or float). I: An integer. F: A float ('typeset -F:' decimal display or 'typeset -E': scientific display). A: A normal array. H: An associative array or 'association' or 'hash' (always 'hideval' as well). ATTRIBUTES: e: The variable has been exported to the enironment and is thus persistent within that terminal -- it will be inherited by subshells. l: The variable is local to the running function. t: The variable is 'tied' to another variable. s: The variable is special to the shell. r: The variable is read-only (this often goes with 'special'). v: 'hideval': the value of the variable will be hidden -- there are things we really don't want to see, like lists of color codes. This tends to go with 'special' and 'hide'. h: Hide: Used with 'special' ?? u: Unique: ?? ?: Undefined: For autoloaded parameters not yet loaded (whatever that means). These types and attributes will now be discussed in detail: ... back to text. BTW, that section of the manual is very well written, almost literate, and technical writing hardly ever is, tho I do wish it was complete. BTW am I mistaken that 'hideval' is not discussed anywhere? [-- Attachment #2: Type: text/html, Size: 6168 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 15:54 ` Ray Andrews @ 2023-01-29 21:21 ` Lawrence Velázquez 2023-01-29 22:33 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-29 21:21 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 29, 2023, at 10:54 AM, Ray Andrews wrote: > BTW am I mistaken that 'hideval' is not discussed anywhere? Look up typeset -H in zshbuiltins(1). -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 21:21 ` Lawrence Velázquez @ 2023-01-29 22:33 ` Ray Andrews 2023-01-29 22:42 ` Lawrence Velázquez 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-29 22:33 UTC (permalink / raw) To: zsh-users On 2023-01-29 13:21, Lawrence Velázquez wrote: > On Sun, Jan 29, 2023, at 10:54 AM, Ray Andrews wrote: >> BTW am I mistaken that 'hideval' is not discussed anywhere? > Look up typeset -H in zshbuiltins(1). > No mention of 'hideval' that I can see. It's not a stretch to understand that '-H' will set the attribute that is called 'hideval' but IMHO that should be explicit. That's why I suggest that all this stuff be explained in one place, namely in the 'Parameters' section of the manual. BTW since 'typeset -p' claims to display information in the same format as for the recreation of the parameter: 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz typeset -i zzz ... but if I run that output as a new command, the -H is clearly lost. 'typeset -p' does not do what it claims to do. Contrast my function (dp is the guts of it): 1 /aWorking/Zsh/Source/Wk 0 $ v zzz Iv zzz = !hidden! ... an integer with the 'hideval' attribute set. Accurate and complete. (Tho using my made-up contractions.) Long form: 1 /aWorking/Zsh/Source/Wk 0 $ allvars | grep zzz zzz integer-hideval 'exported' and 'special' are discussed in the 'Parameters' section of the manual, the others are not. 'readonly' is explicitly discussed in the above section of zshbuiltins but no other attribute names are. 'hideval' is referenced in the 'PARAMETER EXPANSION' section of the manual but nowhere else. It's not optimal. It might take a paragraph or two to completely cover the subject, why not do that? What is the virtue in having bits of information on one subject scattered all over? Seems that the subsection 'Parameter Expansion Flags' under 't' does show them all. So it wouldn't be much work to flesh out the information there and merge it into 'Parameters' for a complete understanding of the subject in one place. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 22:33 ` Ray Andrews @ 2023-01-29 22:42 ` Lawrence Velázquez 2023-01-30 0:42 ` Ray Andrews 2023-01-30 4:41 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-29 22:42 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Jan 29, 2023, at 5:33 PM, Ray Andrews wrote: > On 2023-01-29 13:21, Lawrence Velázquez wrote: >> On Sun, Jan 29, 2023, at 10:54 AM, Ray Andrews wrote: >>> BTW am I mistaken that 'hideval' is not discussed anywhere? >> Look up typeset -H in zshbuiltins(1). >> > No mention of 'hideval' that I can see. It's not a stretch to > understand that '-H' will set the attribute that is called 'hideval' but > IMHO that should be explicit. The patch Bart mentioned earlier adds an explicit reference. > BTW since 'typeset -p' claims to display information in the same format > as for the recreation of the parameter: > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > typeset -i zzz > > ... but if I run that output as a new command, the -H is clearly lost. Feels like a bug. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 22:42 ` Lawrence Velázquez @ 2023-01-30 0:42 ` Ray Andrews 2023-01-30 0:46 ` Ray Andrews 2023-01-30 4:41 ` Bart Schaefer 1 sibling, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-30 0:42 UTC (permalink / raw) To: zsh-users On 2023-01-29 14:42, Lawrence Velázquez wrote: > The patch Bart mentioned earlier adds an explicit reference. Easier if all the exposition was in one place tho, one would quickly see what's missing. > > Feels like a bug. Yeah, and as I've said, apart from it, this thread would never have started. If typeset -p really did output exactly the string that would recreate the param that was input to it, then that would be just what I feel it should do -- and claims to do -- and dp wouldn't be needed. Oh, and it might as well output the value too cuz values are part of the input to a typeset, ergo a recreation would obviously include the value: 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz #typeset -i zzz typeset -Hi zzz=123 ... cool to be able to view a var and in such a way that one could just edit that and recreate the var in one go. typeset -p is a good idea, it just doesn't do what it claims to do. > ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 0:42 ` Ray Andrews @ 2023-01-30 0:46 ` Ray Andrews 0 siblings, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-30 0:46 UTC (permalink / raw) To: zsh-users On 2023-01-29 16:42, Ray Andrews wrote: > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > #typeset -i zzz > > typeset -Hi zzz=123 Question, how would you do that? Sent the output directly back to the command line for edit and re-execution? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-29 22:42 ` Lawrence Velázquez 2023-01-30 0:42 ` Ray Andrews @ 2023-01-30 4:41 ` Bart Schaefer 2023-01-30 5:16 ` Lawrence Velázquez 2023-01-30 14:40 ` Ray Andrews 1 sibling, 2 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-30 4:41 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users On Sun, Jan 29, 2023 at 2:43 PM Lawrence Velázquez <larryv@zsh.org> wrote: > > On Sun, Jan 29, 2023, at 5:33 PM, Ray Andrews wrote: > > > BTW since 'typeset -p' claims to display information in the same format > > as for the recreation of the parameter: > > > > ... but if I run that output as a new command, the -H is clearly lost. > > Feels like a bug. The explicit purpose of the hideval attribute is to prevent "typeset -p" (and several other things) from displaying/restoring the value. -p [ N ] If the -p option is given, parameters and values are printed in the form of a typeset command with an assignment, regardless of other flags and options. Note that the -H flag on parameters is respected; no value will be shown for these parameters. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 4:41 ` Bart Schaefer @ 2023-01-30 5:16 ` Lawrence Velázquez 2023-01-30 6:55 ` Bart Schaefer 2023-01-30 14:40 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-30 5:16 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Sun, Jan 29, 2023, at 11:41 PM, Bart Schaefer wrote: > On Sun, Jan 29, 2023 at 2:43 PM Lawrence Velázquez <larryv@zsh.org> wrote: >> >> On Sun, Jan 29, 2023, at 5:33 PM, Ray Andrews wrote: >> >> > BTW since 'typeset -p' claims to display information in the same format >> > as for the recreation of the parameter: >> > >> > ... but if I run that output as a new command, the -H is clearly lost. >> >> Feels like a bug. > > The explicit purpose of the hideval attribute is to prevent "typeset > -p" (and several other things) from displaying/restoring the value. > > -p [ N ] > If the -p option is given, parameters and values are printed > in the form of a typeset command with an assignment, > regardless of other flags and options. Note that the -H flag > on parameters is respected; no value will be shown for these > parameters. Hm, I was thinking about the omitted -H, not the omitted value (which I didn't even miss, admittedly). Then again, the variable can't be reconstructed without the value, so I'm not sure how valuable it would be for "typeset -p" output to retain the -H. As an aside: The "typeset -p" description is pretty clear about hiding the value of -H parameters, but then what does "the option does not apply if the parameter is specified by name" refer to in the -H description? -H Hide value: specifies that typeset will not display the value of the parameter when listing parameters; the display for such parameters is always as if the `+' flag had been given. Use of the parameter is in other respects normal, and the option does not apply if the parameter is specified by name, or by pattern with the -m option. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 5:16 ` Lawrence Velázquez @ 2023-01-30 6:55 ` Bart Schaefer 0 siblings, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-30 6:55 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: Ray Andrews, zsh-users On Sun, Jan 29, 2023 at 9:17 PM Lawrence Velázquez <larryv@zsh.org> wrote: > > As an aside: The "typeset -p" description is pretty clear about > hiding the value of -H parameters, but then what does "the option > does not apply if the parameter is specified by name" refer to in > the -H description? Badly-placed (or missing?) comma, plus use of "if" where "when" would be better. > the option does not > apply if the parameter is specified by name, or by > pattern with the -m option. The [-H] option does not apply [when] the parameter is specified [by name or by pattern] with the -m option. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 4:41 ` Bart Schaefer 2023-01-30 5:16 ` Lawrence Velázquez @ 2023-01-30 14:40 ` Ray Andrews 2023-01-30 14:55 ` Ray Andrews 2023-01-30 14:56 ` Roman Perepelitsa 1 sibling, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-30 14:40 UTC (permalink / raw) To: zsh-users On 2023-01-29 20:41, Bart Schaefer wrote: > The explicit purpose of the hideval attribute is to prevent "typeset > -p" (and several other things) from displaying/restoring the value. > Interesting, that's a logical dilemma. It's like writing into the constitution that the constitution cannot be changed. So then (my imaginary version): 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz typeset -Hi zzz=123 $ typeset -Hi zzz=456 # New value for zzz. ... very understandable that some vars should be hidden 'normally' but does that mean you have to start a new terminal to edit 'zzz'? -- that the country must be dissolved in order to change it's constitution? Usually there's a way to amend the constitution. So, in the same spirit, my lines above would seem to me to be the one and only legal way to view and edit zzz. Or, it could be decided that zzz can *never* be viewed. But then never edited as well? One thing I'd say for sure: (real code): 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz typeset -i zzz ... that's simply wrong. Hiding the '-H' merely fools you into thinking zzz is a plain integer with no value and that's not correct. My v() does: 1 /aWorking/Zsh/Source/Wk 0 $ v zzz Iv zzz = !hidden! ... so at least you see the attributes correctly ( I should use the 'real' single letters that typeset uses) even if you are still forbidden to see the value. It's a design decision of course, but IMHO every locked door has a key, every constitution can be amended and every var should be viewable and editable even if (in this case) only by explicit exception. Is there really no way at all to see the value of a hideval? Surely there is. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 14:40 ` Ray Andrews @ 2023-01-30 14:55 ` Ray Andrews 2023-01-30 14:56 ` Roman Perepelitsa 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-30 14:55 UTC (permalink / raw) To: zsh-users On 2023-01-30 06:40, Ray Andrews wrote: > > > ... so at least you see the attributes correctly ( I should use the > 'real' single letters that typeset uses) even if you are still > forbidden to see the value. It's a design decision of course, but > IMHO every locked door has a key, every constitution can be amended > and every var should be viewable and editable even if (in this case) > only by explicit exception. Is there really no way at all to see the > value of a hideval? Surely there is. > > > > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > typeset -i zzz > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset +H zzz > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > typeset -i zzz=123 > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=456 > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > typeset -i zzz > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset +H zzz > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > typeset -i zzz=456 > > ... it seems like a whole lot of trouble. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 14:40 ` Ray Andrews 2023-01-30 14:55 ` Ray Andrews @ 2023-01-30 14:56 ` Roman Perepelitsa 2023-01-30 15:56 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-30 14:56 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Jan 30, 2023 at 3:41 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > On 2023-01-29 20:41, Bart Schaefer wrote: > > The explicit purpose of the hideval attribute is to prevent "typeset > > -p" (and several other things) from displaying/restoring the value. > > > Interesting, that's a logical dilemma. It's like writing into the > constitution that the constitution cannot be changed. Are you confusing hideval with readonly? You can change the value of a hideval parameter like any other. % typeset -H foo=bar % foo=baz % print -r -- $foo baz > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -Hi zzz=123 > > 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p zzz > typeset -i zzz > > ... that's simply wrong This output may be confusing to you but it's not wrong. The absence of "=" in the output means this is a -H parameter. In one of the previous emails I wrote that you can recreate parameters in a fresh shell by evaluating the output of `typeset -p` from another shell. *That* was wrong. The docs don't claim this. > Hiding the '-H' merely fools you into thinking > zzz is a plain integer with no value and that's not correct. This *interpretation* of the output would be incorrect. > 1 /aWorking/Zsh/Source/Wk 0 $ v zzz > Iv zzz = !hidden! > > ... so at least you see the attributes correctly This is a different representation for the same information. You could argue that this representation is better because it is easier to parse for a human, or easier to understand correctly, or more difficult to understand incorrectly. You cannot say that it's more correct though. > Is there really no way at all to see the value of a > hideval? You can expand a hideval parameter like any other. % typeset -H foo=bar % print -r -- $foo bar Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 14:56 ` Roman Perepelitsa @ 2023-01-30 15:56 ` Ray Andrews 2023-01-30 16:09 ` Roman Perepelitsa 2023-01-30 17:50 ` Bart Schaefer 0 siblings, 2 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-30 15:56 UTC (permalink / raw) To: zsh-users On 2023-01-30 06:56, Roman Perepelitsa wrote: > > This is a different representation for the same information. You could > argue that this representation is better because it is easier to parse > for a human, or easier to understand correctly, or more difficult to > understand incorrectly. You cannot say that it's more correct though. Yeah, that's true. I shouldn't say 'wrong', it's more like 'misleading'. I myself think the '-H' should remain. > You can expand a hideval parameter like any other. > % typeset -H foo=bar > % print -r -- $foo > bar Ha! I tried everything but the simplest thing. But that begs the question of what 'hideval' really achieves if in fact it's not hidden at all. 1 /aWorking/Zsh/Source/Wk 0 $ typeset +H bg 1 /aWorking/Zsh/Source/Wk 0 $ typeset -p bg typeset -A bg=( [black]=$'\C-[[40m' [blue]=$'\C-[[44m' [cyan]=$'\C-[[46m' [default]=$'\C-[[49m' [green]=$'\C-[[42m' [grey]=$'\C-[[40m' [magenta]=$'\C-[[45m' [red]=$'\C-[[41m' [white]=$'\C-[[47m' [yellow]=$'\C-[[43m' ) 1 /aWorking/Zsh/Source/Wk 0 $ print -r $bg [ colored block characters here] 1 /aWorking/Zsh/Source/Wk 0 $ print -r ${(b)bg} [46m [47m [43m [45m [40m [44m [41m [49m [42m [40m 1 /aWorking/Zsh/Source/Wk 0 $ print -r ${(q+)bg} $'\C-[[46m' $'\C-[[47m' $'\C-[[43m' $'\C-[[45m' $'\C-[[40m' $'\C-[[44m' $'\C-[[41m' $'\C-[[49m' $'\C-[[42m' $'\C-[[40m' ... looks like I must still 'typeset +H' to see the real value -- keys and values that is. IMHO the whole thing is a mess. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 15:56 ` Ray Andrews @ 2023-01-30 16:09 ` Roman Perepelitsa 2023-01-30 16:24 ` Bart Schaefer 2023-01-30 23:05 ` Ray Andrews 2023-01-30 17:50 ` Bart Schaefer 1 sibling, 2 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-30 16:09 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Jan 30, 2023 at 4:57 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > But that begs the question of what 'hideval' really achieves if > in fact it's not hidden at all. It does what it says on the tin. From typeset docs: -H specifies that typeset will not display the value of the parameter when listing parameters > ... looks like I must still 'typeset +H' to see the real value -- keys > and values that is. These are not "real" values. You can choose any representation you like. It looks like you want this: printf '[%s]=%s ' "${(@kvq+)bg}" We keep going in circles. If `typeset -p` doesn't do exactly what you want, it doesn't mean it's broken or bad. If it was *impossible* to produce the output you want, that would be actually bad. Up until now all output that you've identified as desirable was shown to be possible to produce without extending zsh. This means there is no need to extend zsh. If you want to produce some output but don't know how, ask. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 16:09 ` Roman Perepelitsa @ 2023-01-30 16:24 ` Bart Schaefer 2023-01-30 16:34 ` Roman Perepelitsa 2023-01-30 23:05 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-30 16:24 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users On Mon, Jan 30, 2023 at 8:10 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > These are not "real" values. You can choose any representation you > like. It looks like you want this: > > printf '[%s]=%s ' "${(@kvq+)bg}" Actually he just wants typeset -m bg which is what describe-params does, so I don't know how we got off into these weeds again. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 16:24 ` Bart Schaefer @ 2023-01-30 16:34 ` Roman Perepelitsa 0 siblings, 0 replies; 119+ messages in thread From: Roman Perepelitsa @ 2023-01-30 16:34 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Mon, Jan 30, 2023 at 5:25 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Mon, Jan 30, 2023 at 8:10 AM Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > > > These are not "real" values. You can choose any representation you > > like. It looks like you want this: > > > > printf '[%s]=%s ' "${(@kvq+)bg}" > > Actually he just wants > > typeset -m bg > > which is what describe-params does, so I don't know how we got off > into these weeds again. Good point. Mine still stands though. Ray, if you don't like how `typeset -m` represents information, you can always produce your own hand-crafted output. If you don't know how, ask. Roman. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 16:09 ` Roman Perepelitsa 2023-01-30 16:24 ` Bart Schaefer @ 2023-01-30 23:05 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-30 23:05 UTC (permalink / raw) To: zsh-users On 2023-01-30 08:09, Roman Perepelitsa wrote: > > We keep going in circles. If `typeset -p` doesn't do exactly what you > want, it doesn't mean it's broken or bad. If it was *impossible* to > produce the output you want, that would be actually bad. Up until now > all output that you've identified as desirable was shown to be > possible to produce without extending zsh. This means there is no need > to extend zsh. I've agreed to that several times. My humble opinion is that typeset -p should produce a more complete output but that's just me. Don't take this stuff more seriously than I take it. Actually he just wants typeset -m bg ... yup. Just when I reconcile myself to my ... = !hidden! ... then I see that hideval or not, one *can* see the value after all. Ok, I surrender: typeset -p is a masterpiece of helpful, informative clarity. And hidden values are still entirely visible just as one would expect from something hidden. Got it. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 15:56 ` Ray Andrews 2023-01-30 16:09 ` Roman Perepelitsa @ 2023-01-30 17:50 ` Bart Schaefer 2023-01-31 0:42 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-30 17:50 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Jan 30, 2023 at 7:57 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Ha! I tried everything but the simplest thing. But that begs the > question of what 'hideval' really achieves if in fact it's not hidden at > all. hideval was introduced as an internal attribute to avoid having the large/hard-to-read contents of module-provided arrays (like $aliases, $parameters and especially $functions) spewed out in a wall of text when the user was not expecting it. Later, someone else said this would be useful for situations like global variables used to cache data across function invocations, where the user doesn't need to know the details of the function implementation -- so -H was added to typeset. In short, you shouldn't use it yourself unless you have a known reason, and if somebody else used it, it means they don't want you to be nosy. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-30 17:50 ` Bart Schaefer @ 2023-01-31 0:42 ` Ray Andrews 0 siblings, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-31 0:42 UTC (permalink / raw) To: zsh-users On 2023-01-30 09:50, Bart Schaefer wrote: > > hideval was introduced as an internal attribute to avoid having the > large/hard-to-read contents of module-provided arrays (like $aliases, > $parameters and especially $functions) spewed out in a wall of text > when the user was not expecting it. Sure. It makes sense that there are things you'd not want to look at unless explicitly requested. I'm actually a little surprised that they are so easy to look at. But as long as it's explicit then of course you should see what you want to see. I have no complaints other than typeset -p removing the '-H' flag which is clearly still in effect. But you guys are happy with it so that's the end of the subject. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-26 21:41 ` Bart Schaefer 2023-01-26 21:44 ` Bart Schaefer @ 2023-01-26 22:18 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-26 22:18 UTC (permalink / raw) To: zsh-users On 2023-01-26 13:41, Bart Schaefer wrote: > On Thu, Jan 26, 2023 at 1:00 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> undefined and local ... but the doc only mentions some of them > Where did you find "undefined" that led you to think it's a parameter modifier? Nuts, where did I see it? Things very loose here right now, too many irons in the fire. But it showed up. Then I tried to find it in the doc and saw this: If no attribute flags are given, and either no name arguments are present or the flag +m is used, then each parameter name printed is preceded by a list of the attributes of that parameter (array, association, exported, float, integer, readonly, or undefined for autoloaded parameters not yet loaded). If +m is used with attribute flags, and all those flags are in‐ troduced with +, the matching parameter names are printed but their values are not. ... I did see it. > ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 17:02 ` Roman Perepelitsa 2023-01-25 17:34 ` Ray Andrews @ 2023-01-25 22:18 ` Bart Schaefer 2023-01-25 23:10 ` Ray Andrews 1 sibling, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-25 22:18 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users On Wed, Jan 25, 2023 at 9:06 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > These parameters have values. The following three lines are equivalent > (assuming that foo isn't set beforehand): > > typeset foo > typeset foo= > typeset foo="" Note in passing that if the TYPESET_TO_UNSET option is in effect, the first of those three is not equivalent to the other two. > typeset -i foo Similarly. This exposes another case where only "typeset" can provide full information. % typeset +m foo integer foo % printf "<%s>\n" $parameters[foo] <> % The parameter is unset and so not in $parameters, but typeset "remembers" that it is an integer. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 22:18 ` Bart Schaefer @ 2023-01-25 23:10 ` Ray Andrews 2023-01-25 23:19 ` Bart Schaefer 0 siblings, 1 reply; 119+ messages in thread From: Ray Andrews @ 2023-01-25 23:10 UTC (permalink / raw) To: zsh-users On 2023-01-25 14:18, Bart Schaefer wrote: > > Similarly. > > This exposes another case where only "typeset" can provide full information. > > % typeset +m foo > integer foo > % printf "<%s>\n" $parameters[foo] > <> > % > > The parameter is unset and so not in $parameters, but typeset > "remembers" that it is an integer. > From the stands, it look to me like describe-params has to be the way. A new function is needed that cleans all this up, probably at the source code level. Mind, I'm biased, I've never liked typeset. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 23:10 ` Ray Andrews @ 2023-01-25 23:19 ` Bart Schaefer 2023-01-26 0:55 ` Ray Andrews 0 siblings, 1 reply; 119+ messages in thread From: Bart Schaefer @ 2023-01-25 23:19 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Jan 25, 2023 at 3:11 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > From the stands, it look to me like describe-params has to be the > way. Part of the point here is that describe-params won't help in this case. Fortunately, typeset-to-unset is off by default (it's a POSIX compatibility option). ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-25 23:19 ` Bart Schaefer @ 2023-01-26 0:55 ` Ray Andrews 0 siblings, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-26 0:55 UTC (permalink / raw) To: zsh-users On 2023-01-25 15:19, Bart Schaefer wrote: > > Part of the point here is that describe-params won't help in this > case. Fortunately, typeset-to-unset is off by default (it's a POSIX > compatibility option). Not as a script/function but as C source I'll bet you could come up with full disclosure. DP is at, what? 99%, but 100% is sweet. Or maybe there as some things that will always dangle. Like I was saying, I'll be there's no way to distinguish between 'integer int=0' and 'integer int=' ... you get zero either way. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-22 19:20 ` Bart Schaefer 2023-01-22 19:31 ` Roman Perepelitsa @ 2023-01-22 19:52 ` Ray Andrews 1 sibling, 0 replies; 119+ messages in thread From: Ray Andrews @ 2023-01-22 19:52 UTC (permalink / raw) To: zsh-users On 2023-01-22 11:20, Bart Schaefer wrote: > > I'm curious why you chose to do this? The "hide" attribute means that > a local does not preserve semantics of a special global, not that it's > name is invisible. I was just about to ask that. There's a lot to learn from Roman's code but in an experimental frame of mind I have it boiled down to: set -- "$@" ${(Pt)1} print -rn -- "$2 ${(q-)1}" # Seems unneeded: # set -- "$@" ${(M)2:#(array|association)(|-*)} print -r -- " = ${3:+( }${(j: :)${(@qqq)${(@kv)${(@P)1}}}}${3:+ )}" ... I'm completely new to this overwriting of '@', it works but it will take a while to assimilate. Never seen anything like it before. Don't know what to make of it. I'll be interested in Roman's response to your further points before I grab the final edit. Oh, and my last line above, that blows my breakers, I don't have a prayer of understanding it right now. 4 levels of nesting? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-21 16:21 ` Ray Andrews 2023-01-21 16:38 ` Roman Perepelitsa @ 2023-01-21 16:48 ` Bart Schaefer 1 sibling, 0 replies; 119+ messages in thread From: Bart Schaefer @ 2023-01-21 16:48 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users [-- Attachment #1: Type: text/plain, Size: 585 bytes --] On Sat, Jan 21, 2023 at 8:21 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > I suspect > that, as Lawrence said, it's because PATH is an internally created > modification of path, it's a scalar created from an array. So FOO is > all fine, but PATH has a certain specialness -- no other tied parameter > has one 'version' different from the other. > The definition of a tied parameter is that one of the pair is a scalar string with an internal delimiter defaulting to a colon, and the other is an array of the delimited values. There's nothing magic about PATH in this respect. [-- Attachment #2: Type: text/html, Size: 910 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: path PATH 2023-01-20 21:57 path PATH Ray Andrews 2023-01-20 22:20 ` Bart Schaefer @ 2023-01-21 5:47 ` Lawrence Velázquez 1 sibling, 0 replies; 119+ messages in thread From: Lawrence Velázquez @ 2023-01-21 5:47 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Jan 20, 2023, at 4:57 PM, Ray Andrews wrote: > As I understand it, the '-T' switch links two arrays that have different > names but the same content. No, "typeset -T" ties an array to a scalar, which is synthesized by joining the array's values with a separator character. -- vq ^ permalink raw reply [flat|nested] 119+ messages in thread
end of thread, other threads:[~2023-01-31 0:43 UTC | newest] Thread overview: 119+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-01-20 21:57 path PATH Ray Andrews 2023-01-20 22:20 ` Bart Schaefer 2023-01-21 2:23 ` Ray Andrews 2023-01-21 6:11 ` Lawrence Velázquez 2023-01-21 15:18 ` Ray Andrews 2023-01-21 15:25 ` Roman Perepelitsa 2023-01-21 16:21 ` Ray Andrews 2023-01-21 16:38 ` Roman Perepelitsa 2023-01-21 16:54 ` Ray Andrews 2023-01-21 17:01 ` Roman Perepelitsa 2023-01-21 18:53 ` Ray Andrews 2023-01-21 19:09 ` Roman Perepelitsa 2023-01-21 20:50 ` Ray Andrews 2023-01-21 21:11 ` Roman Perepelitsa 2023-01-21 20:19 ` Bart Schaefer 2023-01-21 20:26 ` env arrays (was: Re: path PATH) zeurkous 2023-01-22 17:28 ` Bart Schaefer 2023-01-21 21:03 ` path PATH Ray Andrews 2023-01-21 21:52 ` Lawrence Velázquez 2023-01-22 0:42 ` Ray Andrews 2023-01-22 12:29 ` Roman Perepelitsa 2023-01-22 14:17 ` Ray Andrews 2023-01-22 16:15 ` Bart Schaefer 2023-01-22 17:23 ` Ray Andrews 2023-01-22 19:20 ` Bart Schaefer 2023-01-22 19:31 ` Roman Perepelitsa 2023-01-22 19:51 ` Bart Schaefer 2023-01-22 19:56 ` Roman Perepelitsa 2023-01-22 20:03 ` Bart Schaefer 2023-01-22 21:56 ` Bart Schaefer 2023-01-22 22:02 ` Roman Perepelitsa 2023-01-22 22:27 ` Bart Schaefer 2023-01-22 23:03 ` Ray Andrews 2023-01-22 20:12 ` Ray Andrews 2023-01-22 21:11 ` Bart Schaefer 2023-01-22 22:44 ` Ray Andrews 2023-01-22 23:35 ` Lawrence Velázquez 2023-01-22 23:58 ` Ray Andrews 2023-01-23 0:49 ` Lawrence Velázquez 2023-01-23 1:33 ` Bart Schaefer 2023-01-23 1:49 ` Lawrence Velázquez 2023-01-23 1:11 ` Bart Schaefer 2023-01-23 1:56 ` Ray Andrews 2023-01-23 2:59 ` Lawrence Velázquez 2023-01-23 3:47 ` Ray Andrews 2023-01-23 10:37 ` Roman Perepelitsa 2023-01-23 15:28 ` Ray Andrews 2023-01-23 15:40 ` zeurkous 2023-01-23 16:02 ` Ray Andrews 2023-01-23 16:25 ` zeurkous 2023-01-23 16:26 ` Bart Schaefer 2023-01-24 20:00 ` Ray Andrews 2023-01-24 20:42 ` Bart Schaefer 2023-01-24 20:50 ` Bart Schaefer 2023-01-24 20:54 ` Ray Andrews 2023-01-24 23:28 ` Ray Andrews 2023-01-24 23:42 ` Bart Schaefer 2023-01-25 0:14 ` Ray Andrews 2023-01-25 16:38 ` Ray Andrews 2023-01-25 16:43 ` Roman Perepelitsa 2023-01-25 16:56 ` Ray Andrews 2023-01-25 17:02 ` Roman Perepelitsa 2023-01-25 17:34 ` Ray Andrews 2023-01-25 17:37 ` Roman Perepelitsa 2023-01-25 18:26 ` Ray Andrews 2023-01-25 18:34 ` Roman Perepelitsa 2023-01-25 19:00 ` Ray Andrews 2023-01-26 2:13 ` Ray Andrews 2023-01-26 2:37 ` Bart Schaefer 2023-01-26 4:27 ` Ray Andrews 2023-01-26 20:26 ` Ray Andrews 2023-01-26 20:29 ` Roman Perepelitsa 2023-01-26 20:59 ` Ray Andrews 2023-01-26 21:17 ` Bart Schaefer 2023-01-26 21:41 ` Bart Schaefer 2023-01-26 21:44 ` Bart Schaefer 2023-01-26 22:36 ` Ray Andrews 2023-01-26 22:43 ` Bart Schaefer 2023-01-27 0:19 ` Ray Andrews 2023-01-27 3:36 ` Ray Andrews 2023-01-27 17:51 ` Ray Andrews 2023-01-27 20:45 ` Bart Schaefer 2023-01-27 21:09 ` Ray Andrews 2023-01-27 23:45 ` scowles 2023-01-28 0:12 ` Ray Andrews 2023-01-28 3:47 ` Bart Schaefer 2023-01-28 16:42 ` Ray Andrews 2023-01-28 22:51 ` Bart Schaefer 2023-01-29 2:30 ` Ray Andrews 2023-01-29 3:03 ` Bart Schaefer 2023-01-29 3:44 ` Ray Andrews 2023-01-29 4:35 ` Bart Schaefer 2023-01-29 15:54 ` Ray Andrews 2023-01-29 21:21 ` Lawrence Velázquez 2023-01-29 22:33 ` Ray Andrews 2023-01-29 22:42 ` Lawrence Velázquez 2023-01-30 0:42 ` Ray Andrews 2023-01-30 0:46 ` Ray Andrews 2023-01-30 4:41 ` Bart Schaefer 2023-01-30 5:16 ` Lawrence Velázquez 2023-01-30 6:55 ` Bart Schaefer 2023-01-30 14:40 ` Ray Andrews 2023-01-30 14:55 ` Ray Andrews 2023-01-30 14:56 ` Roman Perepelitsa 2023-01-30 15:56 ` Ray Andrews 2023-01-30 16:09 ` Roman Perepelitsa 2023-01-30 16:24 ` Bart Schaefer 2023-01-30 16:34 ` Roman Perepelitsa 2023-01-30 23:05 ` Ray Andrews 2023-01-30 17:50 ` Bart Schaefer 2023-01-31 0:42 ` Ray Andrews 2023-01-26 22:18 ` Ray Andrews 2023-01-25 22:18 ` Bart Schaefer 2023-01-25 23:10 ` Ray Andrews 2023-01-25 23:19 ` Bart Schaefer 2023-01-26 0:55 ` Ray Andrews 2023-01-22 19:52 ` Ray Andrews 2023-01-21 16:48 ` Bart Schaefer 2023-01-21 5:47 ` Lawrence Velázquez
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).