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.
But I do concede that it makes a lot more sense to remove the
backslash in the matching case.
> 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.
I agree.
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. So nor sensible script could
possibly use such a feature even if we implemented it.
$ ksh -c 'a="/usr/bin/\["; printf "%s\n" $a'
/usr/bin/\[
$
If you really wanted to do this in a script, the portable way is
$ ksh -c 'a="/usr/bin/[[]"; printf "%s\n" $a'
/usr/bin/[
$
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
