GNU bug report logs -
#74159
Unexpected exit code of 0 when -q is set and close_stdout fails
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#74159: Unexpected exit code of 0 when -q is set and close_stdout fails
which was filed against the grep package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 74159 <at> debbugs.gnu.org.
--
74159: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74159
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
On 2024-11-01 06:10, Jan Černohorský wrote:
> when the `-q` option is
> detected (grep.c:2697), the `exit_failure` variable is set to 0. This
> causes any error, when not specially handled, to exit with 0, even
> before any match is found.
Yes, that's a mistake. I can't reproduce your bug but I can see other
consequences of the mistake. Fixed in the attached patch (with a test
case that's unlike your problem); please give it a try.
That being said, the lower levels of your OS appear to be buggy, as
'close' should not fail with EACCES. I wouldn't be surprised if other
software breaks because of this issue. So I suggest also reporting a bug
to whoever maintains the NFS client code that you're using.
I'm boldly closing this bug report; we can reopen it if the patch
doesn't work for you.
[0001-grep-fix-q-suppression-of-diagnostics.patch (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
Hello,
I've encountered a particularly interesting bug in GNU grep yesterday while
hunting some issues with LibreOffice (if you're interested in the whole
post-mortem, it can be read here:
https://grsc.cz/blog/loffice-linux-issues/, but it's mostly not relevant
for this bug).
Whenever the `-q` option is used, grep can exit with a 0, even if no
match has been found and an error has been encountered. In particular,
when the `close_stdout` function is called and the `close` syscall
fails, grep exits with 0, even when it's not supposed to.
While reading the source code, I found out that when the `-q` option is
detected (grep.c:2697), the `exit_failure` variable is set to 0. This
causes any error, when not specially handled, to exit with 0, even
before any match is found. This is also true for the `close_stdout` libc
function, which hard exits using `_exit(exit_failure)` when the syscall
fails.
This, at first glance, (and pardon me if I'm wrong, I haven't looked
into the source code that deeply) seems to me as bad design, since it
makes the code prone to multiple such mistakes – where someone
inadvertently uses the `exit_failure` variable without realising it
makes the program return the wrong code. It would make much more sense
to me (and again, I don't know whether this is possible) to set the
`exit_failure` variable to 0 only *after* the first match is found,
preventing such issues altogether. It also makes more sense semantically
IMO, as the `-q` option states that errors are ignored only when a match
is found, not always.
As I feel this is more of a design decision than a straightforward fix,
I'm not sending a patch, but I'll be glad to assist any efforts to
fix this.
CC'd are my colleagues who helped discover the issue.
Regards,
Jan
This bug report was last modified 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.