On 09/08/16 11:28, Olof Johansson wrote:
Hello,
I'm seeing some discrepancies between dash built with --enable-fnmatch
and dash built without that got me curious. Maybe you could help shed
some light?
foo='[abc]'
echo ${foo#[}
echo ${foo#\[}
With dash built with --enable-fnmatch:
abc]
abc]
With dash built without --enable-fnmatch:
[abc]
abc]
Nice find.
I was able to reproduce this behavior on latest git master
(17a5f24e0). The dash manual states:
The end of the character class is indicated by a ]; if the ] is
missing then the [ matches a [ rather than introducing a character
class.
Which to me suggests that the non-fnmatch case is not the expected
behavior. Is this interpretation correct?
Yes, this looks like a bug in dash. With the default --disable-fnmatch
code, when dash encounters [ in a pattern, it immediately treats the
following characters as part of the set. If it then encounters the end
of the pattern without having seen a matching ], it attempts to reset
the state and continue as if [ was treated as a literal character right
from the start. The attempt to reset the state doesn't look right, and
has been like this since at least the initial Git commit in 2005.
This also affects
case [a in [?) echo ok ;; *) echo bad ;; esac
which should print ok.
Attached is a patch that attempts to reset the state correctly. It
passes your test and mine, but I have not yet tested it extensively.
Thanks,
Cheers,
Harald van Dijk
--- a/src/expand.c
+++ b/src/expand.c
@@ -1594,7 +1594,8 @@ pmatch(const char *pattern, const char *string)
do {
if (!c) {
p = startp;
- c = *p;
+ q--;
+ c = '[';
goto dft;
}
if (c == '[') {
