On 28/03/2018 12:37, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 12:03:24PM +0200, Harald van Dijk wrote:


When expanded backslashes are no longer treated as quoted, this would call
expmeta() with the pattern *\, that is with a single unquoted trailing
backslash, so:
[...]

Thanks for the explanation.  Here is an updated patch.

That seems consistent with what pmatch() does for trailing unquoted backslashes, but actually, I think pmatch() is wrong on that too. POSIX says:

If a pattern ends with an unescaped <backslash>, it is unspecified whether the pattern does not match anything or the pattern is treated as invalid.

I don't think this allows dash's behaviour of taking the backslash as a literal, since that still allows a match to succeed. bash lets such a pattern never match. In other shells, there is no way to get into this situation, but GNU find behaves the same as bash.

Test case:

  v=\\; case \\ in $v) echo bug;; esac

bash prints nothing, dash 0.5.9.1 prints bug. Other shells don't count since they interpret $v differently.

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