allow space before heredoc name

[kasperk81]

in bash, this is allowed:

cat <<       EOF      > /tmp/afile       
  stuff
  more stuff
EOF

Dockerfile are quite pedantic about no space between << and name EOF, otherwise it gives a very confusing syntax error on next line which leads user to think if heredocs are supported, then the follow up google search makes things more confusing... looks to be a simple case of a missing \s* in heredoc parser.

[thaJeztah]

I know the original implementation (see #2132, moby/moby#34423) was based on https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04 - we should probably read up in that document to see how it defines handling of whitespace here.

If the spec doesn't define whitespace being supported, I'm somewhat leaning towards not allowing it (also in light of efforts in the Dockerfile syntax to provide linting errors for consistency), but we should definitely (where possible) improve errors to make it clear to the user what's wrong (i.e., if we decide based on the above to not allow whitespace, then at least a linter and/or error should indicate that it's because of whitespace).

cc @jedevc @tianon

[kasperk81]

yes if the error is improved to say "did you mean <<EOF" that would suffice too (in case allowing space there is not feasible)

[tianon]

That section of the spec doesn't spell out the expected whitespace behavior, but all the examples there are tight. FWIW, BusyBox allows whitespace there too, so I'm sure there's another part of the spec (probably somewhere in some of the token parsing language) that talks about it more generally, and all the other redirection operators are well-known to allow whitespace around them, so it's reasonable to expect the heredoc would too (given it's also a redirection operator).

Another place that allows spaces, and where I know the author has very meticulously read the relevant specs is mvdan/sh: https://github.com/mvdan/sh/blob/8a52daabb9b3c31255442161a2eb7a00b365c006/syntax/printer_test.go#L922 ❤️

(So TLDR, I think allowing spaces here is reasonable and consistent with the relevant standards we're emulating, if the parser doesn't get too complex in doing so.)

[jedevc]

Yup, looking through how bash and zsh handle this as well, they both handle spaces before the EOF terminator, so seems very reasonable to handle it in the dockerfile parser as well.