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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28/03/2018 08:18, Herbert Xu wrote:
On Tue, Mar 27, 2018 at 08:38:01PM +0200, Harald van Dijk wrote:

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? :)

No the passage I quoted only mandates that backslashes be
interpreted when doing the matching.  It doesn't say anything
about whether it should be removed after matching is done.  The
only thing it does say is that:

	If the pattern does not match any existing filenames or pathnames,
	the pattern string shall be left unchanged.

IOW it's silent in the case where the pattern does match.

Of course it doesn't say whether characters in the pattern are preserved in the case of a match. That's because when there's a match, pathname expansion produces the file name, not the original pattern.

In a directory containing foo.txt, you wouldn't argue that *.txt might expand to *foo.txt just because POSIX doesn't explicitly say the * is removed, would you?

However, the other reason this is not worth fixing is because all
those other shells that always treat the backslash as a literal
won't remove it in this case anyway.

I seriously cannot understand the logic of pushing a break from traditional ash behaviour and from all shells apart from bash, giving POSIX as a reason for doing it, and then giving the behaviour of all those other shells as a reason for not doing it properly.

If all those other shells are a reason against doing it, then why isn't that a reason for just restoring the dash 0.5.4 behaviour that all those other shells implement, always taking expanded backslash as effectively quoted?

                                      So nor sensible script could
possibly use such a feature even if we implemented it.

No portable script could use such a feature. A sensible script certainly could. There are a lot of scripts that aren't meant to be portable across shells. I know I've written scripts for my own use that use dash features that don't work the same in bash.

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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux