On Tue, May 9, 2023, 01:50 Robert Elz wrote:
> Date:Mon, 8 May 2023 11:13:19 -0400
> From:Chet Ramey
> Message-ID: <4c66cc58-27f7-4001-c831-8a2a23264...@case.edu>
>
> | I see I might need to update the error message to specify it's process
> | substitution.
>
> You might want to (for this particular case anyway) want to change it
> from saying "unterminated here-document" (which would imply that a here-doc
> was being fetched, and EOF was reached instead of the terminator - which is
> definitely worth warning about, perhaps even being an error) as that isn't
> what this error is, the issue is that the here doc doesn't appear in the
> environment at all ("missing" would be better than unterminated - it was
> perfectly well terminated, or perhaps "misplaced" as the here doc text is
> located anyway, just not where some people expect to find it).
>
> | The process substitution is in its own parsing environment,
>
it is , isnt it , just the default cmdline parsing with full bash cmds ..
as default user input , in terminal
in $( .. ` .. <( .. makes new cmdline
The forthcoming POSIX draft kind of expects that - but I don't really
> like it, and the existing standard, and all before it - and the original
> Bourne shell - didn't treat here docs like that at all. They were read
> following the next newline (token, not one buried inside a string, or
> whatever) in the source, and the current text just says "after the next
> newline" (or words to that effect). That is the next newline after the
> << operator (with appropriate allowances given to command lines with
> multiple
> here doc operators, where the here docs follow, in order of the operators,
> one after another, starting with the next newline).
>
> Of course, in the Bourne shell there was only the `...` form of command
> substitution, with its own truly bizarre set of parsing rules, which made
> this more or less inevitable.But somewhere along the line, someone
> came to the delusion that command substitutions (which would include bash's
> process substitutions) should simply be read as a "word" and then parsed
> later. It has since been conclusively demonstrated that that way lies
> madness, and parsers cannot work like that, the command substitution text
> needs to be parsed as it is read (whether or not the results of that parse
> are saved, or just the text that created it, to be parsed again later),
> which
> means that the here doc operator must necessarily be seen during that
> initial
> parse - and the here doc text can (and IMO should) follow at the next
> newline,
> wherever that happens to occur. That text can be saved to be used again
> when the command substitution text is parsed gain later if that is the way
> the shell wants to do things (though why anyone would want to parse the
> text,
> throw the results away, and then parse the same text again later is beyond
> me,
> the only possible advantage is to allow some syntax errors to be ignored
> during the initial parse, and only be reported if the second one actually
> happens (code flow might mean that the command substitution is never
> executed). That only works occasionally - many syntax errors cause
> parsers to get into a state from which they find it difficult to recover,
> certainly not enough to be at all confident that the end of the command
> substitution is correctly detected - which is the major aim of the first
> parse) - and in any case, really just make broken code appear to be
> correct, until sometime later when it does need to run, and then fails.
> IMO it is much better to report the error immediately (during the first
> parse) even if the code would never be executed, as in:
> if false; then x=$(nonsense code; done); fi
> (as best I can tell, current bash does always report that kind of nonsense
> as a syntax error, and that's good, even though the assignment to x is
> never run, so the command substitution is never executed).
>
> Always simply reading here-docs after the next newline (wherever it
> appears) allows here docs to be written as the OP requested, and many
> other variations - the rule that the here doc text follows the next
> newline (token) is trivial to understand, even if it makes parsing
> theory purists vomit. Here doc text is not part of the shell grammar,
> it is noticed and removed from the input stream during lexical analysis,
> and just because of that, should be treated entirely separately from the
> parse state.
>
> eg:
> cat < text for the first here doc
> comes here
> HD1
> sed commands for the second here doc
> come here
> HD2
> )"; echo ::: END ) # <<- that's the end of
> the cmdsubs
> or:
> cat < text for the first here doc
> comes here
> HD1
> sed commands for the second here doc
> come here
> HD2
>
> which is nicer (but bash doesn't par
