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 <herb...@gondor.apana.org.au> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html