GNU bug report logs -
#75582
GNU grep 3.4 — enhancing manual
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75582 in the body.
You can then email your comments to 75582 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Wed, 15 Jan 2025 14:37:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Anton Samokat <samokat700 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-grep <at> gnu.org.
(Wed, 15 Jan 2025 14:37:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello
In *man grep* page, in the beginning, in the *description* section,
there is phrase:
/A FILE of “-” stands for standard input. If no FILE is given,
recursive searches examine the working directory, and nonrecursive
searches read standard input./
This is for GNU grep 3.4 in Ubuntu 20.04. At first read I thought that
this phrase is non accurate, that it have mistakes. I read and
understand it as follows:
/ If no FILE is given, recursively examine the working directory, and
nonrecursively read standard input./
/Which does not have sense./
/But t/his phrase is accurate and means the following: _If no FILE is
given, recursive searches (grep with -r option), examine the working
directory; nonrecursive searches (without -r option), read standard input._
Though it will be hard to get for non experienced user. Please, make it
more simple and straightforward, remove possible ambiguity. You can use
my version above or correct it as you prefer.
As I understand this ambiguity created related discussion on Unix &
Linux Stack Exchange: Why is "grep keyword" causing the terminal to
stand by forever? — https://unix.stackexchange.com/a/789609/585416
Thanks, Anton.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Wed, 15 Jan 2025 21:36:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 75582 <at> debbugs.gnu.org (full text, mbox):
On 2025-01-15 02:51, Anton Samokat wrote:
> Please, make it more simple and straightforward, remove possible ambiguity
Unfortunately these are competing goals.
Perhaps this would be better:
If no FILE is given read standard input, but if -r is given recursively
search the working directory instead.
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Thu, 16 Jan 2025 04:16:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 75582 <at> debbugs.gnu.org (full text, mbox):
On 2025-01-16 08:05, Paul Eggert wrote:
> On 2025-01-15 02:51, Anton Samokat wrote:
>> Please, make it more simple and straightforward, remove possible ambiguity
>
> Unfortunately these are competing goals.
>
> Perhaps this would be better:
>
> If no FILE is given read standard input, but if -r is given recursively
> search the working directory instead.
> [...]
Interesting. How about:
If no FILE is given, grep's behaviour depends on the -r (recursive)
option, which is disabled (non-recursive) by default:
- If non-recursive, then read standard input; otherwise
- If recursive, examine all files in the working directory,
including recursively descending into subdirectories.
No idea if this is good, bad, or indifferent... others can decide.
s-b etc.
Reply sent
to
Jim Meyering <jim <at> meyering.net>:
You have taken responsibility.
(Thu, 16 Jan 2025 05:03:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Anton Samokat <samokat700 <at> gmail.com>:
bug acknowledged by developer.
(Thu, 16 Jan 2025 05:03:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
On Wed, Jan 15, 2025 at 8:16 PM sur-behoffski
<sur-behoffski <at> grouse.com.au> wrote:
> On 2025-01-16 08:05, Paul Eggert wrote:
> > On 2025-01-15 02:51, Anton Samokat wrote:
> >> Please, make it more simple and straightforward, remove possible ambiguity
> >
> > Unfortunately these are competing goals.
> >
> > Perhaps this would be better:
> >
> > If no FILE is given read standard input, but if -r is given recursively
> > search the working directory instead.
> > [...]
>
> Interesting. How about:
>
> If no FILE is given, grep's behaviour depends on the -r (recursive)
> option, which is disabled (non-recursive) by default:
>
> - If non-recursive, then read standard input; otherwise
> - If recursive, examine all files in the working directory,
> including recursively descending into subdirectories.
>
> No idea if this is good, bad, or indifferent... others can decide.
Thanks for the suggestions. I went with Paul's (keeping it concise is
important), so --help now prints this:
When FILE is '-', read standard input. If no FILE is given, read standard
input, but with -r, recursively search the working directory instead. With
fewer than two FILEs, assume -h. Exit status is 0 if any line is selected,
1 otherwise; if any error occurs and -q is not given, the exit status is 2.
Here's the commit:
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=v3.11-56-gfc6aba9
Marking this as done.
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Fri, 17 Jan 2025 03:29:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
On 2025-01-16 15:32, Jim Meyering wrote:
> On Wed, Jan 15, 2025 at 8:16 PM sur-behoffski
> <sur-behoffski <at> grouse.com.au> wrote:
> [...]>
> Thanks for the suggestions. I went with Paul's (keeping it concise is
> important), so --help now prints this:
>
> When FILE is '-', read standard input. If no FILE is given, read standard
> input, but with -r, recursively search the working directory instead. With
> fewer than two FILEs, assume -h. Exit status is 0 if any line is selected,
> 1 otherwise; if any error occurs and -q is not given, the exit status is 2.
>
> Here's the commit:
> https://git.savannah.gnu.org/cgit/grep.git/commit/?id=v3.11-56-gfc6aba9
>
> Marking this as done.
----------------------------
Blending in documentation about -h immediately made me curious.
I've tried a quick test, and it seems grep 3.11's behaviour
doesn't match the new documentation:
~ $ mkdir grep-r
~ $ cd !$
cd grep-r
~/grep-r $ echo "Hello, world" >single.txt
~/grep-r $ grep -r llo
single.txt:Hello, world
~/grep-r $ ls -al
total 12
drwxr-xr-x 2 bjh bjh 4096 Jan 17 13:30 .
drwx--x--x 38 bjh bjh 4096 Jan 17 13:30 ..
-rw-r--r-- 1 bjh bjh 13 Jan 17 13:30 single.txt
~/grep-r $ grep --version
grep (GNU grep) 3.11
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others; see
<https://git.savannah.gnu.org/cgit/grep.git/tree/AUTHORS>.
grep -P uses PCRE2 10.44 2024-06-07
~/grep-r $
Note the match prefix "single.txt:" above.
----------------------------
Looking at grep's documentation for -h:
-h, --no-filename
Suppress the prefixing of file names on output. This is the default when there is
only one file (or only standard input) to search.
----------------------------
The discrepancy arises because recursion might dig up only
a single file to search, yet the assumption is that if -r is
specified (use recursion), simply assume many files, i.e.:
-H, --with-filename
Print the file name for each match. This is the default when there is more than one
file to search. This is a GNU extension.
I believe the behaviour is reasonable, as grep doesn't want
to get deeply into file counting associated with recursion,
but the behaviour mismatches the new documentation.
Reading the above a bit more, there may be confusion in the
documentation between "one file" and "one FILE" in the -h
entry. Also, an additional "-r implies -H" clause might be
worthwhile in e.g. the -r documentation.
----------------------------
Hope this helps,
s-b
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Fri, 17 Jan 2025 04:53:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
sur-behoffski wrote:
>> Blending in documentation about -h immediately made me curious.
Speaking off the cuff, without benefit of looking at the code or sufficient experimenting with the behavior, I would expect that:
By default, if more than one file argument is named on the command line or is potentially implied by the "-r" recursive option, grep prefixes each line of output with the file name in which it was found, whereas if only one file is explicitly named, or only the standard input is being searched, then grep suppresses the prefixing of file names on output. The "-h" and "-H" options override these defaults, to either never ("-h") or always ("-H") prefix each line of output with the file name in which it was found. If "-H" is specified and grep is searching its standard input, that input file name prefix is the string "(standard input)".
Clearly my previous paragraph fails the "keep word count parsimonious" mandate for man pages. Perhaps the two man page paragraphs, one for "-h" and the next one for "-H", could be combined into a single paragraph, derived from some parsimonious variant of my above paragraph, explaining both the "-h" and "-H" options.
--
Paul Jackson
jackson <at> fastmail.fm
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Fri, 17 Jan 2025 06:47:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
On 2025-01-16 20:51, jackson <at> fastmail.fm wrote:
> Clearly my previous paragraph fails the "keep word count parsimonious" mandate for man pages.
Yup.
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Fri, 17 Jan 2025 07:56:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
>> yup
However, perhaps my "little" essay answers some of sur-behoffski's considerations.
--
Paul Jackson
jackson <at> fastmail.fm
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Fri, 17 Jan 2025 18:31:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
With is rather like if ... else .... so maybe:
When FILE is '-', read standard input. If no FILE is given, with -r, recursively search the working directory instead, else read standard input. With fewer than two FILEs, assume -h. Exit status is 0 if any line is selected, 1 otherwise; if any error occurs and -q is not given, the exit status is 2.
On Thursday, January 16, 2025 at 12:03:41 AM EST, Jim Meyering <jim <at> meyering.net> wrote:
On Wed, Jan 15, 2025 at 8:16 PM sur-behoffski
<sur-behoffski <at> grouse.com.au> wrote:
> On 2025-01-16 08:05, Paul Eggert wrote:
> > On 2025-01-15 02:51, Anton Samokat wrote:
> >> Please, make it more simple and straightforward, remove possible ambiguity
> >
> > Unfortunately these are competing goals.
> >
> > Perhaps this would be better:
> >
> > If no FILE is given read standard input, but if -r is given recursively
> > search the working directory instead.
> > [...]
>
> Interesting. How about:
>
> If no FILE is given, grep's behaviour depends on the -r (recursive)
> option, which is disabled (non-recursive) by default:
>
> - If non-recursive, then read standard input; otherwise
> - If recursive, examine all files in the working directory,
> including recursively descending into subdirectories.
>
> No idea if this is good, bad, or indifferent... others can decide.
Thanks for the suggestions. I went with Paul's (keeping it concise is
important), so --help now prints this:
When FILE is '-', read standard input. If no FILE is given, read standard
input, but with -r, recursively search the working directory instead. With
fewer than two FILEs, assume -h. Exit status is 0 if any line is selected,
1 otherwise; if any error occurs and -q is not given, the exit status is 2.
Here's the commit:
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=v3.11-56-gfc6aba9
Marking this as done.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Fri, 17 Jan 2025 18:36:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Should both -r and file names raise an error?
$ grep -r xxx yyy zzzgrep: yyy: No such file or directorygrep: zzz: No such file or directory$
On Thursday, January 16, 2025 at 11:53:29 PM EST, jackson <at> fastmail.fm <jackson <at> fastmail.fm> wrote:
sur-behoffski wrote:
>> Blending in documentation about -h immediately made me curious.
Speaking off the cuff, without benefit of looking at the code or sufficient experimenting with the behavior, I would expect that:
By default, if more than one file argument is named on the command line or is potentially implied by the "-r" recursive option, grep prefixes each line of output with the file name in which it was found, whereas if only one file is explicitly named, or only the standard input is being searched, then grep suppresses the prefixing of file names on output. The "-h" and "-H" options override these defaults, to either never ("-h") or always ("-H") prefix each line of output with the file name in which it was found. If "-H" is specified and grep is searching its standard input, that input file name prefix is the string "(standard input)".
Clearly my previous paragraph fails the "keep word count parsimonious" mandate for man pages. Perhaps the two man page paragraphs, one for "-h" and the next one for "-H", could be combined into a single paragraph, derived from some parsimonious variant of my above paragraph, explaining both the "-h" and "-H" options.
--
Paul Jackson
jackson <at> fastmail.fm
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Sat, 18 Jan 2025 05:31:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 17, 2025 at 10:35 AM David G. Pickett <dgpickett <at> aol.com> wrote:
> Should both -r and file names raise an error?
>
> $ grep -r xxx yyy zzz
> grep: yyy: No such file or directory
> grep: zzz: No such file or directory
That is expected behavior.
In that case, you've made a legitimate request to search recursively
for "xxx" in yyy and zzz.
It would probably elicit no diagnostic if you had files or directories
named yyy and zzz.
Information forwarded
to
bug-grep <at> gnu.org:
bug#75582; Package
grep.
(Sat, 18 Jan 2025 17:36:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 75582-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
No -r activity?
On Saturday, January 18, 2025 at 12:30:01 AM EST, Jim Meyering <jim <at> meyering.net> wrote:
On Fri, Jan 17, 2025 at 10:35 AM David G. Pickett <dgpickett <at> aol.com> wrote:
> Should both -r and file names raise an error?
>
> $ grep -r xxx yyy zzz
> grep: yyy: No such file or directory
> grep: zzz: No such file or directory
That is expected behavior.
In that case, you've made a legitimate request to search recursively
for "xxx" in yyy and zzz.
It would probably elicit no diagnostic if you had files or directories
named yyy and zzz.
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 16 Feb 2025 12:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.