On 03/09/16 15:05, Herbert Xu wrote:
On Sat, Sep 03, 2016 at 02:03:28PM +0200, Harald van Dijk wrote:
This also affects
case [a in [?) echo ok ;; *) echo bad ;; esac
We're talking about something that dash has had code to handle for
10 years, that's been documented by dash as supported for >10
years, and now that it turns out there's a flaw in the code where
dash does not behave as documented and as clearly intended by the
code, it's POSIX's fault?
dash has never worked this way.
Very misleading to continue quoting the complicated case but leave out
the simple case again: dash doesn't handle even ${foo#[} correctly. And
again, by correctly I mean as documented by dash, as required by POSIX,
and as clearly intended by the author at the time the code was written.
I do not know if you were the author of that specific piece of code.
But yeah, sure, if the bug has been there for over 10 years, and I'm
unable to find older versions of dash to check, I would have guessed
that dash indeed has never worked this way.
What's worse is that your patch
changes dash's behaviour in a way that is inconsistent with every
shell out there except bash.
For the simple case, ksh and posh also strip a leading [ if doing ${foo#[}.
For the complicated case, at the very least, it makes dash consistent
between builds. If you feel that for the complicated case, bad should be
printed rather than ok, then that just makes dash buggy in the
--enable-fnmatch builds, it still means there's something to fix.
--
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
