Re: Odd behavior with various (q) array modifiers and non-printable characters (backspace, newline)

[Zach Riggle <zachriggle@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

Apologies for resurrecting this thread, but I wanted to revisit and thank
everybody for the help.

I ran into some issues where my
print-a-$-and-then-the-minally-quoted-version-of-this-array-of-scalars when
dealing with regex, due to "builtin echo" treating '\bfoo bar\b'
incorrectly.

I attempted a variety of things to fix the problem, but going back through
this thread really helped a bunch.  I had written additional code that
relied in builtin echo.  "command echo" and the issue is resolved.


On Sat, Aug 14, 2021 at 10:52 AM Daniel Shahaf <d.s@daniel.shahaf.name>
wrote:

> Lawrence Velázquez wrote on Wed, Aug 11, 2021 at 17:42:09 -0400:
> > On Wed, Aug 11, 2021, at 5:16 PM, Bart Schaefer wrote:
> > > You need to stop testing things with "echo".  The "echo" builtin
> > > interprets some backslash escapes itself, which will confuse you about
> > > what the quoting options have done.
> > >
> > > Repeat all your tests instead with
> > >   printf "%s\n" ${(q)...}
> > > and so on, and come back if you still have questions.
> >
> > Additionally, \b and \n are not interpreted in double quotes, so
> > your initial data does not actually contain BS or NL characters.
> ⋮
> > As per the QUOTING section of zshmisc(1):
> >
> >       Inside double quotes (""), parameter and command substitution
> >       occur, and `\' quotes the characters `\', ``', `"', `$',
> >       and the first character of $histchars (default `!').
>
> There are third-party plugins that implement syntax highlighting at the
> prompt (I happen to co-maintain one such plugin).  Those plugins are
> aware of the quoted docs section, so on input such as
> .
>     % foo "bar \n \\ \x"
> .
> they will correctly highlight only the «\\» as an escape sequence, and
> everything else as literals.
>

[-- Attachment #2: Type: text/html, Size: 2399 bytes --]