* Re: first adventures [not found] ` <141030195906.ZM30057@torch.brasslantern.com> @ 2014-10-31 18:10 ` Ray Andrews 2014-10-31 19:59 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Ray Andrews @ 2014-10-31 18:10 UTC (permalink / raw) To: Zsh Users On 10/30/2014 07:59 PM, Bart Schaefer wrote: Bart, > (We've drifted back to stuff that would be fine on zsh-users now ...) The power and the glory. typeset -g TLC TRAPDEBUG() { (( $#functrace == 1 )) && TLC=(${(z)ZSH_DEBUG_CMD}) } Years of thrashing that issue, and it turns out to be dead simple. I take it that 'TRAPDEBUG' AND 'ZSH_DEBUG_CMD' are hard-coded names? One further question, I tried the ' (Q) ' flag to remove quotes, and it works as advertised, however trying to print individual array elements fails whereas they print fine with the ' (z) 'flag. Why is that? Fixable? Not important tho, I'm just curious. print -ru2 "two: $TLC[2]" << No luck if ' (Q) ' flag is used. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-10-31 18:10 ` first adventures Ray Andrews @ 2014-10-31 19:59 ` Peter Stephenson 2014-11-01 4:26 ` Ray Andrews 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2014-10-31 19:59 UTC (permalink / raw) To: Zsh Users On Fri, 31 Oct 2014 11:10:54 -0700 Ray Andrews <rayandrews@eastlink.ca> wrote: > One further question, I tried the ' (Q) ' flag to remove quotes, and it > works > as advertised, however trying to print individual array elements fails > whereas > they print fine with the ' (z) 'flag. Why is that? They're doing different things. (Q) really does just remove quotes, it doesn't split things into elements. (z) splits things into elements using the shell's normal rules, but doesn't remove quotes. You might be running up against the problem that if you combine them in the obvious way it doesn't do what you want because the splitting happens too late. That's a deliberate rule, it's just not convenient in this particular case --- there are so many cases for parameter expansion it's quite impossible to get them all to work in the simplest way. So starting with % print -rl ${line} 'one two' "buckle my shoe" three\ four (printing the raw string arguments one per line) you get % print -rl ${(Qz)line} one two buckle my shoe three four which isn't what you want. But you can use a nested expansion to get the quotes removed after zplitting: % print -rl ${(Q)${(z)line}} one two buckle my shoe three four Finally, you've got exactly the right set of arguments as simple strings. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-10-31 19:59 ` Peter Stephenson @ 2014-11-01 4:26 ` Ray Andrews 2014-11-01 7:51 ` Mikael Magnusson 0 siblings, 1 reply; 9+ messages in thread From: Ray Andrews @ 2014-11-01 4:26 UTC (permalink / raw) To: zsh-users On 10/31/2014 12:59 PM, Peter Stephenson wrote: Strange, I'm getting double posts both sending and receiving. > On Fri, 31 Oct 2014 11:10:54 -0700 > Ray Andrews <rayandrews@eastlink.ca> wrote: >> One further question, I tried the ' (Q) ' flag to remove quotes, and it >> works >> as advertised, however trying to print individual array elements fails >> whereas >> they print fine with the ' (z) 'flag. Why is that? > They're doing different things. (Q) really does just remove quotes, it > doesn't split things into elements. (z) splits things into elements > using the shell's normal rules, but doesn't remove quotes. Right. Somehow I assumed the breakdown as well, tho there's no reason I should have. > You might be running up against the problem that if you combine them in > the obvious way it doesn't do what you want because the splitting > happens too late. That's a deliberate rule, it's just not convenient in > this particular case --- there are so many cases for parameter expansion > it's quite impossible to get them all to work in the simplest way. Sure. I find it unbelievable that anyone can keep any sort of handle on this at all. So much power, but is it even possible to keep a rigid syntax? > % print -rl ${(Q)${(z)line}} > one two > buckle my shoe > three four > > Finally, you've got exactly the right set of arguments as simple strings. Outstanding. One might wish for something simpler, but if you can nest those things like that, then you could probably get it to do your taxes. zsh seems to always trade away simplicity for power, but the power is indeed awesome. But there is always a gotcha: Using (( $#functrace == 1 )) && TLC=(${(z)ZSH_DEBUG_CMD}) $ test2 'one \n' "two \n" buckle \n My unexpanded arguments were: test2 'one \n' "two \n" buckle \n ...and my arguments broken to an array: two: 'one \n' three: "two \n" four: buckle five: \n Using (( $#functrace == 1 )) && TLC=(${(Q)${(z)ZSH_DEBUG_CMD}}) } $ test 'one \n' "two \n" buckle \n My unexpanded arguments were: test2 one \n two \n buckle n ...and my arguments broken to an array: two: one \n three: two \n four: buckle five: n << Why does it remove the backslash? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-11-01 4:26 ` Ray Andrews @ 2014-11-01 7:51 ` Mikael Magnusson 2014-11-01 16:35 ` Ray Andrews 0 siblings, 1 reply; 9+ messages in thread From: Mikael Magnusson @ 2014-11-01 7:51 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users On Sat, Nov 1, 2014 at 5:26 AM, Ray Andrews <rayandrews@eastlink.ca> wrote: > On 10/31/2014 12:59 PM, Peter Stephenson wrote: > > Strange, I'm getting double posts both sending and receiving. >> >> On Fri, 31 Oct 2014 11:10:54 -0700 >> Ray Andrews <rayandrews@eastlink.ca> wrote: >>> >>> One further question, I tried the ' (Q) ' flag to remove quotes, and it >>> works >>> as advertised, however trying to print individual array elements fails >>> whereas >>> they print fine with the ' (z) 'flag. Why is that? >> >> They're doing different things. (Q) really does just remove quotes, it >> doesn't split things into elements. (z) splits things into elements >> using the shell's normal rules, but doesn't remove quotes. > > Right. Somehow I assumed the breakdown as well, tho there's no reason I > should have. [...] > Using > (( $#functrace == 1 )) && TLC=(${(Q)${(z)ZSH_DEBUG_CMD}}) > } > > $ test 'one \n' "two \n" buckle \n > My unexpanded arguments were: test2 one \n two \n buckle n > ...and my arguments broken to an array: > > two: one \n > three: two \n > four: buckle > five: n << Why does it remove the backslash? \n is the same as for example "n", which is one level of quoting, which (Q) removes. Note that \n is not special to the shell in any way other than being a quoted letter n. Many builtins parse the _string_ \n as a newline, but \n on the raw input line after parsing into separate arguments is not the string \n, but the string n. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-11-01 7:51 ` Mikael Magnusson @ 2014-11-01 16:35 ` Ray Andrews 2014-11-01 18:40 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Ray Andrews @ 2014-11-01 16:35 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Zsh Users On 11/01/2014 12:51 AM, Mikael Magnusson wrote: I got three copies of this, is that how things are supposed to work? > On Sat, Nov 1, 2014 at 5:26 AM, Ray Andrews <rayandrews@eastlink.ca> wrote: > \n is the same as for example "n", which is one level of quoting, > which (Q) removes. Note that \n is not special to the shell in any way > other than being a quoted letter n. Many builtins parse the _string_ > \n as a newline, but \n on the raw input line after parsing into > separate arguments is not the string \n, but the string n. I understand. You point out one of those little subtle errors that can foul things up. I was indeed thinking of ' \n ' as 'special' (newline of course), but it's special to echo and print NOT to the shell in general. But there are situations where I have to pass a literal ' \n ' to a command, so I was wanting it unmolested. Is there, or could/should there be some way of leaving builtin 'special' characters alone? But it's not important, the ' (z) ' method gives me the command back absolutely raw, even on Saturday, just as I want. And I can always ' \\n ' protect the thing by hand. Philosophically tho, it seems strange that zsh can prepare coffee in more ways than Starbucks, but getting a raw coffee bean is difficult. Thanks Mikael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-11-01 16:35 ` Ray Andrews @ 2014-11-01 18:40 ` Peter Stephenson 2014-11-01 20:24 ` Ray Andrews 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2014-11-01 18:40 UTC (permalink / raw) To: Zsh Users On Sat, 01 Nov 2014 09:35:49 -0700 Ray Andrews <rayandrews@eastlink.ca> wrote: > But there are > situations where I have to pass a literal ' \n ' to a command, so I was > wanting it unmolested. Is there, or > could/should there be some way of leaving builtin 'special' characters > alone? That's exactly what quoting is for. '\n' is probably the easiest way of doing it. Single quotes quote everything except single quotes (and with RC_QUOTES you can do that, too). > Philosophically tho, it seems strange that zsh can prepare coffee in > more ways than Starbucks, but getting a raw coffee bean is difficult. This isn't fair in this case. The character \ was picked to be a special character because it isn't commonly used in normal text. So it's special to the command line. You now need it to be special somewhere else *as well*, at a later stage, for something that also picked the backslash to be special for exactly the same reason. It's not surprising that takes a bit of doing. With your analogy, you're trying to put a coffee bean into a roaster and saying that you want it to emerge unscathed in such a way that it can be roast by something else after it emerges. If you want text not to be processed by the shell, the best way of doing that is to pass it via standard input and output rather than the command line, using "read -r" and "print -r". pws ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-11-01 18:40 ` Peter Stephenson @ 2014-11-01 20:24 ` Ray Andrews 2014-11-01 21:11 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Ray Andrews @ 2014-11-01 20:24 UTC (permalink / raw) To: zsh-users On 11/01/2014 11:40 AM, Peter Stephenson wrote: This isn't fair in this case. The character \ was picked to be a special character because it isn't commonly used in normal text. So it's special to the command line. You now need it to be special somewhere else *as well*, at a later stage, for something that also picked the backslash to be special for exactly the same reason. It's not surprising that takes a bit of doing. Yeah, I see that. Still, all those {( ) .... processors are arbitrary, tho useful, tools. One could, I suppose create new ones to do whatever one wanted, including stripping quotation marks while leaving the 'special' backslash pairs. But I understand the logic of (Q) now, and I'm happy with (z) anyway because quoted strings are naturally single arguments, and (z) leaves ' \n ' alone. But my thinking is anticipated by the ' -r ' switch, which recognizes the specialness of the ' \n ' family of escapes, so one could imagine other parts of the shell recognizing that, too. It would just 'harmonize' what print and read and echo do with what the shell itself might be able to provide, namely special treatment for \n \t \b , etc. if requested. > With your analogy, you're trying to put a coffee bean into a roaster and > saying that you want it to emerge unscathed in such a way that it can be roast by > something else after it emerges. I'd rather say that I'd like to be able look at the bean before it's roasted at all. Anyway, TRAPDEBUG seems to do exactly that, so my itch is scratched. > > If you want text not to be processed by the shell, the best way of doing > that is to pass it via standard input and output rather than the command > line, using "read -r" and "print -r". Can you give me an example of that, please? > pws > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-11-01 20:24 ` Ray Andrews @ 2014-11-01 21:11 ` Peter Stephenson 2014-11-01 23:23 ` Ray Andrews 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2014-11-01 21:11 UTC (permalink / raw) To: zsh-users On Sat, 01 Nov 2014 13:24:52 -0700 Ray Andrews <rayandrews@eastlink.ca> wrote: > > If you want text not to be processed by the shell, the best way of doing > > that is to pass it via standard input and output rather than the command > > line, using "read -r" and "print -r". > > Can you give me an example of that, please? It doesn't really fit in the case you're looking at. The point was more that if you had the choice, which you don't, and you had to pass raw chunks of text around you'd do things like read -r line < input print -r -- $line > output and not actually worry about what was in $line at all. Perhapse the real point is what you're looking at is an unusual case in that you've been passed a piece of raw shell input and you're thinking about what it would look like if it wasn't raw any more. This is hairy stuff that most people who consider themselves shell language gurus probably never have to think about --- extracting bits of semi-parsed chunks of input is something most people would do in a language like Lisp rather than a shell. So it's not surprising you're a bit bamboozled when you're coming to this out of nowhere. pws ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: first adventures 2014-11-01 21:11 ` Peter Stephenson @ 2014-11-01 23:23 ` Ray Andrews 0 siblings, 0 replies; 9+ messages in thread From: Ray Andrews @ 2014-11-01 23:23 UTC (permalink / raw) To: zsh-users On 11/01/2014 02:11 PM, Peter Stephenson wrote: > > Perhapse the real point is what you're looking at is an unusual case in > that you've been passed a piece of raw shell input and you're thinking > about what it would look like if it wasn't raw any more. This is hairy > stuff that most people who consider themselves shell language gurus > probably never have to think about --- extracting bits of semi-parsed > chunks of input is something most people would do in a language like > Lisp rather than a shell. So it's not surprising you're a bit > bamboozled when you're coming to this out of nowhere. Bamboozled ain't the half of it. But it's ok, what Bart showed me is quite satisfactory. I should spend less time speculating. But I wonder if anyone in the next generation of zsh users is going to be able to explain, or even understand half of this stuff. Sheesh, I thought that as a newbie, a good place to start looking at the code was where we first swallow a command line. But that was a long long time ago ;-) > pws > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-11-01 23:20 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <544D2D6F.8030505@eastlink.ca> [not found] ` <20141026175257.2611487b@pws-pc.ntlworld.com> [not found] ` <544FD6DD.7010806@eastlink.ca> [not found] ` <141028210510.ZM10784@torch.brasslantern.com> [not found] ` <54510A96.20009@eastlink.ca> [not found] ` <141029134624.ZM15681@torch.brasslantern.com> [not found] ` <545178DF.1040600@eastlink.ca> [not found] ` <141029210738.ZM15833@torch.brasslantern.com> [not found] ` <5452ED18.7070208@eastlink.ca> [not found] ` <141030195906.ZM30057@torch.brasslantern.com> 2014-10-31 18:10 ` first adventures Ray Andrews 2014-10-31 19:59 ` Peter Stephenson 2014-11-01 4:26 ` Ray Andrews 2014-11-01 7:51 ` Mikael Magnusson 2014-11-01 16:35 ` Ray Andrews 2014-11-01 18:40 ` Peter Stephenson 2014-11-01 20:24 ` Ray Andrews 2014-11-01 21:11 ` Peter Stephenson 2014-11-01 23:23 ` Ray Andrews
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).