From: Juri Linkov <juri@jurta.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Dave Abrahams <dave@boostpro.com>, 9226@debbugs.gnu.org
Subject: bug#9226: 23.3; [rgrep]; (matches found) ?
Date: Wed, 10 Aug 2011 18:10:27 +0300 [thread overview]
Message-ID: <87pqkdwblb.fsf@mail.jurta.org> (raw)
In-Reply-To: <jwv1uwtbdde.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 10 Aug 2011 09:35:55 -0400")
> I suggest we remove this "matches found" thingy. It was meant to be
> a feature, but in the case where it works (i.e. for `grep') the rest of
> the output already gives the information anyway.
>
> We can replace it with the exit status code instead: it's more cryptic
> but at least it never lies.
It would be too bad to lose this useful feature that helps
to quickly see the status in the last line of the output
and in the mode line.
What we definitely know now is that:
GREP EXIT STATUS
The exit status is 0 if selected lines are found,
and 1 if not found. If an error occurred the exit status is 2.
(Note: POSIX error handling code should check for '2' or greater.)
FIND EXIT STATUS
find exits with status 0 if all files are processed successfully,
greater than 0 if errors occur. This is deliberately a very
broad description, but if the return value is non-zero, you
should not rely on the correctness of the results of find.
XARGS EXIT STATUS
0 if it succeeds
123 if any invocation of the command exited with status 1-125
124 if the command exited with status 255
125 if the command is killed by a signal
126 if the command cannot be run
127 if the command is not found
1 if some other error occurred.
and currently process the following cases in grep.el:
0 finished (matches found)
1 finished with no matches found
* exited abnormally with code %d
So to never lie to the users and determine reliably
the status we could use the following logic:
If status is 0 and the output is not empty:
Grep finished (matches found)
Otherwise:
Grep exited with status %d
These changes completely remove the case of status 1 that displayed
"finished with no matches found", and also remove the word "abnormally"
from the message of remaining cases, because we can't reliably determine
the case of "no matches found" by checking status 123 of a command line
that contains "xargs".
next prev parent reply other threads:[~2011-08-10 15:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 1:40 bug#9226: 23.3; [rgrep]; (matches found) ? Dave Abrahams
2011-08-10 7:16 ` Glenn Morris
2011-08-10 13:35 ` Stefan Monnier
2011-08-10 15:10 ` Juri Linkov [this message]
2011-08-17 14:52 ` Dave Abrahams
2011-08-17 15:02 ` Lennart Borgman
2011-08-17 16:50 ` Juri Linkov
2011-08-22 9:54 ` Juri Linkov
2011-09-17 18:24 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pqkdwblb.fsf@mail.jurta.org \
--to=juri@jurta.org \
--cc=9226@debbugs.gnu.org \
--cc=dave@boostpro.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).