Re: Parameter expansion, patterns and fnmatch
On 2016-08-09 23:39 +0200, Harald van Dijk wrote: > 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 a lot! For what it's worth, I've been using dash with this patch this for about a week now, including building a lot of open source software (via OpenEmbedded). I haven't seen any issues yet. -- Olof Johanssonhttps://github.com/olof -- 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
Parameter expansion, patterns and fnmatch
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]
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?
Thanks,
--
Olof Johanssonhttps://github.com/olof
--
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
Re: dash drops exported bash functions
On 2016-02-11 14:40 +0100, Makarius wrote: > In any case, the Debian guys need to get involved, but I am myself > not a member of that society. Why? It's an upstream patch, it's not Debian specific. https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027 Adapt your software instead? -- Olof Johanssonhttps://github.com/olof -- 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
Re: 'set' leaks garbage from environment
On 2014-09-30 09:01 -0600, Eric Blake wrote: > $ dash -c 'unset "a|b" > $ echo $? > 0 Works for me (tested on both Debian package versions 0.5.7-3 (wheezy) and 0.5.7-4 (unstable)): $ dash -c 'unset "a|b"' dash: 1: unset: a|b: bad variable name $ echo $? 2 > $ env 'a|b=' dash -c 'set | grep a"."b' > a|b='' This I can reproduce though. -- --- | Olof Johansson http://stdlib.se/ | | irc: zibri https://github.com/olof | --- -- 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
Re: How to pass parameters containig options from variables
Hi, On 2012-09-25 10:47 +0200, b...@bc-bd.org wrote: > I am trying to pass these arguments > > -N -p -F "not host foo" > > to a binary, but > > ARGS="-N -p -F 'not host foo'" > $DAEMON $ARGS > > get's passed as 6 arguments and not 4. eval $DAEMON $ARGS should work. -- ------- | Olof Johansson http://stdlib.se/ | | irc: zibri https://github.com/olof | --- -- 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
