On Tue, Aug 07, 2018 at 04:21:31AM -0400, Eric Sunshine wrote:
> diff --git a/t/chainlint.sed b/t/chainlint.sed
> index 5f0882cb38..bd76c5d181 100644
> --- a/t/chainlint.sed
> +++ b/t/chainlint.sed
> @@ -61,6 +61,22 @@
> # "else", and "fi" in if-then-else likewise must not end with "&&", thus
> # receives similar treatment.
> #
> +# Swallowing here-docs with arbitrary tags requires a bit of finesse. When a
> +# line such as "cat <<EOF >out" is seen, the here-doc tag is moved to the
> front
> +# of the line enclosed in angle brackets as a sentinel, giving "<EOF>cat
> >out".
> +# As each subsequent line is read, it is appended to the target line and a
> +# (whitespace-loose) back-reference match /^<(.*)>\n\1$/ is attempted to see
> if
> +# the content inside "<...>" matches the entirety of the newly-read line. For
> +# instance, if the next line read is "some data", when concatenated with the
> +# target line, it becomes "<EOF>cat >out\nsome data", and a match is
> attempted
> +# to see if "EOF" matches "some data". Since it doesn't, the next line is
> +# attempted. When a line consisting of only "EOF" (and possible whitespace)
> is
> +# encountered, it is appended to the target line giving "<EOF>cat >out\nEOF",
> +# in which case the "EOF" inside "<...>" does match the text following the
> +# newline, thus the closing here-doc tag has been found. The closing tag line
> +# and the "<...>" prefix on the target line are then discarded, leaving just
> +# the target line "cat >out".
Gross, but OK, as long as we would not get confused by a line that
actually started with <EOF> at the start.
> +/<<[ ]*[-\\]*[A-Z0-9_][A-Z0-9_]*/ {
> + s/^\(.*\)<<[ ]*[-\\]*\([A-Z0-9_][A-Z0-9_]*\)/<\2>\1<</
> + s/[ ]*<<//
Here-docs can use lowercase, too, though I'd personally frown on that
from a style perspective.
It looks like this doesn't catch:
cat <<'EOF'
EOF
either. I think we prefer the backslash style, but there are quite a few
<<-'EOF' hits. Is it covered somewhere else?
-Peff
