On 11/11/2016 03:25 PM, L. A. Walsh wrote: > Eric Blake wrote: >> >> If the idea is that the quoting is there to make copy-and-pasting into a >> shell command line easier, then there is nothing we can do that is less >> aggressive, since failing to quote spaces changes what the shell will >> do. > ---- > I assume you are talking about "quoting-style=shell-always" > and not the conditional quoting you get for "quoting-style=shell"?
quoting-style=shell-always uses quotes ALWAYS, even if the quotes are redundant. quoting-style=shell uses quotes ONLY if the shell could otherwise interpret it differently without the quotes. Reusing Paul's example: $ \ls --quoting-style=shell 'a b' c $ \ls --quoting-style=shell-always 'a b' 'c' Note that 'a b' needed quoting under both styles, but 'c' was conditional. >> If the idea is that the quoting should only be added to avoid >> ambiguous situations, then maybe you are right that we can add further >> heuristics to the quoting algorithm to disable quotes on output that is >> unambiguous, even if it can't be pasted back into the shell. Having two >> different quoting modes, where you can choose between the options, may >> be the way to go - but then you STILL have the problem of what to pick >> as the default of those two modes when neither one was explicitly >> requested. >> > ---- > Seems like the default is to not put quotes. That's what > is used now. Why would you break it? Paul was suggesting _yet another mode_ (which someone would have to write patches for), which avoids quotes in all situations where the output is unambiguous (a file 'a b' is unambiguous in 'ls' output even without quotes, since the ambiguity only arises if you have two spaces; but a file 'a b' would still need quotes, as would a file that itself contains literal quotes in the name), but also pointing out that the definition of "not ambiguous" may be context sensitive (the ambiguity of plain 'ls' [two spaces, embedded newline, or something that uses the same mechanism we use for escaping the other ambiguous cases] differs from the ambiguity of 'ls -l' [embedded newline, or something that uses the same mechanism we use for escaping the other ambiguous cases], because two spaces is ambiguous in one but not the other). Personally, I think that trying hard to avoid quotes makes the addition of quotes that much more surprising when hitting the corner cases, which by their nature are already corner cases and therefore somewhat rare, so I'd rather stick with a style that is very easy to describe ("if the shell could misintepret it without quotes, add quotes; and this applies regardless of the app using this quoting rule") over one that is difficult ("if it matches potential ambiguity A, B, or C, add quotes - but now you have to learn a different list of A, B, and C for every app and context that has different ambiguities"). Furthermore, I _like_ quoting-style=shell (and NOT quoting-style=shell-always) in one regards: when dealing solely with file names that are declared portable according to POSIX, quoting-style=shell is indistinguishable from quoting-style=literal. It is only on file names that are already inherently non-portable to all possible file systems where the additional quotes calls my attention to the potential portability issue, whereas quoting-style=always does not have that benefit. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature