Re: quoting of strings in errors

[Jim Meyering]

On Mon, Nov 2, 2015 at 6:33 AM, Pádraig Brady <address@hidden> wrote:
> On 28/10/15 18:19, Jim Meyering wrote:
>> On Wed, Oct 28, 2015 at 10:30 AM, Pádraig Brady <address@hidden> wrote:
>>> On 28/10/15 17:01, Jim Meyering wrote:
>>>> On Wed, Oct 28, 2015 at 6:18 AM, Pádraig Brady <address@hidden> wrote:
>>>>> seq 10 | shuf --random-source="blah"$'\r'
>>>>
>>>> Thank you for pursuing this.
>>>> Properly quoting unusual names like those is definitely welcome,
>>>
>>> Cool. At least with this patch, the quoting is consistent across all utils.
>>> I.E. we were already using quote() in most places.
>>>
>>>> however, in the remaining 99% of use cases, I find the added quotes
>>>> to be most unwelcome: at least two extra bytes per line, in addition to
>>>> the common hassles with multi-byte rendering.
>>>>
>>>> What do you think about a mode that quotes only when necessary?
>
> Note one caveat with not using quotes by default, is it
> might result in errors that are harder to understand.
> For example the problematic item is not immediately
> obvious in the following message:
>
>   $ fname="file"
>   $ fmt "$fname"
>   fmt: cannot open file for reading: No such file or directory
>
> By using shell_escape_always rather than shell_escape, we
> still get the non multi-byte quoting and copy/paste benefits?
>
>   $ fname="file"
>   $ fmt "$fname"
>   fmt: cannot open 'file' for reading: No such file or directory
>
> What do you think?

In a context like that, where there is no delimiter already,
I agree completely that the quotes are welcome.
The cases where I prefer to omit the quotes are where the
name is already delimited by ": " on one side and ":" on the other:

  $ touch k; chmod 0 k; cat k
  cat: k: Permission denied

Hmm... not trivial, I'm sure, but I'll bet one could automate the
conversion and add a syntax-check rule to keep things consistent.