From: Harald van Dijk <harald@gigawatt.nl>
To: Olof Johansson <olof@ethup.se>, dash@vger.kernel.org
Subject: Re: Parameter expansion, patterns and fnmatch
Date: Tue, 9 Aug 2016 23:39:13 +0200 [thread overview]
Message-ID: <0ce0bca2-3bdd-a1f5-169e-0291a49cd6c7@gigawatt.nl> (raw)
In-Reply-To: <20160809092832.GB23983@brutus.ethup.se>
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
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
[-- Attachment #2: lit-lbrack.patch --]
[-- Type: text/x-patch, Size: 234 bytes --]
--- 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 == '[') {
next prev parent reply other threads:[~2016-08-09 21:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 9:28 Parameter expansion, patterns and fnmatch Olof Johansson
2016-08-09 21:39 ` Harald van Dijk [this message]
2016-08-17 14:50 ` Olof Johansson
2016-09-02 14:04 ` Herbert Xu
2016-09-02 14:25 ` Eric Blake
2016-09-02 14:29 ` Herbert Xu
2016-09-02 14:49 ` Eric Blake
2016-09-02 14:51 ` Herbert Xu
2016-09-03 12:03 ` Harald van Dijk
2016-09-03 13:05 ` Herbert Xu
2016-09-03 13:19 ` Harald van Dijk
2016-09-03 13:58 ` Herbert Xu
2016-09-03 15:16 ` Harald van Dijk
2016-09-02 14:46 ` Herbert Xu
2016-09-02 14:54 ` Eric Blake
2016-09-02 15:06 ` Chet Ramey
2016-09-02 14:48 ` Eric Blake
2016-09-02 15:12 ` Jilles Tjoelker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ce0bca2-3bdd-a1f5-169e-0291a49cd6c7@gigawatt.nl \
--to=harald@gigawatt.nl \
--cc=dash@vger.kernel.org \
--cc=olof@ethup.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.