Re: [Feature Request] Adding option to support triple quotes

Re: [Feature Request] Adding option to support triple quotes

[Aryn Starr]

The only preventive measure I can think of is to tell users to check zsh’s version at the very start and exit noisily ... 

> On Aug 15, 2019, at 8:42 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Daniel Shahaf wrote on Thu, 15 Aug 2019 16:08 +00:00:
>> Aryn Starr wrote on Thu, 15 Aug 2019 16:05 +00:00:
>>> That cc function is a kind of calculator. Like 
>>> https://github.com/arzzen/calc.plugin.zsh, but better.
>>> That example of yours is indeed worthy of attention ... Can you think 
>>> of possible remedies? I’m thinking about preventing mistakes though, 
>>> not malicious code.
>> 
>> Let's discuss this on list.
> 
> Here's a quick example, not very inspired but valid:
> 
> echo '''The installation hasn't finished; rm -rf / must be run after the next reboot; should you forget that step, you'll have to restart the whole installation from square one.'''

Re: [Feature Request] Adding option to support triple quotes

[Bart Schaefer]

On Thu, Aug 15, 2019 at 6:13 PM Aryn Starr <whereislelouch@icloud.com> wrote:
>
> The only preventive measure I can think of is to tell users to check zsh’s version at the very start and exit noisily ...

This right here is exactly why we have traditionally never built new
syntax that is an ambiguous superset of an existing syntax.  If it's
not a syntax error in a version of the interpreter that doesn't
support it, it shouldn't be there at all.  I've been staying out of
this discussion because it's all been theoretical so far, but tripling
quotation marks is a nonstarter for me.

A good relatively recent example of this is that you're allowed to write

{ stuff } always
{ other stuff }

but not

{ stuff }
always { other stuff }

So if you really want to make progress with this, start looking for
something more akin to perl's q{} and qq{} as already mentioned.  The
difficult part is that the shell language uses "lexical pasting"
instead of a concatenation operator, so finding something that doesn't
already have another meaning is tricky.

One way around this is to introduce a new keyword.  A candidate that
occurs to me is "let", because it's already a builtin and it's been
decades since I saw anybody use it.  (Does anyone know of a program
named "let" with which this would collide, and that isn't already
basically unusable in zsh because of the builtin?)  The "let" builtin
expects math expressions, which already have a limited syntax, so it's
easier to find something that would break in an old shell.  For
example, a math expression can't begin with a colon, so that could
introduce a new quoting token.

This also means you can turn the syntax off with "disable" if you
don't want it, we don't have to create another setopt.

Qualification:  I'm not sure the following suggestions would actually
error soon enough to prevent some downstream syntax from being
interpreted/executed, so this probably still needs more thought.

Nevertheless you could have (just throwing out examples)

let :"( this is like a triple double quoted argument to the ":" builtin )
let :'{ similarly a triple single quote , and look we can choose our delimiter }
let foo=:"{{{ assign to foo, and quote } and { by having the delimiter
repeat }}}

There are other characters that can't begin a math expression that
could be given other meanings, such as ^ and @ and %

let list=@{ :"( string one ) :'< string two > :^[ string three ] }   #
no, I do not have any idea what :^ would mean ...
let hash=%{ key=:"( value ) }

Re: [Feature Request] Adding option to support triple quotes

[Stephane Chazelas]

2019-08-16 22:31:11 -0700, Bart Schaefer:
[...]
> So if you really want to make progress with this, start looking for
> something more akin to perl's q{} and qq{} as already mentioned.
[...]

q{} would be a non-starter since it's already valid syntax.

q(...)    for '...'
qq(...)   for "..."
qqq(...)  for $'...'
qqqq(...) and more q's reserved for future extensions like
          ksh93's $"..."

may be workable. (and \qq(...) or 'q'q(...) would be a literal q
followed by q(...)). 

perl allows \( and \) to escape ( and ) (and as a result \\ to
escape \) inside even the q(...) form, I'm not sure I like that:

$ perl -le 'print q( \\ \(\) () )'
 \ () ()

'...' can quote anything that doesn't contain '. q(...) could
quote anything except unmatched (...) pairs.

I'm sure everyone will have wished for a kind of quotes (à la
TCL {...} or perl q(...)) that can nest when writing things
like:

ssh host 'find . -exec sh -c '\''for i do sed '\'\\\'\'s/... '

Which you wished you could write:

ssh host q(find . -exec zsh -c q(for i do sed q(s...)...) zsh {} +)

That's the same kind of reason we got $(...) to replace `...`

On a related note, I really wish the glob*(e'(code $(...))')
worked, as in the code that looks for the closing ) for the e
glob qualifier would find the matching ")" as opposed to the
first one (same in the s/j... parameter expansion flags, etc.)

-- 
Stephane

Re: [Feature Request] Adding option to support triple quotes

[Stephane Chazelas]

2019-08-17 07:30:09 +0100, Stephane Chazelas:
> 2019-08-16 22:31:11 -0700, Bart Schaefer:
> [...]
> > So if you really want to make progress with this, start looking for
> > something more akin to perl's q{} and qq{} as already mentioned.
> [...]
> 
> q{} would be a non-starter since it's already valid syntax.
> 
> q(...)    for '...'
> qq(...)   for "..."
> qqq(...)  for $'...'
> qqqq(...) and more q's reserved for future extensions like
>           ksh93's $"..."
> 
> may be workable
[...]

Sorry, scrap that, I overlooked that it clashes with

q() { ...; }

And

rm *.faq(.bak|'~')

There's also ruby's %(...) which is less likely to clash in
practice.

-- 
Stephane

Re: [Feature Request] Adding option to support triple quotes

[Mikael Magnusson]

On 8/17/19, Stephane Chazelas <stephane.chazelas@gmail.com> wrote:
>
> On a related note, I really wish the glob*(e'(code $(...))')
> worked, as in the code that looks for the closing ) for the e
> glob qualifier would find the matching ")" as opposed to the
> first one (same in the s/j... parameter expansion flags, etc.)

You probably want glob*(e*'code $(...)'*), an unquoted * will never
match a quoted *, eg:
% echo .(e*'touch \*hi; reply=("*"*)'*)
*hi

-- 
Mikael Magnusson

Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes)

[Stephane Chazelas]

2019-08-18 06:24:32 +0200, Mikael Magnusson:
> On 8/17/19, Stephane Chazelas <stephane.chazelas@gmail.com> wrote:
> >
> > On a related note, I really wish the glob*(e'(code $(...))')
> > worked, as in the code that looks for the closing ) for the e
> > glob qualifier would find the matching ")" as opposed to the
> > first one (same in the s/j... parameter expansion flags, etc.)
> 
> You probably want glob*(e*'code $(...)'*), an unquoted * will never
> match a quoted *, eg:
> % echo .(e*'touch \*hi; reply=("*"*)'*)
> *hi
[...]

Thanks,

I'm not sure why it works of why it doesn't work with other
characters (it seems to work with ? as well though), but I can
confirm it does and it's very handy indeed.

Are we guaranteed it will stay that way?

I've just realised we can also do:

echo .(e'
 single-line code
')

BTW, this doesn't look right:

$ (echo a(eé'echo é'é)) |& sed -n l
zsh: unknown file attribute: ^\003$

-- 
Stephane

Re: Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes)

[Bart Schaefer]

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

On Sun, Aug 18, 2019, 1:59 PM Stephane Chazelas <stephane.chazelas@gmail.com>
wrote:

> Are we guaranteed it will stay that way?
>

Yes.

$ (echo a(eé'echo é'é)) |& sed -n l
> zsh: unknown file attribute: ^\003$
>

You can't use multibyte characters as the delimiter there.

>

Re: Matching delimiters for the "e" glob qualifier

[Stephane Chazelas]

2019-08-18 14:55:09 -0500, Bart Schaefer:
> On Sun, Aug 18, 2019, 1:59 PM Stephane Chazelas <stephane.chazelas@gmail.com>
> wrote:
> 
> > Are we guaranteed it will stay that way?
> >
> 
> Yes.

Thanks. I found that it also works for [...] (which is probably
the one I'll settle on for my own use) and the extended glob
ones (#, ^, ~, the latter only with #q when using extendedglob),
but also "-"!

Which harks back to 
https://www.zsh.org/mla/workers/2019/msg00465.html

Which was also asking (among other things) about the special
treatment of "-" in

$ string=- pattern='\-'; [[ $string = $~pattern ]] && echo yes
yes

(I had no feedback on that one at the time).

Here maybe zsh could extend it to all characters as doing it for
only *?[]^~#- and not others (I've not tested all possible ones)
seems a bit arbitrary.


> $ (echo a(eé'echo é'é)) |& sed -n l
> > zsh: unknown file attribute: ^\003$
> >
> 
> You can't use multibyte characters as the delimiter there.
[...]

Sorry for causing confusion there. UTF-8 é as delimiter is fine
there.

$ zsh -c 'echo /(eé"echo x"é/)'
x
/

The issue I wanted to raise was the bogus error message when
using é as a glob qualifier. It can be reproduced without the
"e" qualifier:

$ zsh -c 'echo /(é)' |& sed -n l
zsh:1: unknown file attribute: ^\003$

-- 
Stephane