On 27/03/2018 14:19, Herbert Xu wrote:
Nowhere does it say that backslashes that come from the result of
parameter expansion is always literal.

So it's clear that any shell that treats the backslash as a literal
backslash is already broken.

By the literal POSIX wording, yes, but the fact remains that that's what all shells aside from bash were already doing, so that may mean it's a POSIX defect. That's why I qualified with "POSIX specifies and/or intends to specify".

But I'm tempted to agree with your and Martijn's point of view now that it's better to just implement it the way POSIX specifies, that it's more useful that way.

On Tue, Mar 27, 2018 at 01:07:21PM +0200, Harald van Dijk wrote:
Can you show me any shell other than bash that lets this optimisation affect
the results?

The fact is that the other shells are not doing what they do because
they're not doing this optimisation.  They do what they do because
they have broken POSIX because they always treat backslashes that
arise from parameter expansion as literal backslashes.

Right, but they're doing this optimisation as well.

FWIW it wouldn't be hard to iron out the anomalous case of /d\ev.
You just have treat the backslash as a metacharacter.

That's a good point and wouldn't have too much of an impact on performance of existing scripts. BTW, that means both expandmeta()'s metachars variable, and expmeta()'s

  if (metaflag == 0 || lstat64(expdir, &statb) >= 0)

optimisation. You already got rid of the latter in your patch to prevent buffer overflows.

In regular /d\ev that doesn't come from a variable, the backslash will have been replaced by CTLESC, but it's not necessary to treat CTLESC as a metacharacter: in that case, either there's a match and pathname expansion produces /dev, or there's no match and quote removal produces /dev, so the optimisation is still valid. It'd only affect backslashes that come from a variable, so it's very limited in scope.

Cheers,
Harald van Dijk
--
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

Reply via email to