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

[Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>]

On Tue, Mar 27, 2018 at 08:01:10PM +0200, Harald van Dijk wrote:
>
> >Right.  I guess we could change it so that CTLESC is preserved
> >to distinguish between the backslashes from parameter expansion
> >vs. backslashes from open input.
> 
> Thinking about it some more, see below.

Actually let's not go down this route because this would mean
that the glob(3) path will never have the same functionality
since it cannot possibly see CTLESC.

> It was just the most basic command I could think of that shouldn't hit the
> FS, currently doesn't hit the FS, and would start hitting the FS if
> backslash gets taken as a metacharacter. Anything containing a quoted
> metacharacter would do. I suppose I could have used echo "[  ok  ]" instead
> for something that's more likely to pop up in a real script.

My inclination is to just drop the /d\ev issue and use the bash
behaviour until such a time that bash changes or POSIX changes.

It's such an unlikely case as why would anyone knowingly put
backslash into a variable and expecting pathname expansion to
remove it without actually using real magic characters.

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