Re: first adventures

Re: first adventures

[Ray Andrews]

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.

Re: first adventures

[Peter Stephenson]

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/

Re: first adventures

[Ray Andrews]

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?

Re: first adventures

[Mikael Magnusson]

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

Re: first adventures

[Ray Andrews]

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

Re: first adventures

[Peter Stephenson]

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

Re: first adventures

[Ray Andrews]

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
>

Re: first adventures

[Peter Stephenson]

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

Re: first adventures

[Ray Andrews]

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
>