Zsh Mailing List Archive
Messages sorted by:
Re: indented heredocs
- X-seq: zsh-workers 40251
- From: "Nikolay Aleksandrovich Pavlov (ZyX)" <kp-pav@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: indented heredocs
- Date: Sat, 31 Dec 2016 21:11:30 +0300
- Authentication-results: mxback9j.mail.yandex.net; dkim=pass email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1483207890; bh=vuVmi5YGkpOQDIr585/Zc+59uLhdm4QGt6pv0s30iaU=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=sGbUzuURR8eV64BeJnLR4kxsx7kkF1coKgHg9RV3gSYOpaLFgbxHFirmZHc2O0S7S /8xK+paeKNMui7fiOdafN2FT8PaeATL4ih8soXPwOwZKHZsxJzUQMgXdpVu1k2Dhs3 TNrHt6lAoWIylXRl9Vzyeyy1QfDuWI83B+4kjpv4=
- In-reply-to: <161229185629.ZM11029@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CFA2339B-26F2-4104-AAD2-64852509286B@yost.com> <CAH+w=7bGEb13SUxX-whdHzWRktoiMdvgSosJvcEoZ+t0z3FOhA@mail.gmail.com> <firstname.lastname@example.org> <161229185629.ZM11029@torch.brasslantern.com>
30.12.2016, 05:57, "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>:
> On Dec 30, 1:31am, Nikolay Aleksandrovich Pavlov (ZyX) wrote:
> } 22.12.2016, 01:11, "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>:
> } > I would propose instead something similar (read on below) to this:
> } >
> } > % cat <<-' xx'
> As has already been pointed out, this can't be used exactly as-is,
> because quotes around the end marker already have semantics.
> } This makes changing the indent rather tricky.
> Well ... it means you have to both change the indent and declare that
> you've changed it. I wouldn't call that "tricky".
“Tricky” here means only “I can’t just use `V)>` in Vim”. Or “when doing refactoring it would be easy to miss necessary changes”.
> } YAML does better here: amount of stripped indent is either determined
> } based on the first non-blank line [...]
> This is at least feasible. (Does "non-blank" mean "contains a character
> that is not whitespace"? What's whitespace?)
I would suggest to mean “space or tab” by whitespace. Generally “anything what may be used for indentation or separating command arguments” (I would not be surprised to hear that I missed that zsh allows using some fancy unicode characters as whitespaces for indentation or separating comand arguments in unicode locales).
> Would we want to strip leading space and tab, or e.g. leading $IFS (with
> the probable exclusion of the set $'\f\n\r\v' in that case)?
I would expect it to strip leading spaces and tabs (and error out if there are no necessary spaces in a non-blank line). Involving IFS is not needed: it is not checked for indentation or separating command arguments in source code currently after all, only in some expansions and for `read`.
Example of error: "cat <<| EOF\n\tabc\n\n def\nEOF" (indent of the third heredoc line is neither preceding the EOF marker nor indent of the first non-blank line (which is \t)).
> } or is specified explicitly, relative to the indent of the line where
> } block scalar starts
> Now that latter I *would* call "tricky" -- a numeric count relative
> to some other indent? What if some of the leading whitespace is tabs?
> Also if I read the rest of your explanation correctly, this would make
> signficant the leading whitespace before the command whose input is
> being redirected, which is a non-starter.
If this is implemented then heredocs own indent should be space-only, “some other” indent is copied as-is. But I agree that this would be tricky and it is not much needed. Also code with such explicit indent is less readable: harder to determine what exactly heredoc will result in if there is more then one line with extra (compared to initial+requested by number) indent. Actually I did not see YAML documents with such block scalars.
> } YAML uses `|` and `>` to start block scalars, that's why I used
> } `|` above (`<<>` seems odd and may be confused with `<>`). Not
> } sure why this should be a bad choice: `|` already has different
> } meanings in different contexts
> It seems a bad choice to me because of >| and >>| which have a very
> different meaning. If we were going to use either <| or <<| for some
> special purpose, it feels as if there should be symmetry implied, as
> with e.g. <& and >&.
> Of course << and >> have already given up that sort of symmetry except
> for one being input and one being output, so ...
> This reminds me that both <<; and <<& also are currently bad syntax;
> though "<<;" is probably an even worse choice than "<<|". There is
> at least precedent for combining one of "|" or "&" with redirection.
Messages sorted by: