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.

POSIX Token Recognition says `bad` is to be recognised as a single token of type word, and any word can act as a heredoc delimiter. POSIX Here-Document says only quote removal is performed on the word.

However, dash does not always preserve the original spelling of the word. That's what's going on here. Because dash hasn't preserved the `bad` spelling (it's been turned into CTLBACKQ), the check for the end of the heredoc doesn't pick it up, and it instead gets taken as a command substitution.

When an actual 0x84 byte is seen in the input, *that* gets taken as the heredoc delimiter:

  dash -c "tail -n1 <<\`:\`
  `printf \\\204`
  ok
  \`:\`"

In a locale in which 0x84 is a valid character (since dash doesn't support locales, that's easy, it's always valid), it's supposed to print "ok". dash instead interprets the second line as the end of the heredoc and subsequently issues an error message when it interprets "ok" on line 3 as a command to execute.

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

Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to