bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51860: [PATCH] Reinstate Binary file matches to stdout


From: Duncan Roe
Subject: bug#51860: [PATCH] Reinstate Binary file matches to stdout
Date: Sun, 21 Nov 2021 12:38:51 +1100

On Fri, Nov 19, 2021 at 01:22:23AM -0800, Paul Eggert wrote:
> On 11/18/21 17:19, Duncan Roe wrote:
> > With regard to Bug#29668: they can use `grep -s -I`.
> > Their real problem was that `-I` didn't work.
>
> The problem I was referring to was described here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29668#17
>
> This is the problem of what an ordinary 'grep' user would expect with just
> 'grep PATTERN FILE | wc', without any options.

"ordinary 'grep' user"? Like in "grep user who doesn't RTFM"?

This was *documented* *behaviour*. And it still is documented behaviour, except
now grep doesn't abide by its documentation(*).

> When the "Binary file FILE
> matches" message is sent to 'wc' its information is lost to the user. When
> the message is sent to stderr, the user sees it and has a helpful indication
> that the usage is problematic.

That's a nice idea, but I suggest it was a mis-step to unilaterally change grep
to achieve it. A new (GNU extension) option to send binary file matches to
stderr would have been better IMHO.

I'd further suggest biaary matches output to stderr by the new option be not
affected by the setting of `-s`, only by `-I`. This reinstates orthogonality of
-s and -I which 271793f0 broke. Documenting the new option would be easy. On
which subject:

Quoting commit 271793f0
> Adjust tests to match new behavior.  In all cases this
> simplifies the tests, which is a good sign.
A good sign? Maybe. I have found that a much better sign is "How easy is
updating the documentation to reflect this change?". If it's awkward, perhaps
the change was a bad idea.

The man page is not yet updated to reflect the new `-s` behaviour. Nor is the
texi(*). For option `-s` the man page says:
> Suppress error messages about nonexistent or unreadable files.
Binary file matches are neither of the above. You need to update the man page to
explain that binary file matches are now treated as errors. Personally, I'd find
that embasassing.

>
> Using 'grep -s -I' wouldn't have helped with this problem.

Why did you offer an updated `-s` as a solution then?
>
>
> > They all use `grep --line-buffered` (since `less` to the tty
> > will be line buffered), grep -s (to avoid stderr output which would mess up
> > `less`)
>
> You can use "grep PATTERN FILE 2>&1 | less". This shouldn't mess up 'less'.

As it happens, I find I can. I don't need `grep -s` inside `sfl` - it's a
holdover from before when I first wrote `sfl` last century. Back then, I was
using `grep -swn` to hide errors about unreadable directories.

Since you have provided me with a workaround, I have no further interset in this
bug. I still think the 271793f0 functionality change was wrong and could and
should be improved on. But that's up to you.

(*) I'm discounting the 1-liner in the FAQ as wholly inadequate.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]