Re: Unclosed quotes on heredoc mode

[Robert Elz]

    Date:        Sat, 20 Nov 2021 11:33:37 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <4addb789-50b6-12a5-7b8a-8a082abaa50d@case.edu>

  | I'm skeptical, but willing to be convinced. Bourne's shell allowed EOF to
  | terminate all sorts of things (quoted strings, command substitutions, here
  | documents) -- enough to make it purposeful.

More likely economical.   Making things fit in that sh was a real challenge.

  | > So just how many complaints do you get about the warning message?
  | > "ksh doesn't complain wbout this, why does bash?"

  | It's usually people who have misplaced or mistyped the ending delimiter.

Yes, exactly - it happens like that all the time.   That's why it should
be an error, not just a warning - no different than when someone does
        cmd >/tpm/foo
they made a typo, they get an error, and fix it.   No problems.


  | "When an io_here token has been recognized by the grammar (see Shell
  | Grammar), one or more of the subsequent lines immediately following the
  | next NEWLINE token form the body of one or more here-documents and shall be
  | parsed according to the rules of Here-Document."

That's a good starting point, provided you're willing to actually implement
that.  That's what I'd like.   But for this you need to understand that
the shell has to parse and understand command substitutions, as they're read,
in order to correctly find the end, and a newline token in the middle of
a command substitution counts for a here doc operator that occurred before
it, and a here doc operator in a command substitution might not encounter
a newline until after the cmdsub text has ended - the next following newline
token provides there here doc text.

  | That implies that the shell goes off and
  | reads lines before parsing the rest of the current line as a list.

Yes, certainly - how to read the here doc seems to be agreed, just when
to read it is not.

  | >   cat <<EOF > file ; echo "abc
  | >   def
  | >   EOF
  | >   ghi" \
  | >   EOF
  | >   EOF
  | > What is the here doc, and what does echo say.
  |
  | That's a good example. The here-doc is empty (the delimiter is the third
  | EOF) and the echo prints the rest of the text, with the backslash-newline
  | disappearing.

I agree.

  | I'd say that this is somewhat deceptive, and is a decent illustration of my
  | point. The shell -- bash, at least -- always reads complete lines from the
  | input before parsing any here documents, so it's going to keep reading
  | through the second EOF to read the `complete' first line, due to the quoted
  | string and the quoted newline. The `current' token is going to be the
  | newline that follows the second EOF even before it starts figuring out that
  | it has a here-document and goes off to collect the body.

That's reasonable.   As long as you stick to reading lines, and parsing
them as they're read, and then insert here doc contents as soon as a here
doc operator is located on one of the lines read.

  | > For this.  No.   An extension.  One that comes for feee.
  |
  | I like the Freudian slip there.

Oops...   didn't spot that one!

kre