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

[Pádraig Brady]

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.

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,
Pádraig.

error-failed-to.diff
Description: Text Data