-
Notifications
You must be signed in to change notification settings - Fork 1.2k
dockerfile: allow whitespace in heredocs #5817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
all these are valid in shells: # no spaces
cat <<EOF> /tmp/afile
# leading and trailing spaces
cat << EOF > /tmp/afile
# leading space only
cat << EOF> /tmp/afile
# trailing space only
cat <<EOF > /tmp/afile |
740605c
to
3db9444
Compare
Woops, forgot we needed to handle the word splitting as well, should work properly now 👀 All of the above should be valid - we don't need to do any additional word to handle the trailing spaces, those work as intended today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!! Looks less complicated than I expected it to be (which is good!).
Found one typo; otherwise just me rambling 😂
@@ -677,3 +697,11 @@ func trimSuffix(pattern, word string, greedy bool) (string, error) { | |||
} | |||
return reverseString(str), nil | |||
} | |||
|
|||
func isWhitespace(r rune) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to change, but this got me thinking; "wasn't there some utility or const in stdlib for these?".
I think having this utility is readable for sure, so definitely no need to swap (just me now getting curious 😂 - I'll probably start digging to find)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unicode.IsSpace
does roughly this, but not quite 😢 it also includes newlines, which we're not interested in.
`<<-"EOF"`, | ||
`<<EO"F"`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh; I actually didn't know (or forgot) these were allowed as well
reHeredoc = regexp.MustCompile(`^(\d*)<<(-?)([^<]*)$`) | ||
reHeredoc = regexp.MustCompile(`^(\d*)<<(-?)\s*([^<]*)$`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also me thinking out loud; should we (at some point) consider capturing these, so that we could reformat in a canonical form (whitespace removed) 🤔
Also curious now if we have a useful error if we found the start "word", but didn't find the "end" word (i.e., user either forgot, or (e.g..) accidentally indented.
It would be really nice if we could show a usable error for them ("did you mean ... <non-indented>
?")
docker build -<<'EOF'
FROM alpine
RUN <<'EOD'
echo hello
EOD
RUN echo world
RUN echo that's it
EOF
Currently, it just continues going, and marking the whole remainder of the Dockerfile to be part of the here document.
Dockerfile:2
--------------------
1 | FROM alpine
2 | >>> RUN <<'EOD'
3 | >>> echo hello
4 | >>> EOD
5 | >>> RUN echo world
6 | >>> RUN echo that's it
7 |
--------------------
ERROR: failed to solve: unterminated heredoc
Which is "correct", but possibly could be made smarter (seeing RUN
at start of the line could be deducted as; PROBABLY you meant to terminate here, and seeing an indented <word>
could be detected as "did you accidentally add whitespace?")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I remember thinking about this, but it kind of ends up involving totally different layers of the lexer/parser to produce this warning, so the effort to produce it seems way higher than the benefit of such a message.
I'm also not entirely convinced that unterminated heredoc
is that bad of an error message, especially given that it highlights which line it starts on.
Signed-off-by: Justin Chadwell <me@jedevc.com>
3db9444
to
c80fa93
Compare
Fixes #5778.
FYI @tianon @thaJeztah