Re: expand: Do not quote backslashes in unquoted parameter expansion

[Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>]

On Tue, Mar 27, 2018 at 02:57:12PM +0200, Harald van Dijk wrote:
>
> 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.

No the purpose of this metaflag check is to bypass the lstat call.
My patch simply made it bypass the call by returning earlier.

It is not relevant to whether we include backslash as a metacharacter.

> 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.

For the case where the backslash came from the parser, the CTLESC
would have already been removed by preglob so there should be no
difference.

The only problem with the metacharacter approach is that glibc's
glob(3) probably won't treat it as a metacharacter and therefore
it will still behave in the same way as the current bash.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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