* coloring substitution seems to eat next line. @ 2022-11-10 0:43 Ray Andrews 2022-11-10 8:02 ` Roman Perepelitsa 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-10 0:43 UTC (permalink / raw) To: Zsh Users So I'm trying to replace a sed with native zsh code. This stuff in inside a 'for' loop with 'aa' as the counter and '$filter' is 'zsh': cc[$aa]=$( print -r $cc[$aa] | sed -rn "s/($filter)/\x1b\[$color;1m\1\x1b\[0m/${sed_case}gp" ) ... that's the sed version working fine. But this: print "going in: $cc[aa]" cc[aa]=( ${${cc[aa]}//(#b)((#i)${filter})/$'\e[31;1m'${match[1]}$'\e[0m'} ) print "coming out: $cc[aa]" ... almost works but it seems to eat the next element of the array every now and then with no pattern that I can discern. /aWorking/garbageZSH colored /usr/share/zsh colored /aWorking/Zsh disappears going in but seems to be there going out , but not colored /aWorking/Backup/Zsh ditto /aWorking/Zsh-55555 colored /aWorking/Zsh/Zsh-5.8 no color as with above /usr/share/doc/zsh-common ditto ... however if I make the output array different from the input array everything is fine. But I've always had success with that sort of array being overwritten by some manipulation of itself, tho it seems dangerous. sed has no issue with it. Anyway, the expansion seems to interfere with the the clean separation of the elements that I'm hoping for. Using a separate output array is fine, still I'm curious as to what's going on. In particular the way some lines seem to disappear going 'in' -- I print the array element -- and get nothing at all, but there is output ... which seems impossible (tho it's never colorized). It seems the expansion/substitution is ignoring line endings or some such. I don't doubt there's some logic to what's happening but I sure don't get it. It hasta be line separated. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 0:43 coloring substitution seems to eat next line Ray Andrews @ 2022-11-10 8:02 ` Roman Perepelitsa 2022-11-10 18:25 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-10 8:02 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users On Thu, Nov 10, 2022 at 1:44 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > cc[$aa]=$( print -r $cc[$aa] | sed -rn > "s/($filter)/\x1b\[$color;1m\1\x1b\[0m/${sed_case}gp" ) > > ... that's the sed version working fine. But this: > > cc[aa]=( > ${${cc[aa]}//(#b)((#i)${filter})/$'\e[31;1m'${match[1]}$'\e[0m'} ) Differences in the second version compared to the first: - aa instead of $aa - slice assignment instead of scalar (almost certainly unintended) - hardcoded (#i) instead of $sed_case - hardcoded 31 instead of $color - $filter treated as a literal instead of regex Given that the second version works without errors, I assume that cc must be a regular (not associative) array. This means you can replace the whole loop with this: local MATCH MBEGIN MEND cc=(${cc//(#m)$~zsh_case$filter/$'\e[31;1m'$MATCH$'\e[0m'}) Here's a test: () { emulate -L zsh -o extended_glob local cc=(/foo/Zsh/bar /baz /ZSHzsh /zsh-zsh) local filter=zsh local zsh_case='(#i)' local MATCH MBEGIN MEND cc=(${cc//(#m)$~zsh_case$filter/$'\e[31;1m'$MATCH$'\e[0m'}) print -rC1 -- ${(qqqq)cc} print -rC1 -- $cc } > /aWorking/Zsh disappears going in but seems > to be there going out , but not colored You can debug this by printing all relevant parameters. print -r -- "going in: $cc[aa]" typeset -p cc aa filter ... typeset -p cc print -r -- "coming out: $cc[aa]" After that you can reproduce and dissect the issue in isolation. You can also ask other people for help and give them everything they need to reproduce the problem. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 8:02 ` Roman Perepelitsa @ 2022-11-10 18:25 ` Ray Andrews 2022-11-10 18:36 ` Roman Perepelitsa 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-10 18:25 UTC (permalink / raw) To: zsh-users On 2022-11-10 00:02, Roman Perepelitsa wrote: > Differences in the second version compared to the first: Sorry about the sloppy code Roman, the differences there don't matter but you have no way of knowing that. > - aa instead of $aa Does that matter? I thought it was one of those situations where the dollar sign is optional. > - slice assignment instead of scalar (almost certainly unintended) Indeed. I don't even know what the difference is. I've never heard of slice assignment :( > Given that the second version works without errors The first version using sed. > This means you can replace > the whole loop with this: > > local MATCH MBEGIN MEND > cc=(${cc//(#m)$~zsh_case$filter/$'\e[31;1m'$MATCH$'\e[0m'}) Unfortunately not. That works as you intend, but I need to filter not just colorize. Any line without all matches must be deleted. The 'for' loop runs the lines thru each filter in turn and must zero any line that does not match. You can debug this by printing all relevant parameters. > print -r -- "going in: $cc[aa]" > typeset -p cc aa filter Good idea! That's going to be useful. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 18:25 ` Ray Andrews @ 2022-11-10 18:36 ` Roman Perepelitsa 2022-11-10 18:45 ` Ray Andrews 2022-11-10 18:54 ` Bart Schaefer 0 siblings, 2 replies; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-10 18:36 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Nov 10, 2022 at 7:25 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2022-11-10 00:02, Roman Perepelitsa wrote: > > > Differences in the second version compared to the first: > Sorry about the sloppy code Roman, the differences there don't matter > but you have no way of knowing that. > > - aa instead of $aa > Does that matter? I thought it was one of those situations where the > dollar sign is optional. It matters if cc is an associative array. Given that you've (accidentally) used slice assignment with cc, it cannot be an associative array. > > - slice assignment instead of scalar (almost certainly unintended) > I've never heard of slice assignment :( These two aren't the same: cc[42]="foo bar" cc[42]=(foo bar) The second is a slice assignment. > > This means you can replace > > the whole loop with this: > > > > local MATCH MBEGIN MEND > > cc=(${cc//(#m)$~zsh_case$filter/$'\e[31;1m'$MATCH$'\e[0m'}) > > Unfortunately not. That works as you intend, but I need to filter not > just colorize. Any line without all matches must be deleted You can filter beforehand like this: cc=(${(M)cc:#*$filter*}) This assumes that $filter doesn't have metacharacters. If it does and you want to treat them as such, use $~filter. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 18:36 ` Roman Perepelitsa @ 2022-11-10 18:45 ` Ray Andrews 2022-11-10 18:54 ` Bart Schaefer 1 sibling, 0 replies; 39+ messages in thread From: Ray Andrews @ 2022-11-10 18:45 UTC (permalink / raw) To: zsh-users On 2022-11-10 10:36, Roman Perepelitsa wrote: > Does that matter? I thought it was one of those situations where the >> dollar sign is optional. > It matters if cc is an associative array. Given that you've > (accidentally) used slice assignment with cc, it cannot be an > associative array. Correct. Anyway that's good to know, I think I've only used an associative array once and not here. > I've never heard of slice assignment :( > These two aren't the same: > > cc[42]="foo bar" > cc[42]=(foo bar) > > The second is a slice assignment. Ok, I'll play with that. Sheesh, the things I don't even know that I don't know. Is there somewhere I can read up on that? > You can filter beforehand like this: > cc=(${(M)cc:#*$filter*}) > > This assumes that $filter doesn't have metacharacters. If it does and > you want to treat them as such, use $~filter. Thanks, I'll tinker with that. It will be satisfying to be able to avoid sed ... come to that I just went back to grep for the filter and colorization because sed's separation character might just be part of a directory name. These little things! grep is faster too. But native code will be best. > > Roman. > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 18:36 ` Roman Perepelitsa 2022-11-10 18:45 ` Ray Andrews @ 2022-11-10 18:54 ` Bart Schaefer 2022-11-10 19:28 ` Ray Andrews 1 sibling, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-10 18:54 UTC (permalink / raw) To: zsh-users; +Cc: Ray Andrews On Thu, Nov 10, 2022 at 10:36 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > These two aren't the same: > > cc[42]="foo bar" > cc[42]=(foo bar) The first one resets cc[42]. The second one both updates cc[42] and inserts a new cc[43] after it. There is also the form cc[42,44]=(foo bar) which removes three elements (42,43,44) and replaces them with two new ones (42 and 43). Hence a "slice". ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 18:54 ` Bart Schaefer @ 2022-11-10 19:28 ` Ray Andrews 2022-11-10 20:22 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-10 19:28 UTC (permalink / raw) To: zsh-users On 2022-11-10 10:54, Bart Schaefer wrote: > >> cc[42]="foo bar" >> cc[42]=(foo bar) > The first one resets cc[42]. The second one both updates cc[42] and > inserts a new cc[43] after it. Now there's a surprise. Nuts, that explains the weird output and the seemingly empty next element. It bleeding creates a new empty next element!! I'll leave it to more adept people to understand why that's ever wanted. Anyway, I stopped slicing (or did I start slicing? ...) anyway: cc[$aa]=( ${cc[$aa]/(#b)((#i)$filter)/$'\e['$color;1m${match[1]}$'\e[0m'} ) ... is the now slightly understandable strange output and ... cc[$aa]=${cc[$aa]/(#b)((#i)$filter)/$'\e['$color;1m${match[1]}$'\e[0m'} ... works just fine :-) I've gotten into the habit of always using the parentheses just because. > There is also the form > > cc[42,44]=(foo bar) > > which removes three elements (42,43,44) and replaces them with two new > ones (42 and 43). Hence a "slice". Sheesh. So it looks like I stopped slicing. But that just above is sorta understandable. BTW I'm not using Roman's '(#M)' syntax because it seems to want to print all sorts of values to the terminal. Like '$MATCH' is some internal variable that always prints itself or something. One last issue, tinkering with the code even as I compose this: cc[$aa]=${cc[$aa]/(#b)(${zsh_case}${filter})/$'\e['$color;1m${match[1]}$'\e[0m'} ... the one thing left is to insert '$zsh_case' in there, which so far is not working. But Roman has the answer: cc[$aa]=${cc[$aa]/(#b)($~zsh_case${filter})/$'\e['$color;1m${match[1]}$'\e[0m'} ... I have not idea what '$~' means, but it works. BTW, to my surprise, using native code gives the same performance as using grep, 40 seconds on a stress test here. sed wanted 43 seconds. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 19:28 ` Ray Andrews @ 2022-11-10 20:22 ` Bart Schaefer 2022-11-10 21:42 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-10 20:22 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Nov 10, 2022 at 11:28 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > I'll leave it to more adept people to understand why that's > ever wanted. It's just a quick way to lengthen or shorten arrays when not merely adding elements at the end. > Anyway, I stopped slicing (or did I start slicing? ...) anyway: > > cc[$aa]=( ${cc[$aa]/(#b)((#i)$filter)/$'\e['$color;1m${match[1]}$'\e[0m'} ) > > ... is the now slightly understandable strange output That would only be "strange" if the result in the parens somehow came out as either nothing, or as two or more strings with a space between, but ordinarily the fact that you're doing a single ${cc[$aa]} (regardless of the replacements) would mean you get exactly one element. > I've gotten into the habit of always using the > parentheses just because. Most of the time you want the parens when assigning all the elements of an array at once. You should not use the parens for anything that's meant to be a single string (or number). > BTW I'm not using Roman's '(#M)' syntax because it seems to want to > print all sorts of values to the terminal. That's almost certainly because of > > local MATCH MBEGIN MEND which should never appear except inside a function, and should only appear at the beginning of the function and not inside a loop. > ... I have not idea what '$~' means, but it works. $~foo (or ${~foo} means that the value of $foo should be interpreted as a glob pattern rather than as a literal string. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 20:22 ` Bart Schaefer @ 2022-11-10 21:42 ` Ray Andrews 2022-11-10 21:51 ` Roman Perepelitsa 2022-11-10 22:47 ` Bart Schaefer 0 siblings, 2 replies; 39+ messages in thread From: Ray Andrews @ 2022-11-10 21:42 UTC (permalink / raw) To: zsh-users On 2022-11-10 12:22, Bart Schaefer wrote: > > Most of the time you want the parens when assigning all the elements > of an array at once. You should not use the parens for anything > that's meant to be a single string (or number). Slowly I figure out what's really going on and don't have to rely on rote copying of syntax. > local MATCH MBEGIN MEND > which should never appear except inside a function, and should only > appear at the beginning of the function and not inside a loop. Heavy duty diagnostic stuff it seems. > $~foo (or ${~foo} means that the value of $foo should be interpreted > as a glob pattern rather than as a literal string. Ah! When you type it in there verbatim it seems to always be the pattern, but as a variable who's to say that the intention is? So some way of making it explicit avoids semantic confusion. That's robust, I like it. One more little thing: string="${cc[$aa]/*(#i)$filter*/}" if [[ "$string" ]]; then cc[aa]='' else cc[$aa]=${cc[$aa]/(#b)($~zsh_case${filter})/$'\e['$color;1m${match[1]}$'\e[0m'} ... to delete non-matching lines, but I'll bet there's a better way than this failed substitution. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 21:42 ` Ray Andrews @ 2022-11-10 21:51 ` Roman Perepelitsa 2022-11-11 17:24 ` Ray Andrews 2022-11-10 22:47 ` Bart Schaefer 1 sibling, 1 reply; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-10 21:51 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Nov 10, 2022 at 10:42 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > On 2022-11-10 12:22, Bart Schaefer wrote: > > > > Most of the time you want the parens when assigning all the elements > > of an array at once. You should not use the parens for anything > > that's meant to be a single string (or number). > Slowly I figure out what's really going on and don't have to rely on > rote copying of syntax. > > local MATCH MBEGIN MEND > > which should never appear except inside a function, and should only > > appear at the beginning of the function and not inside a loop. > Heavy duty diagnostic stuff it seems. > > $~foo (or ${~foo} means that the value of $foo should be interpreted > > as a glob pattern rather than as a literal string. > > Ah! When you type it in there verbatim it seems to always be the > pattern, but as a variable who's to say that the intention is? So some > way of making it explicit avoids semantic confusion. That's robust, I > like it. One more little thing: > > > string="${cc[$aa]/*(#i)$filter*/}" > if [[ "$string" ]]; then > cc[aa]='' > else > cc[$aa]=${cc[$aa]/(#b)($~zsh_case${filter})/$'\e['$color;1m${match[1]}$'\e[0m'} If you look back, you can find in my answers a way to: 1. Remove all elements of an array that don't match a pattern. It has this form: array=(${(M)array:#pattern}) 2. Perform a replacement in all elements of an array. Like this: array=(${array//pattern/substitute}) Perhaps now you have enough familiarity with the syntax to see how it works. You can save a tremendous amount of time by reading the official guide and the reference. Set aside an evening or two and read them from start to end. Exploring a language as a science project is a great way to get started but at some point you'll become more efficient by reading the blueprint. After that the language becomes an artifact rather than a blackbox. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 21:51 ` Roman Perepelitsa @ 2022-11-11 17:24 ` Ray Andrews 0 siblings, 0 replies; 39+ messages in thread From: Ray Andrews @ 2022-11-11 17:24 UTC (permalink / raw) To: zsh-users On 2022-11-10 13:51, Roman Perepelitsa wrote: > If you look back, you can find in my answers a way to: > 1. Remove all elements of an array that don't match a pattern. It has this form: > > array=(${(M)array:#pattern}) > > 2. Perform a replacement in all elements of an array. Like this: > > array=(${array//pattern/substitute}) > Fabulous: for filter in "$@"; do cc=( ${(M)cc:#*$~zsh_case${filter}*} ) cc=( ${cc//(#b)($~zsh_case${filter})/$'\e['$color;1m${match[1]}$'\e[0m'} ) done ... no need for a a loop processing each line one at a time. Once the non-matching lines are removed, the whole array can be colorized in one gulp. I knew there'd be an elegant way. > You can save a tremendous amount of time by reading the official guide > and the reference. IF you know what you are looking for! I can't look for '(M)' before I know the thing exists to be looked for. > Set aside an evening or two and read them from > start to end. This mortal would need to devote a year to it. I have tried but one needs to understand the jargon before it's even intelligible. But yes, it needs to be learned from the outside in. You experts don't realize how steep the learning curve is. Oh, for a glossary! ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 21:42 ` Ray Andrews 2022-11-10 21:51 ` Roman Perepelitsa @ 2022-11-10 22:47 ` Bart Schaefer 2022-11-10 23:07 ` Ray Andrews 1 sibling, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-10 22:47 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Nov 10, 2022 at 1:42 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > local MATCH MBEGIN MEND > > which should never appear except inside a function, and should only > > appear at the beginning of the function and not inside a loop. > Heavy duty diagnostic stuff it seems. Well, no. "local" is a variable scope declaration. But "local" is a synonym for "typeset" and we just had that long discussion about how "typeset" both declares variables and prints their values ... so you don't want to execute it multiple times, because the second+ time it is going to start printing instead of declaring. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 22:47 ` Bart Schaefer @ 2022-11-10 23:07 ` Ray Andrews 2022-11-10 23:27 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-10 23:07 UTC (permalink / raw) To: zsh-users On 2022-11-10 14:47, Bart Schaefer wrote: > Heavy duty diagnostic stuff it seems. > Well, no. "local" is a variable scope declaration. Yabut MBEGIN and MEND are showing values that are never explicitly set, they are showing some internal workings surely? Roman: > If you look back, you can find in my answers a way to: ... there's stuff pending. I had to sort out some other issues and now I'll be attending to your other suggestions. I sometimes have more information than I can digest at once. And I'm an old dog. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 23:07 ` Ray Andrews @ 2022-11-10 23:27 ` Bart Schaefer 2022-11-11 15:00 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-10 23:27 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Nov 10, 2022 at 3:07 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Yabut MBEGIN and MEND are showing values that are never explicitly set, > they are showing some internal workings surely? They are set by the (#m) operator in ${cc//(#m).../...} ... try looking those names up in the manual page, hmm? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-10 23:27 ` Bart Schaefer @ 2022-11-11 15:00 ` Ray Andrews 2022-11-11 18:15 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-11 15:00 UTC (permalink / raw) To: zsh-users On 2022-11-10 15:27, Bart Schaefer wrote: > On Thu, Nov 10, 2022 at 3:07 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> Yabut MBEGIN and MEND are showing values that are never explicitly set, >> they are showing some internal workings surely? > They are set by the (#m) operator in ${cc//(#m).../...} ... try > looking those names up in the manual page, hmm? If I ever cross paths with them again, then yeah. Worth noting tho is that one might actually search for 'MBEGIN' on the internet or even as a raw text search in the manual and find something. As I'm always whining, with most of zsh syntax issues that's impossible you have to already know the 'name of the family' of the sort of syntactical element that you are looking for. Is it a glob expansion or a parameter flag or a pattern match or ... what? You guys won't sympathize. Mind, this problem is sorta unavoidable since the syntax is so terse. What I wouldn't give for a glossary or a sort of overview of zsh syntactical elements '(#i)' -- so I've learned -- is a regex not a glob not a pattern match not any other sort of animal. Knowing that it's a regex, I know where to look for information. but '/**/' is a glob and '(N)' is a glob qualifier. Can't learn it from the inside out, only from the outside in. But my little immediate problems are always from the inside out. Slowly but surely tho. > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-11 15:00 ` Ray Andrews @ 2022-11-11 18:15 ` Bart Schaefer 2022-11-11 18:50 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-11 18:15 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Nov 11, 2022 at 7:00 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2022-11-10 15:27, Bart Schaefer wrote: > > On Thu, Nov 10, 2022 at 3:07 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > >> Yabut MBEGIN and MEND are showing values that are never explicitly set, > >> they are showing some internal workings surely? > > They are set by the (#m) operator in ${cc//(#m).../...} ... try > > looking those names up in the manual page, hmm? > If I ever cross paths with them again, then yeah. Why wouldn't you do this as soon as they began exhibiting behavior you found mysterious? > What I > wouldn't give for a glossary or a sort of overview of zsh syntactical > elements You mean like maybe the six indexes at the bottom of the page here? https://zsh.sourceforge.io/Doc/ > '(#i)' -- so I've learned -- is a regex not a glob not a > pattern match not any other sort of animal. That actually is (part of) a glob. The (?i) thing for PCRE is not going to be in the zsh doc, of course. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-11 18:15 ` Bart Schaefer @ 2022-11-11 18:50 ` Ray Andrews 2022-11-11 19:25 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-11 18:50 UTC (permalink / raw) To: zsh-users On 2022-11-11 10:15, Bart Schaefer wrote: > Why wouldn't you do this as soon as they began exhibiting behavior you > found mysterious? Because I'd never seen anything like that before and I had no idea where to even begin looking for an answer. God knows how many tools are out there that I've never even heard of. > > You mean like maybe the six indexes at the bottom of the page here? > https://zsh.sourceforge.io/Doc/ > > Not really. Again you'd have to know ahead of time what you're > looking for. But if I don't flame-out I think it's time to read > Peter's User's Guide. Then scan the manual end to end. Understandable > there's not more resources available tho, I think genuine neophytes to > zsh are very rare, almost everyone is already a shell adept even if > moving from, say, bash. I'll bet that even after several years I'm > still the junior man here. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-11 18:50 ` Ray Andrews @ 2022-11-11 19:25 ` Bart Schaefer 2022-11-11 21:26 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-11 19:25 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Nov 11, 2022 at 10:50 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2022-11-11 10:15, Bart Schaefer wrote: > > Why wouldn't you do this as soon as they began exhibiting behavior you > > found mysterious? > Because I'd never seen anything like that before and I had no idea where > to even begin looking for an answer. God knows how many tools are out > there that I've never even heard of. I find this response baffling. Roman wrote "local MATCH ..." so obviously it's a zsh thing. Even if it might be another tool, at least try checking the zsh manual first? https://zsh.sourceforge.io/Doc/Release/zsh_6.html#index_split-5_vr_letter-M > > You mean like maybe the six indexes at the bottom of the page here? > > https://zsh.sourceforge.io/Doc/ > > > Not really. Again you'd have to know ahead of time what you're > looking for. Isn't that also true of a glossary? I mean, go back to the mention of how you've never heard of $foo:t before. Well, gosh, look up "colon" in the concept index: https://zsh.sourceforge.io/Doc/Release/Concept-Index.html#Concept-Index-1_cp_letter-C Takes you right here: https://zsh.sourceforge.io/Doc/Release/Expansion.html#index-colon-modifiers Now you know it's called a "modifier" so when you see $foo:A you know where to look. Or you could look up "substitution" https://zsh.sourceforge.io/Doc/Release/zsh_4.html#index_split-3_cp_letter-S where you find that for parameters it's usually called "expansion" and expansion has flags and oh by the way there's even a set of expansion "rules" that will tell you all about the procedure zsh follows to perform one. Or you could just scan through the concept index to get an idea of what terminology you're likely to encounter on this list, without having to read the whole manual. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-11 19:25 ` Bart Schaefer @ 2022-11-11 21:26 ` Ray Andrews 2022-11-12 4:24 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-11 21:26 UTC (permalink / raw) To: zsh-users On 2022-11-11 11:25, Bart Schaefer wrote: > Because I'd never seen anything like that before and I had no idea where >> to even begin looking for an answer. God knows how many tools are out >> there that I've never even heard of. > I find this response baffling. Roman wrote "local MATCH ..." so > obviously it's a zsh thing. Even if it might be another tool, at > least try checking the zsh manual first? > Obviously but he showed it to me before I knew there was any such thing to look for. If I have need of it again then I'll be sure to read up on it. For now, it's water under the bridge. > https://zsh.sourceforge.io/Doc/Release/zsh_6.html#index_split-5_vr_letter-M Tx, now that I know there is such a thing, I'll read up on it. > Isn't that also true of a glossary? Not exactly. The sort of thing I have in mind would be purpose built to explain zsh anatomy. It would show you sample code and then 'dissect' it for you, explaining what all the bits and pieces are called and how they function. You'd get an understanding of the structure of the thing at the most zoomed out level. Anatomy 101. > > I mean, go back to the mention of how you've never heard of $foo:t > before. Well, gosh, look up "colon" in the concept index: You have me there. I was pleased to find out you could search for 'colon'. Searching for ':' was obviously not much use. Sorta like just recently the ':#' construction. You won't have much luck googling for 'zsh' ':#' you hafta know ahead of time the name of those sorts of manipulations. 'parameter expansions' no? Once I know what to call it, I can zoom in on the correct part of the manual. > Now you know it's called a "modifier" so when you see $foo:A you know > where to look. > > Or you could look up "substitution" Nuts, I thought I had it right with 'expansion' :( But yes, that's the thing, '//' ':#' '%%' ... these are substitutions. So yeah, that's the magic word that takes me to the relevant information. Without the terminology one is quite lost. > > https://zsh.sourceforge.io/Doc/Release/zsh_4.html#index_split-3_cp_letter-S > > where you find that for parameters it's usually called "expansion" and > expansion has flags and oh by the way there's even a set of expansion > "rules" that will tell you all about the procedure zsh follows to > perform one. Ah! So I was right the first time. Yes 'expansions' even when they are contractions -- doesn't matter what the word is, just so long as I know it. > > Or you could just scan through the concept index to get an idea of > what terminology you're likely to encounter on this list, without > having to read the whole manual. My imaginary glossary would be specifically designed to get you up to speed on terminology. Anyway it IS time to do some reading. Anecdote: when I first tried Linux, coming from DOS, one of the first things I wanted to find out was how you write a batch-file. Googled, nada. What? No batch-files in Linux? Well yes, but they're called scripts. And switches are called options. And variables are called parameters. And so on. Getting the lingo straight should be done up front with a purpose built document for that. > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-11 21:26 ` Ray Andrews @ 2022-11-12 4:24 ` Bart Schaefer 2022-11-12 14:03 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-12 4:24 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Nov 11, 2022 at 1:26 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2022-11-11 11:25, Bart Schaefer wrote: > > Isn't that also true of a glossary? > Not exactly. The sort of thing I have in mind would be purpose built to > explain zsh anatomy. It would show you sample code and then 'dissect' I've never heard the term "glossary" applied to something like that. This is a glossary: https://homepages.uc.edu/~thomam/Intro_Unix_Text/Glossary.html But you seem to want something more like the whole book: How about https://homepages.uc.edu/~thomam/Intro_Unix_Text/TOC.html (Or at least everything from Chapter 9 and later.) > recently the ':#' construction. You won't have much luck googling for > 'zsh' ':#' Indeed, search engine text indexing is lousy at short strings and punctuation. > > Or you could look up "substitution" > > where you find that for parameters it's usually called "expansion" > > Ah! So I was right the first time. Substitution is a special case of expansion. Globbing is also a special case of expansion. I was just trying to illustrate that the index will get you to the general case from the specific. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-12 4:24 ` Bart Schaefer @ 2022-11-12 14:03 ` Ray Andrews 2022-11-13 15:09 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-12 14:03 UTC (permalink / raw) To: zsh-users On 2022-11-11 20:24, Bart Schaefer wrote: > I've never heard the term "glossary" applied to something like that. True, as I muse I expand the idea from a glossary to a primer to a grammar. > This is a glossary: > https://homepages.uc.edu/~thomam/Intro_Unix_Text/Glossary.html That looks really good, I'm going to scan it end to end. Even if it was nothing more, something like that focused on zsh -- or I guess just 'shell' -- terminology would be invaluable to someone like me. Probably was something like that at one time but its fallen by the wayside since, as I said, raw beginners are now so rare. Really, how many people at my level are there now? I just decided to dive in at the deep end and learn to swim by not drowning. Inside out -- solve one problem at a time, and hope that the grammar would reveal itself eventually. Nope, the grammar is too terse, too powerful. Latin and Greek are 'C' by comparison. > But you seem to want something more like the whole book: > How about https://homepages.uc.edu/~thomam/Intro_Unix_Text/TOC.html > > (Or at least everything from Chapter 9 and later.) Nope, we already have 'the whole book' that's just the thing, I want the language to be able to read the whole book and understand it. Peter's 'From Bash to Z Shell' was good except that it discussed Bash as much as Zsh so it confused and diluted as much as it clarified and explained. > Indeed, search engine text indexing is lousy at short strings and punctuation. And that's the unavoidable dilemma. Zsh uses one or two characters as syntactic entities and those same characters might have three or four meanings in different contexts so the whole paradigm of the google search is just useless. Nope, hafta read the book. But manuals are not even designed to be helpful they are repositories of information that you consult when you know what you are looking for. The right book will have a glossary in it, helpful hints, anatomy lessons, and a 'phrase book' -- even if you can't speak German, you can learn to order a beer. Build up from simple examples. Mean time, my only salvation is asking you guys for help -- which I always get :-) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-12 14:03 ` Ray Andrews @ 2022-11-13 15:09 ` Ray Andrews 2022-11-14 14:12 ` Roman Perepelitsa 2022-11-14 17:08 ` Ray Andrews 0 siblings, 2 replies; 39+ messages in thread From: Ray Andrews @ 2022-11-13 15:09 UTC (permalink / raw) To: zsh-users Roman: cc=( ${(M)cc:#*$~zsh_case${filter}*} ) I've been applying that in some other functions but I need a variation that will erase non-matching lines but leave them as blanks so that array indexes do not change. Reason being that a subsequent merge with another array will happen and indexes must mesh. I'm doing it right now by using a dummy string as replacement for a non-match and then combining the arrays and then deleting the dummies but that's obviously clumsy. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-13 15:09 ` Ray Andrews @ 2022-11-14 14:12 ` Roman Perepelitsa 2022-11-14 17:08 ` Ray Andrews 1 sibling, 0 replies; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-14 14:12 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Sun, Nov 13, 2022 at 4:10 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Roman: > > cc=( ${(M)cc:#*$~zsh_case${filter}*} ) > > I've been applying that in some other functions but I need a variation > that will erase non-matching lines but leave them as blanks so that > array indexes do not change. This should do it: cc=( "${(@)cc/#%$~zsh_case^(*$filter*)}" ) This uses ${name/pattern/repl} with the pattern starting with %# to signify full match. Within the pattern ^ is negation. Double quotes with (@) are to retain empty elements. The rest you've already used, so it should be familiar. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-13 15:09 ` Ray Andrews 2022-11-14 14:12 ` Roman Perepelitsa @ 2022-11-14 17:08 ` Ray Andrews 2022-11-14 17:12 ` Roman Perepelitsa 1 sibling, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-14 17:08 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 983 bytes --] On 2022-11-13 07:09, Ray Andrews wrote: > Roman: > > cc=( ${(M)cc:#*$~zsh_case${filter}*} ) > > I've been applying that in some other functions but I need a variation > that will erase non-matching lines but leave them as blanks so that > array indexes do not change. Reason being that a subsequent merge > with another array will happen and indexes must mesh. I'm doing it > right now by using a dummy string as replacement for a non-match and > then combining the arrays and then deleting the dummies but that's > obviously clumsy. Stéphane Chazelas <https://unix.stackexchange.com/users/22565/st%c3%a9phane-chazelas> over at StackExchange offers this: cc=( "${cc[@]/#%^*$~zsh_case${filter}*}" ) ... and it seems to do exactly what I want. I understand the negation and the way the '[@]' and the outer quotes protect the length of the array, now I just need to understand the '#%' anchors -- but they are essential. > > > [-- Attachment #2: Type: text/html, Size: 1764 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-14 17:08 ` Ray Andrews @ 2022-11-14 17:12 ` Roman Perepelitsa 2022-11-14 18:58 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-14 17:12 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Nov 14, 2022 at 6:09 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Stéphane Chazelas over at StackExchange offers this: > > cc=( "${cc[@]/#%^*$~zsh_case${filter}*}" ) > This is the same as what I posted. > now I just need to understand the '#%' anchors See my previous post. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-14 17:12 ` Roman Perepelitsa @ 2022-11-14 18:58 ` Ray Andrews 2022-11-14 20:00 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-14 18:58 UTC (permalink / raw) To: zsh-users On 2022-11-14 09:12, Roman Perepelitsa wrote: > > This is the same as what I posted. Things get overlooked in the confusion, I often have ten things to learn all at the same time. I'll sometimes take some code on faith and forget that I've forgotten to really understand it. Or that an explanation was there previously. >> now I just need to understand the '#%' anchors I think I might: Because it's a negation, you have to force the match to include the entire element from beginning to end. You're sorta forcing a greedy match. " ^$foo " searched for in " xxxfoobarxxx " will match " xxxfo " but will not match the whole string -- which is to say that it matches and therefore is rejected by the caret forcing negation. It's not a simple construction. Oh, and I would never have figured it out by myself, too many things have to work together just right. > See my previous post. > > Roman. > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-14 18:58 ` Ray Andrews @ 2022-11-14 20:00 ` Bart Schaefer 2022-11-14 23:25 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-14 20:00 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Nov 14, 2022 at 10:58 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > >> now I just need to understand the '#%' anchors > > I think I might: Because it's a negation, you have to force the match > to include the entire element from beginning to end. You're sorta > forcing a greedy match. Yes, it forces a match of the entire string. No, that's not the same as "greedy". Given a pattern like "#%(*)foo(*)" and a string like "xxxfooyyyfoozzz", a "greedy" match would have the first (*) match "xxxfooyyy". A non-greedy match would have the second (*) match "yyyfoozzz" because the non-greedy first (*) matched only "xxx" before "foo". This isn't particularly important in the context here, but if you were using (#b) to activate backreferences it could be crucial. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: coloring substitution seems to eat next line. 2022-11-14 20:00 ` Bart Schaefer @ 2022-11-14 23:25 ` Ray Andrews 2022-11-15 14:17 ` Belaboring substitution syntax Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-14 23:25 UTC (permalink / raw) To: zsh-users On 2022-11-14 12:00, Bart Schaefer wrote: > > Yes, it forces a match of the entire string. No, that's not the same > as "greedy". Right, it seems to me that 'greedy' is perfectly defined and 'whole string' isn't it. It's a rather subtle thing getting these pattern matches to do what a casual intuition might think they do. Throw in a negation and it's not simple. That line would be a good candidate for dissection in one of my imagined anatomy lessons. Really, it's half an hour to completely understand it. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Belaboring substitution syntax 2022-11-14 23:25 ` Ray Andrews @ 2022-11-15 14:17 ` Ray Andrews 2022-11-16 1:49 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-15 14:17 UTC (permalink / raw) To: zsh-users Ignore this post unless you're the sort of person who loved grammar in school: cc=( "${cc[@]/#%^*$~zsh_case${filter}*}" ) ... working fine, and approved by Stephane and Roman. But, trying to 'feel' the rightness of it, I sorta get that '[@]' is saying: "process this array line by line" thus preserving array indexes. I'm not sure about the quotes. Quotes seem to mostly combine words into lines -- or should I say that they mostly combine what would be word splitting into bigger elements: array=( "this array" "has" "three elements" ) ... and sometimes the quotes seem to protect stuff from expansion or interpretation: " $ echo "Yar 'en ign'rint fool!" ". In my case, leaving the quotes out doesn't *seem* to matter but I know it would bite me eventually. When would it bite me? And: " /#%^ " ... it seems to me this is belaboring something simple. Do we not have an operator that says (in English): If string A is a substring of B, then return B, else return nothing. No anchors, no negation. Inventing '!!' as my operator (yes I know it won't work but just for discussion): cc=( "${cc[@]!!$~zsh_case${filter}}" ) One operator instead of four. Actually, in such a construction the anchors would say: ... furthermore the substring must start at the beginning of the element: cc=( "${cc[@]!!#$~zsh_case${filter}}" ) ... or must end at the end of the element: cc=( "${cc[@]!!%$~zsh_case${filter}}" ) ... This wouldn't be a fancy substitution so much as a truth test with nulling of 'false'. Dunno, but it seems like a simple thing and one of the first things a shell might be able to do. Instead what we seem to have is a powerful operator that must then be dumbed down. Not important, but if anyone is interested. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-15 14:17 ` Belaboring substitution syntax Ray Andrews @ 2022-11-16 1:49 ` Bart Schaefer 2022-11-16 2:54 ` Ray Andrews 2022-11-16 10:32 ` Roman Perepelitsa 0 siblings, 2 replies; 39+ messages in thread From: Bart Schaefer @ 2022-11-16 1:49 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Tue, Nov 15, 2022 at 6:18 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > I sorta get that '[@]' is saying: "process this array line by line" thus preserving array indexes. I'm not sure about the quotes. This follows the same rules as $@. If you write "${array[@]}" with the quotes, you get each element of the array separately quoted. This often doesn't matter in zsh but always matters in other shells or when SH_WORD_SPLIT is enabled in zsh. BTW you need to stop thinking of these as "lines" -- line breaks have nothing to do with it. Conversely if you write "${array}" or ${array[*]}" either one with the quotes, you get the entire array joined into a single string. > and sometimes the quotes seem to protect stuff from expansion or interpretation: Quotes ALWAYS protect SOMETHING from expansion or interpretation, unless you start throwing other things in there such as eval. WHAT is protected differs: Double quotes allow ${param} and $(process) and $((math)) replacements but protect syntax tokens and glob patterns and whitespace; single quotes protect pretty much everything. > In my case, leaving the quotes out doesn't *seem* to matter but I know it would bite me eventually. When would it bite me? In the specific example in this thread, zsh's default array behavior (no_SH_WORD_SPLIT) is sufficient, but if you later enclose that or a similar construct in a deeper context, yes, you might be bitten. > Do we not have an operator that says (in English): If string A is a substring of B, then return B, else return nothing. Your trouble is the definition of "nothing." ${B:#*A*} does that, but in your example here, you don't actually want "nothing", you want "the empty string" which is still something. In fact the example in question is "if A is NOT a substring of B then return B, else return the empty string." So we have this: Do a replacement on every element of $cc is ${cc[@]/...} Replacement must start at beginning of element ${cc[@]/#...} Replacement must also end at end of element ${cc[@]/#%...} Use $zsh_case as a pattern is $~zsh_case Match that pattern anywhere with $filter is *$~zsh_case${filter}* Match NOT that whole pattern is ^*$~zsh_case${filter}* Put it all together: ${cc[@]/#%^*$~zsh_case${filter}* Replace all that with the empty string is just close the brace ${cc[@]/#%^*$~zsh_case${filter}*} ... and then the double-quotes for safety. About the only thing your magical operator could remove is putting *...* around the pattern to mean "is a substring". ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 1:49 ` Bart Schaefer @ 2022-11-16 2:54 ` Ray Andrews 2022-11-16 6:26 ` Bart Schaefer 2022-11-16 10:32 ` Roman Perepelitsa 1 sibling, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-16 2:54 UTC (permalink / raw) To: zsh-users On 2022-11-15 17:49, Bart Schaefer wrote: > BTW you need to stop thinking of these as "lines" -- line breaks have > nothing to do with it. Because I've never had an element that was more than one line I tend to say 'lines' but I know abstractly what you're saying. I'll crash into the issue eventually and I'll be ready for it. > Conversely if you write "${array}" or ${array[*]}" either one with the > quotes, you get the entire array joined into a single string. Right, that's quotes doing joining which I expect. > Quotes ALWAYS protect SOMETHING from expansion or interpretation, > unless you start throwing other things in there such as eval. WHAT is > protected differs: Double quotes allow ${param} and $(process) and > $((math)) replacements but protect syntax tokens and glob patterns and > whitespace; single quotes protect pretty much everything. Yeah, I get all that. There are times when I want to protect but not join tho and it gets confusing. > In the specific example in this thread, zsh's default array behavior > (no_SH_WORD_SPLIT) is sufficient, but if you later enclose that or a > similar construct in a deeper context, yes, you might be bitten. I'll stay safe. > Your trouble is the definition of "nothing." ${B:#*A*} does that, but > in your example here, you don't actually want "nothing", you want "the > empty string" which is still something. Quite so, rather sloppy of me to say 'nothing', I know better. > About the only thing your magical operator could remove is putting > *...* around the pattern to mean "is a substring". > Well no, I *define* my operator to do just as I said (except that I should have said 'empty string'). All that puzzles me is that it's not already available. Mind, functionality is added as needed so it's sufficient to just say that nobody has much wanted such a thing -- which is not debatable. It's a fact on the ground that my operator doesn't exist ergo it's not been in demand and that's that. So long is my functionality is achievable the rest is just musing. Still I'd have expected it to be one of the earlier operators because it's the simplest case. Nevermind. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 2:54 ` Ray Andrews @ 2022-11-16 6:26 ` Bart Schaefer 2022-11-16 14:08 ` Ray Andrews 2022-11-16 20:46 ` Ray Andrews 0 siblings, 2 replies; 39+ messages in thread From: Bart Schaefer @ 2022-11-16 6:26 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Tue, Nov 15, 2022 at 6:54 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > There are times when I want to protect but not > join tho and it gets confusing. That's almost always the instance in which you want to use "${array[@]}" or the almost-equivalent "${(@)array}". The difference is that you can [sometimes must] use (@) on a nested expansion "${(@)${somethingthatcreatesanarray}}". ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 6:26 ` Bart Schaefer @ 2022-11-16 14:08 ` Ray Andrews 2022-11-16 14:13 ` Roman Perepelitsa 2022-11-16 20:46 ` Ray Andrews 1 sibling, 1 reply; 39+ messages in thread From: Ray Andrews @ 2022-11-16 14:08 UTC (permalink / raw) To: zsh-users On 2022-11-15 22:26, Bart Schaefer wrote: > > That's almost always the instance in which you want to use > "${array[@]}" or the almost-equivalent "${(@)array}". The difference > is that you can [sometimes must] use (@) on a nested expansion > "${(@)${somethingthatcreatesanarray}}". Sheesh, that's a new one again. I'll add that to my list of potential expand/protect/join/split/slice/don't-slice/compact/don't-compact candidate syntaxes. How you guys can possibly parse all this is too scary to even think about. Still: "${array[@]}" ... Read: protect the elements of this array, do any expansions within them, but do NOT combine them ?? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 14:08 ` Ray Andrews @ 2022-11-16 14:13 ` Roman Perepelitsa 2022-11-17 2:31 ` Bart Schaefer 0 siblings, 1 reply; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-16 14:13 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Wed, Nov 16, 2022 at 3:09 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > "${array[@]}" ... Read: protect the elements of this array, do any expansions within them, but do NOT combine them ?? No, this just expands the array to all its elements. If you drop the quotes, then it's a more complex thing. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 14:13 ` Roman Perepelitsa @ 2022-11-17 2:31 ` Bart Schaefer 2022-11-17 8:59 ` Roman Perepelitsa 0 siblings, 1 reply; 39+ messages in thread From: Bart Schaefer @ 2022-11-17 2:31 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Ray Andrews, zsh-users On Wed, Nov 16, 2022 at 6:15 AM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > On Wed, Nov 16, 2022 at 3:09 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > > "${array[@]}" ... Read: protect the elements of this array, do any expansions within them, but do NOT combine them ?? > > No, this just expands the array to all its elements. In the base cases, you can think of it as "if I can't see it, nothing happens to it." The exceptions only occur when you start adding parameter flags like ${(e)array[@]}. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-17 2:31 ` Bart Schaefer @ 2022-11-17 8:59 ` Roman Perepelitsa 2022-11-17 16:02 ` Ray Andrews 0 siblings, 1 reply; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-17 8:59 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Thu, Nov 17, 2022 at 3:32 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Wed, Nov 16, 2022 at 6:15 AM Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > > > On Wed, Nov 16, 2022 at 3:09 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > > > > "${array[@]}" ... Read: protect the elements of this array, do any expansions within them, but do NOT combine them ?? > > > > No, this just expands the array to all its elements. > > In the base cases, you can think of it as "if I can't see it, nothing > happens to it." The exceptions only occur when you start adding > parameter flags like ${(e)array[@]}. If I didn't know that ${array[@]} without quotes does not in general expand to the array's elements, I could be confused by this exchange, so I'll post some examples for Ray's benefit. This does nothing (the array's content is unchanged): array=("${array[@]}") This may change the content of the array: array=(${array[@]}) The content of the array is changed by this statement in two ways: 1. All empty elements are removed. 2. If sh_word_split is set, elements of the array are split on $IFS. To demonstrate (1): % () { emulate -L zsh local array=('' 'foo bar') typeset -p array array=(${array[@]}) typeset -p array } typeset -a array=( '' 'foo bar' ) typeset -a array=( 'foo bar' ) To demonstrate (2): % () { emulate -L zsh -o sh_word_split local array=('' 'foo bar') typeset -a array=( 'foo bar' ) array=(${array[@]}) typeset -p array } typeset -a array=( '' 'foo bar' ) typeset -a array=( foo bar ) In short, "${array[@]}" expands to array elements just like "$scalar" expands to the scalar's value. Versions without quotes are more complex, for they may transform the value in various ways. Additionally, unless ksh_arrays is set (it's unset by default), these two are equivalent: "${array[@]}" "${(@)array}" And these four are equivalent: ${array[@]} ${(@)array} ${array} $array Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-17 8:59 ` Roman Perepelitsa @ 2022-11-17 16:02 ` Ray Andrews 0 siblings, 0 replies; 39+ messages in thread From: Ray Andrews @ 2022-11-17 16:02 UTC (permalink / raw) To: zsh-users On 2022-11-17 00:59, Roman Perepelitsa wrote: > ... > And these four are equivalent: > > ${array[@]} > ${(@)array} > ${array} > $array > > Roman. Thanks, that's what I call quality explanation, I'm going to save that whole post to my cheat sheet and work it over at length. 2/3 of my own difficulties here involve all this splitting/joining stuff. Mostly because I use Sebastian's n_list() quite a bit and it demands lines/elements for input, with blank lines and spaces in filenames protected. The construction that seems robust is like this: n_list "${array[@]}" ... for the reasons you mention. A useful document would be the Unabridged Guide to Zsh Arrays (their splitting, splicing, slicing and dicing, with protections and without, with all flags explained and specimens of every possible syntax and when you'd want to use them). I know it's far too late in the game to even think about fundamental changes, but if we had to do it all over again I'd advocate for a single universal expansion grammar: ${(CONTROL) FIELD / FIELD / FIELD } No '//' '##' '%%' or any of that. '/' is the universal separator, and what is done to the fields is entirely explained within the parenthesis. No more worries about special characters except '/' and maybe " " and ' ' and backslash cuz those expansion controls are robust. Within the parenthesis there are zero worries about literals, it's 100% operators so the syntax-space is unlimited. Within the fields there are zero operators (except quote expansions) so parsing becomes vastly simpler. ${(S:a!$%&@N/(xx^)**/*<>) ${array} / ${filter} } ... what's in the () explains exactly what is to be done vis a vis the two fields ... or more. ${(VERBS) NOUNS / NOUNS / NOUNS } ${(PREDICATES) SUBJECTS } ... that's the way a grammar should look. Basically 'flags' do everything and verbs and nouns are never intermingled. That's the reason glob qualifiers are so stinking powerful, cuz within the parenthesis their is nothing one might not achieve. Nevermind. :-) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 6:26 ` Bart Schaefer 2022-11-16 14:08 ` Ray Andrews @ 2022-11-16 20:46 ` Ray Andrews 1 sibling, 0 replies; 39+ messages in thread From: Ray Andrews @ 2022-11-16 20:46 UTC (permalink / raw) To: zsh-users On 2022-11-15 22:26, Bart Schaefer wrote: > "${(@)${somethingthatcreatesanarray}}". Speak of the devil and he appears: a guy on StackExchange just offered this for my 'keep erased lines' issue: remnant=( "${(@M)remnant##*$~zsh_case${searchstring[ee]}*}" ) ... (name off the array was 'cc' previously) but this seems to be about approximately exactly my imaginary operator, no? '##', which I understand, throw in the '(@M)' which is probably not that hard to understand, so unless I hear different, it seems to produce identical results to the more belabored form: remnant=( "${remnant[@]/#%^*$~zsh_case${searchstring[ee]}*}" ) ... so thereyago. Two operators shorter. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Belaboring substitution syntax 2022-11-16 1:49 ` Bart Schaefer 2022-11-16 2:54 ` Ray Andrews @ 2022-11-16 10:32 ` Roman Perepelitsa 1 sibling, 0 replies; 39+ messages in thread From: Roman Perepelitsa @ 2022-11-16 10:32 UTC (permalink / raw) To: Bart Schaefer; +Cc: Ray Andrews, zsh-users On Wed, Nov 16, 2022 at 2:50 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Tue, Nov 15, 2022 at 6:18 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > > In my case, leaving the quotes out doesn't *seem* to matter but I know it would bite me eventually. When would it bite me? > > In the specific example in this thread, zsh's default array behavior > (no_SH_WORD_SPLIT) is sufficient, but if you later enclose that or a > similar construct in a deeper context, yes, you might be bitten. Without the quotes empty elements will be dropped. Ray wants ${#cc} to stay unchanged, so quotes are required. Roman. ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2022-11-17 16:03 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-10 0:43 coloring substitution seems to eat next line Ray Andrews 2022-11-10 8:02 ` Roman Perepelitsa 2022-11-10 18:25 ` Ray Andrews 2022-11-10 18:36 ` Roman Perepelitsa 2022-11-10 18:45 ` Ray Andrews 2022-11-10 18:54 ` Bart Schaefer 2022-11-10 19:28 ` Ray Andrews 2022-11-10 20:22 ` Bart Schaefer 2022-11-10 21:42 ` Ray Andrews 2022-11-10 21:51 ` Roman Perepelitsa 2022-11-11 17:24 ` Ray Andrews 2022-11-10 22:47 ` Bart Schaefer 2022-11-10 23:07 ` Ray Andrews 2022-11-10 23:27 ` Bart Schaefer 2022-11-11 15:00 ` Ray Andrews 2022-11-11 18:15 ` Bart Schaefer 2022-11-11 18:50 ` Ray Andrews 2022-11-11 19:25 ` Bart Schaefer 2022-11-11 21:26 ` Ray Andrews 2022-11-12 4:24 ` Bart Schaefer 2022-11-12 14:03 ` Ray Andrews 2022-11-13 15:09 ` Ray Andrews 2022-11-14 14:12 ` Roman Perepelitsa 2022-11-14 17:08 ` Ray Andrews 2022-11-14 17:12 ` Roman Perepelitsa 2022-11-14 18:58 ` Ray Andrews 2022-11-14 20:00 ` Bart Schaefer 2022-11-14 23:25 ` Ray Andrews 2022-11-15 14:17 ` Belaboring substitution syntax Ray Andrews 2022-11-16 1:49 ` Bart Schaefer 2022-11-16 2:54 ` Ray Andrews 2022-11-16 6:26 ` Bart Schaefer 2022-11-16 14:08 ` Ray Andrews 2022-11-16 14:13 ` Roman Perepelitsa 2022-11-17 2:31 ` Bart Schaefer 2022-11-17 8:59 ` Roman Perepelitsa 2022-11-17 16:02 ` Ray Andrews 2022-11-16 20:46 ` Ray Andrews 2022-11-16 10:32 ` Roman Perepelitsa
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).