2019-07-03 11:08:57 +0100, Geoff Clare: [...] > > And again, that's an incompatible change for dash, ksh88, ksh93, > > pdksh, mksh, bosh, yash where: > > > > a='\*' > > ls -ld $a > > > > lists the files that start with \ > > Which is inconsistent with find, pax, fnmatch() and glob().
And again, that argument doesn't hold. There's no find implementation that I know where find . -name '"*"*' find . -name '"$var"*' works the same as printf '%s\n' "*"* printf '%s\n' "$var"* even though that's currently allowed by the spec. And I don't expect we want to go there. And if we go there, I don't expect we would want to also add back those to the shell as a second level of evaluation (like in pattern='"$var"*'; ls -- $pattern). fnamtch() didn't add \ support for consistency with the shell, It did add the *, ? and [ glob operators of the shell and the \ quoting operator of the shell. \ is not a glob operator there but a quoting operator in its very limited syntax (compared to that of the shell which has other forms of quoting, and many forms of expansions). Adding it back to the shell *as an extra layer* hardly helps with consistency and adds confusion. But more importantly would break backward compatibility in most shells. [...] > > a='\d*' > > ls -ld $a > > > > lists the filenames that start with \d > > Which is inconsistent with find, pax, fnmatch() and glob(). Irrelevant, pax, fnmatch() and glob() don't do variable expansion. find -name '$a' is unspecified but in all implementations, that returns the files called $a literally. > > And in ksh93 > > > > a='\d*' > > case string in $a) > > > > matches on strings that start with digits. > > Which has never been allowed by any possible interpretation of the standard. But would be once bug 1234 is fixed properly by allowing both the most common behaviour and that of bash. > > I still don't understand why you want to specify a behaviour > > that is not present in any shell (but one), that would break > > backward compatibility, that is not needed, that would make the > > syntax of the shell and the text of the spec more confusing. > > We know you don't get it; you've told us several times already. > Repeating it more times is not going to achieve anything and will just > waste everybody's time. [...] We have diverging views. Bug 1234 is about saying that your view is wrong. If you don't agree, you can close that bug as "won't fix" and be done with it. But AFAICT, Eric's and Joerg's views at least are currently closer to mine than to yours. -- Stephane
