Re: Expansion-lookalikes in heredoc delimiters

[Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>]

On Thu, Mar 15, 2018 at 05:29:27PM +0100, Harald van Dijk wrote:
>
> That's because POSIX specifies that after ${, everything up to the matching
> }, not including nested strings, expansions, etc., is part of the word. No
> exception is made when it spans multiple lines.
> 
> Another instance of this is
> 
>   if false; then
>     echo ${
>   fi
>   }
>   fi
>   echo ok
> 
> This is accepted by bash, ksh, zsh and posh.

Interestingly, ksh bombs out on this:

	echo ${
	fi
	}

So this behaviour is not exactly consistent.

In any case, this substituion is invalid in all of these shells so
does it really matter?

> >While other shells all behave the way dash does.
> 
> All? At least two others don't: yash rejects ${ as invalid because of the
> missing parameter name. zsh agrees with bash and ksh that it should look for
> the closing }.

pdksh/mksh are the two shells that I tried.  OK I admit "all"
was stretching things :)

But my point regarding the inconsistency remains.

> >Considering the fact that even if you closed the brace after
> >the newline bash would still be stuck forever,
> 
> That's because bash doesn't ever match multi-line heredoc delimiters. Which
> is what POSIX technically requires:
> 
>   "The here-document shall be treated as a single word that begins after the
> next <newline> and continues until there is a line containing only the
> delimiter and a <newline>, with no <blank> characters in between."
> 
> No single line will ever match a multi-line heredoc delimiter.

Sure.  But this is a quality of implementation issue.  If you're
never going to match the delimter you should probably emit an error
at the very start rather than at the EOF.

> >Another interesting thing to try is
> >
> >	cat << ${ foo
> >	${
> >
> >Also you can look at the quotes:
> >
> >	cat << "
> >	"
> >
> >IOW it's not clear that "word" in this context necessarily follows
> >the same rules used during normal tokenisation.
> 
> Quotes are clear: as far as they go, this *must* follow the same rules used
> during normal tokenisation. Does any shell disagree?

I was talking about multi-line quotes, which you conveniently dismissed :)

> For your example, does any shell, including dash, *not* treat this as a
> multi-line heredoc delimiter consisting of a newline character (which may or
> may not be matched by two blank lines, depending on the shell)?

Yes, almost every shell fails with the multi-line delimiter inside
double quotes.  Only dash and ksh93 seem to get it right.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html