Re: indented heredocs

["Nikolay Aleksandrovich Pavlov (ZyX)" <kp-pav@xxxxxxxxx>]

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.