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.
