Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: indented heredocs
- X-seq: zsh-workers 40224
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Dave Yost <Dave@xxxxxxxx>
- Subject: Re: indented heredocs
- Date: Wed, 21 Dec 2016 14:10:37 -0800
- Cc: zsh workers <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=z0/pE27or5rH/TCRXX1FMVTXr6O3N3NWhdtNXYKE1tA=; b=lfrAj04Ea7wjgHJng++6vwv2vYyy1ibqvtSY+3mqW4OQwMynCAA7GFYOVTN+B4J6ET 8s8jP4J5qjdbrldmktRhzhmUIuxC9PiuOLlYxgBagXBoKht4vhRXjWhDRaIDH0IOgKsh LmlY3Cm48kDG+0q2hcm8fetbWJyfkjtrnMqEYGcDPmUCkMxrSqRTa/TBCllTKj7g6ILb hBU1b7b5AMpV9wQRRjSavqMhvuicDWbyiDWqT9Zp9yhVaNdLUCO1Lkn05+0ac9KLwREl byEnYDnCDvOHmzHZgQez3aCxjfvXzGzDgibgzggHhUozXwfLfXkFucbNTcHfQCXiuByS rGVw==
- In-reply-to: <CFA2339B-26F2-4104-AAD2-64852509286B@yost.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CFA2339B-26F2-4104-AAD2-64852509286B@yost.com>
On Wed, Dec 21, 2016 at 11:29 AM, Dave Yost <Dave@xxxxxxxx> wrote:
>
> Surely people have thought of this (Alternative 1):
>
> 0 Wed 10:53:53 ~
> 205 Z% cat <<xx
> foo
> bar
> xx
> foo
> bar
> 0 Wed 10:53:53 ~
> 206 Z%
>
> but shells don’t do that.
[...]
> I suggested this (Alternative 2), which [Bourne] liked:
>
> 0 Wed 10:53:53 ~
> 206 Z% cat \
> <<xx
> foo
> bar
> xx
> foo
> bar
> 0 Wed 10:54:10 ~
> 207 Z%
I'm not thrilled with this idea because it gives special semantics to
backslash-newline (as well as to leading spaces before "<<") which do
not currently exist. In existing syntax, backslash-newline can simply
be discarded without changing the meaning of the command line, I think
even before tokenization.
I would propose instead something similar (read on below) to this:
% cat <<-' xx'
foo
bar
xx
foo
bar
%
This explicitly quotes the leading space that is to be stripped, so
there is no parsing ambiguity, and it piggybacks on the existing <<-
syntax, merely changing the expected leading space from "all tabs" to
"the leading whitespace on the end marker".
> I don’t think that would help anything. If the parser doesn’t know how to do
> the new syntax with the existing << operator, you’ll get an error, and if the
> parser doesn’t know the new operator, you’ll get an error. Same difference.
It is a consideration that we might prefer that older shells choke on
the new syntax. I think having them choke by failing to find the end
marker is rather worse than having them choke by failing to recognize
the operator -- something that wrongly appears to be the end marker
might appear later in the script if we go your "Alternative 2" route.
Taken literally, my example above would be accepted by an older shell
and processed without stripping the leading spaces. If that's
unacceptable, we need a different (and currently invalid) replacement
for "<<-" (the only thing that comes to mind is "<<|" which seems a
bad choice).
Messages sorted by:
Reverse Date,
Date,
Thread,
Author