On 28/03/2018 13:00, Herbert Xu wrote:
On Wed, Mar 28, 2018 at 12:53:31PM +0200, Harald van Dijk wrote:
[un-snip]
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.
Nope, bash treats it as if the backslash is not there.
$ pwd
/home/dash
$ touch asdf\\
$ touch asdf
$ bash -c 'v="../da*sh/asdf\\"; printf "%s\n" $v'
../dash/asdf
$
Huh. Indeed in that case, but at the same time:
bash -c 'v="?sdf\\"; printf "%s\n" $v'
Here, it will not be considered to match, this just prints ?sdf\. I
suspect bash has the same kind of logic as dash, where it just tries to
lstat() the file if the final pathname component contains no
metacharacters or goes through an opendir()/readdir()/closedir()
sequence if it does, and mishandles this corner case.
[...]
Since bash itself is inconsistent, and POSIX unclear,
What exactly is unclear about the sentence of POSIX that I quoted? Is
there a legitimate interpretation of "It is unspecified whether A or B"
that allows other behaviour than A or B?
Cheers,
Harald van Dijk
--
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
