[Feature Request] Adding option to support triple quotes

[Feature Request] Adding option to support triple quotes

[Aryn Starr]

Adding an option to zsh to support triple quotes (TRIPLE_QUOTES) would make possible much more readable code.
We can have double triple quotes that support `$` interpolation, and triple single quotes that just take raw strings. If it’s possible, we can even make it customizable for the user to set the number of quotes needed to activate this mode; I don’t imagine any one is using 4 consecutive quotes in their current code.
These little conveniences go a long way to make zsh a stronger competitor to scripting languages like Python. zsh is optimized for filesystem and process programming, which necessates some compromises, but things like triple quotes can be introduced to the current syntax with no problem, I think.

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

[Mikael Magnusson]

On 8/13/19, Aryn Starr <whereislelouch@icloud.com> wrote:
> Adding an option to zsh to support triple quotes (TRIPLE_QUOTES) would make
> possible much more readable code.
> We can have double triple quotes that support `$` interpolation, and triple
> single quotes that just take raw strings. If it’s possible, we can even make
> it customizable for the user to set the number of quotes needed to activate
> this mode; I don’t imagine any one is using 4 consecutive quotes in their
> current code.

You are unfortunately wrong about this;
% echo it''''s used by RC_QUOTES
it's used by RC_QUOTES


-- 
Mikael Magnusson

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

[Daniel Shahaf]

Aryn Starr wrote on Tue, 13 Aug 2019 06:08 +00:00:
> Adding an option to zsh to support triple quotes (TRIPLE_QUOTES) would 
> make possible much more readable code.
> We can have double triple quotes that support `$` interpolation, and 
> triple single quotes that just take raw strings.

What would be the difference to ordinary «'…'» and «"…"» string
literals?  They can already be multiline.

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

[Aryn Starr]

The tripe single quotes can have single quotes in them, and the triple double quotes can have double quotes.
It’s useful for normal English interpolation:
“””I’m going to kill process “${some_process}.”
     Proceed? (Y/n)”””
It’s useful for regexes:
[[ “$sth” =~ ‘’’ “\w+”=‘?(\d+)’? ‘’’ ]]
It’s useful for putting code in strings, which is extremely useful for macros, code generators, evaling code of other languages (node -e, python -c, etc):
“”” $var_name=“\$$var_value”
“””

There are quite a few “...”’”’”...” and the like already in my code, and they are make the code unreadable and ugly. 

> On Aug 13, 2019, at 8:58 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> Aryn Starr wrote on Tue, 13 Aug 2019 06:08 +00:00:
>> Adding an option to zsh to support triple quotes (TRIPLE_QUOTES) would 
>> make possible much more readable code.
>> We can have double triple quotes that support `$` interpolation, and 
>> triple single quotes that just take raw strings.
> 
> What would be the difference to ordinary «'…'» and «"…"» string
> literals?  They can already be multiline.

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

[Aryn Starr]

Well, it feels much more natural (and readable) to do an `echo it\'s used by RC_QUOTES` than put 4 single quotes together, but your point is taken. I don’t use this option, and I’m proposing the triple quotes as two new options (for triple single quotes and triple double quotes).
The triple quotes are a well-known, easy-to-use, copy-paste-friendly, and readable construct. They certainly can help make the shell more useable for a lot of us.

> On Aug 13, 2019, at 1:36 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> 
> echo it''''s used by RC_QUOTES

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

[Stephane Chazelas]

2019-08-13 10:36:53 +0430, Aryn Starr:
> Adding an option to zsh to support triple quotes
> (TRIPLE_QUOTES) would make possible much more readable code.
[...]

We could also implement mksh's "$(<<'EOF'
arbitrary text that mustn't end in empty lines
EOF
)"

That already works in zsh, but is not optimised like in mksh as
it does "$(cat <<'EOF'
arbitrary text that mustn't end in empty lines
EOF
)" while mksh treats it specially as effectively a kind of
quotes.

mksh also supports $(<<'EOF'
foo
EOF)

(though that's probably not POSIX).

See also perl's q(...) and qq(...) that are more compatible with
the shell syntax than those python '''/""".

See:

$ a="'"; print -r ${(qq)a}
''\'''

-- 
Stephane

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

[Aryn Starr]

That EOF solution is good if there is a lot of text, but for short snippets, it’s too many characters to type. Completely against the shell’s spirit of arcane brevity. :))
I also thought of a (kind of) new application for the triple quotes. I think it’ll enable a lot more functions like this:
cc() python -c "from math import *; print($*);"
Since we’ll be able to easily write the target language’s code in our shell, with minimal typing.

> On Aug 14, 2019, at 2:24 PM, Stephane Chazelas <stephane.chazelas@gmail.com> wrote:
> 
> 2019-08-13 10:36:53 +0430, Aryn Starr:
>> Adding an option to zsh to support triple quotes
>> (TRIPLE_QUOTES) would make possible much more readable code.
> [...]
> 
> We could also implement mksh's "$(<<'EOF'
> arbitrary text that mustn't end in empty lines
> EOF
> )"
> 
> That already works in zsh, but is not optimised like in mksh as
> it does "$(cat <<'EOF'
> arbitrary text that mustn't end in empty lines
> EOF
> )" while mksh treats it specially as effectively a kind of
> quotes.
> 
> mksh also supports $(<<'EOF'
> foo
> EOF)
> 
> (though that's probably not POSIX).
> 
> See also perl's q(...) and qq(...) that are more compatible with
> the shell syntax than those python '''/""".
> 
> See:
> 
> $ a="'"; print -r ${(qq)a}
> ''\'''
> 
> -- 
> Stephane
> 
> 
> 
> 

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

[Daniel Shahaf]

Aryn Starr wrote on Thu, 15 Aug 2019 14:29 +00:00:
> That EOF solution is good if there is a lot of text, but for short 
> snippets, it’s too many characters to type. Completely against the 
> shell’s spirit of arcane brevity. :))
> I also thought of a (kind of) new application for the triple quotes. I 
> think it’ll enable a lot more functions like this:
> cc() python -c "from math import *; print($*);"
> Since we’ll be able to easily write the target language’s code in our 
> shell, with minimal typing.

I don't really understand your example, but I did want to point out this:

[[[
#!/usr/bin/env zsh
: '''.'; /sbin/shutdown -h now; : '.'''
]]]

With TRIPLE_QUOTES, it's harmless.  If TRIPLE_QUOTES is unset or doesn't
exist (older version of zsh), it executes an external command.  (Just
imagine it said «rm -rf /» there.)

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

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

[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

[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

[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.'''