bug#13409: [patch] make some error messages clearer

[Jim Meyering]

Pádraig Brady wrote:
> On 01/14/2013 09:08 AM, Jim Meyering wrote:
>> Benno Schulenberg wrote:
>>> On Fri, Jan 11, 2013, at 8:39, Jim Meyering wrote:
>>>>
>>>>        wwarn (_("%s: read failed"), src_name);
>>>>
>>>
>>> When things go wrong, I would prefer to see a word like
>>> "failed", "error", "mistake", "bad", "invalid" or "mayday"
>>> at the beginning of the line (right after the command name).
>>>
>>> cmd: error in something: /some/complicated/filename
>>>
>>> cmd: /some/complicated/filename: error in something
>>>
>>> The first form is to me much clearer than the second.
>>> That something went wrong is the main thing, with
>>> which file exactly is secondary, in my opinion.
>>
>> Good argument, as long as there isn't a line number.
>> Also, you might argue that the active-voiced
>>    (I, the command) "failed to read"
>> is better than the passive-voiced
>>    (a) "read failed"
>>
>> If there are both file name and line number, then they should be
>> formatted like this, like compiler diagnostics:
>>
>>     CMD: FILE_NAME:LINE_NUMBER: diagnostic
>>
>> so that diagnostic-parsing tools can handle them seamlessly.
>
> There are many existing cases of "error {read,writ}ing" in coreutils.
> So we may change all together, but that would be a further patch.
> But I'll note that "error reading" and "error writing" are quite
> unambiguous and fit well to indicate partial failure of the operation.
> If we used "failed to write", then it might imply that nothing was written 
> etc.

Good point.

> So I've adjusted Benno's patch as per the attached,
> which rewraps long lines and s/error closing/failed to close/
> as that is a single operation where "failed to" fits well.
>
> I'll apply this in the next few hours.

Thanks.