On 27/03/2018 20:24, Herbert Xu wrote:
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.
Yes, that's why I ended up proposing what I put below, which does allow
them the same functionality. Neither glob() nor expmeta() would see
CTLESC, and neither would need to, since neither would need to optimise
for the no-metachars case.
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.
What would need to change in POSIX to convince you to change dash to
match what you were already arguing is the POSIX-mandated behaviour? :)
More serious response: I do think it's worth raising this as a bash bug
too and seeing what they do.
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.
That's true. The least unlikely scenario I can think of is a directory
name containing [ but not ]. A script may end up escaping the [ in that
case just as a precaution, even though it's not strictly needed, and
glob() may return early due to GLOB_NOMAGIC picking up on the fact that
[ is not magic in that context.
Cheers,
Harald van Dijk
--
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
