Re: Expansion-lookalikes in heredoc delimiters

[Martijn Dekker <martijn@xxxxxxxx>]

Op 08-03-18 om 22:03 schreef Harald van Dijk:
> Consider this:
> 
>   cat <<`bad`
>   `bad`
> 
> As far as I can tell, this is technically valid, supposed to print
> nothing, and accepted in most other shells.

According to my tests, bash, ksh93, pdksh, mksh, zsh, and yash all
accept it with no problem, including old versions of these.

bosh (schily Bourne shell) fails much like dash does, but tries to run
both "`bad`" as command substitutions.

FreeBSD sh fails gracefully, exiting with "Syntax error: Illegal eof
marker for << redirection"


> When an actual 0x84 byte is seen in the input, *that* gets taken as the
> heredoc delimiter:
> 
>   dash -c "tail -n1 <<\`:\`
>   `printf \\\204`
>   ok
>   \`:\`"

This prints 'ok' on bash, ksh93, pdksh, mksh, and zsh. Given LANG=C,
this prints 'ok' on yash, too (otherwise "cannot read input: Illegal
byte sequence").

bosh fails ungracefully and FreeBSD sh fails gracefully.

So that's all the same as with the first example.


> This is pretty clearly a case that no serious script is ever going to
> encounter, not to mention one that many shells don't even attempt to
> support, at least not completely, so I don't think this is a real
> problem.

How do you figure that "not many" do? By my tests, the vast majority of
shells support it completely -- much more still if you count their
respective user bases instead of counting them all equally.


> I'm mentioning it anyway because I was trying to come up with a
> few more test cases for the parser, and I think it's good to have a
> record not only of what worked, what has been made to work, and what got
> broken, but also of what's never going to be work.

I think it should be fixed to act either like FreeBSD sh or like the
majority. Fixing obscure bugs that "no one will ever encounter" may fix
other bugs in the process, and increases the integrity of the code.

- M.
--
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