GNU bug report logs - #56453
Bug reports

Previous Next

To reply to this bug, email your comments to 56453 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "GUI" <1678556598 <at> qq.com>
To: "bug-grep" <bug-grep <at> gnu.org>
Subject: Bug reports
Date: Fri, 8 Jul 2022 19:35:41 +0800

[Message part 1 (text/plain, inline)]

I'm a beginner for Linux.
Today, when I was learning the grep command, I used the man command to check its manual and found a suspicious point.In its DESCRIPTION,it says "grep  searches  for  PATTERN  in  each  FILE.   A FILE of ��-�� stands for standard input.  If no FILE is given, recursive searches examine the working directory, and nonrecursive searches read standard input.  By default, grep prints the matching lines. In addition, the variant programs egrep and fgrep are the  same  as  grep -E  and  grep -F,  respectively.   These  variants  are deprecated, but are provided for backward compatibility."
I think there are something wrong with the sentence 'If no FILE is given, recursive searches examine the working directory, and nonrecursive searches read standard input. ' . Pay attention to the 'and' in "recursive searches examine the working directory, and nonrecursive searches read standard input".When I use the grep command,such as this:


[root <at> localhost ~]# grep Download dwad dawdwa Downloads Downloads ^C [root <at> localhost ~]# 


From this result,we can see that if no file is given, nonrecursive searches read standard input instead of that rescursive searches examine the working directory.
As we known, the working directory is ~,whose subdirectories have 'Downloads'.So when you type grep Download on  terminal, you should see 'Downloads' under the current folder ~.
I don't know why or There is something wrong with the description of grep in the manual.

[Message part 2 (text/html, inline)]

Message #8 received at 56453 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: GUI <1678556598 <at> qq.com>
Cc: 56453 <at> debbugs.gnu.org
Subject: Re: bug#56453: Bug reports
Date: Fri, 8 Jul 2022 12:03:14 -0500

On 7/8/22 06:35, GUI via Bug reports for GNU grep wrote:
> [root <at> localhost ~]# grep Download dwad dawdwa Downloads Downloads ^C [root <at> localhost ~]#

It looks like you typed the string "grep Download dwad dawdwa Downloads 
Downloads" and then typed control-C. This caused the shell to not 
execute grep at all. You need to type a CARRIAGE RETURN (labeled "Enter" 
on most keyboards) to actually run grep.

Here's what happens when I run the command (properly entered) on my 
platform. grep matches its documentation here: since -r is not 
specified, the search is not recursive.

$ grep Download dwad dawdwa Downloads Downloads
grep: dwad: No such file or directory
grep: dawdwa: No such file or directory
grep: Downloads: Is a directory
grep: Downloads: Is a directory

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gary Johnson <garyjohn <at> spocom.com>
To: bug-grep <at> gnu.org
Subject: Re: bug#56453: Bug reports
Date: Fri, 8 Jul 2022 10:32:04 -0700

On 2022-07-08, GUI via Bug reports for GNU grep wrote:
> I'm a beginner for Linux.

> Today, when I was learning the grep command, I used the man
> command to check its manual and found a suspicious point.In its
> DESCRIPTION,it says "grep  searches  for  PATTERN  in  each  FILE.
> A FILE of “-” stands for standard input.  If no FILE is given,
> recursive searches examine the working directory, and nonrecursive
> searches read standard input.  By default, grep prints the
> matching lines. In addition, the variant programs egrep and fgrep
> are the  same  as  grep -E  and  grep -F,  respectively.   These
> variants  are deprecated, but are provided for backward
> compatibility."

> I think there are something wrong with the sentence 'If no FILE is
> given, recursive searches examine the working directory, and
> nonrecursive searches read standard input. ' . Pay attention to
> the 'and' in "recursive searches examine the working directory,
> and nonrecursive searches read standard input".When I use the grep
> command,such as this:

The sentence in the manual is correct as written.  Note that
a search can be recursive or nonrecursive, but not both.

> [root <at> localhost ~]# grep Download dwad dawdwa Downloads Downloads ^C
> [root <at> localhost ~]# 

> From this result,we can see that if no file is given, nonrecursive
> searches read standard input instead of that rescursive searches
> examine the working directory.

As that command appears in your post, a file _is_ given.  In fact,
four file names are given; the last two are the same file.

    grep Download dwad dawdwa Downloads Downloads

searches for the pattern Download in the files dwad, dawdwa,
Downloads and Downloads.  The search is nonrecursive since the
command does not include either the -r nor -R options are given.

The results indicate that the string Download is not found in any of
those files.  I don't know what the ^C at the end of your command
means.  ^C (Ctrl-C) normally kills the current command, but I don't
think you want to do that here.

> As we known, the working directory is ~,whose subdirectories have
> 'Downloads'.So when you type grep Download on  terminal, you
> should see 'Downloads' under the current folder ~.

I think you misunderstand what grep does.  Grep searches for
a pattern in the contents of files, or in the contents of its
standard input.  It does not search for a pattern in file names.

If you want to search for a pattern in the names of the files in
your working directory, use this pipeline instead:

    ls | grep Download

The ls command will list all the file names in your working
directory and grep will search that list for the string Download.

> I don't know why or There is something wrong with the description
> of grep in the manual.

The description is fine.  You just need a little more experience
with Linux commands and with interpreting the manual pages.  Their
English is usually correct, but not always clear.

Regards,
Gary

Message #16 received at 56453 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: GUI <1678556598 <at> qq.com>
Cc: 56453 <at> debbugs.gnu.org
Subject: Re: 回复： bug#56453: Bug reports
Date: Fri, 8 Jul 2022 22:42:50 -0500

On 7/8/22 21:53, GUI wrote:
> " If no FILE is given, recursive searches examine the working  directory,  and nonrecursive searches read standard input. "You use the word 'and' to say 'If no FILE is given' when this happens, 'recursive searches Examine the working directory' and 'nonrecursive searches read standard input'. This statement is inconsistent with the result of running in terminal.

Not at all. Several FILEs were given in your example:

> $ grep Download dwad dawdwa Downloads Downloads
> grep: dwad: No such file or directory
> grep: dawdwa: No such file or directory
> grep: Downloads: Is a directory
> grep: Downloads: Is a directory

Here 'dwad', 'dawdna', 'Downloads', and 'Downloads' are all FILEs. Since 
it's not the case that "no FILE is given", for your example it doesn't 
matter what the rest of that sentence says.

Message #19 received at 56453 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: GUI <1678556598 <at> qq.com>
Cc: 56453 <at> debbugs.gnu.org
Subject: Re: 回复： 回复： bug#56453: Bug reports
Date: Sat, 9 Jul 2022 13:24:09 -0500

On 7/9/22 05:16, GUI wrote:
> Thank you very much.I think there are something wrong with my expression.
>
> grep Download
>
> When you type something, hitting grep will do a row match
>
> The "grep Download" command has no file.So it is the case that"If no FILE is given, recursive searches examine the working  directory,  and nonrecursive searches read standard input. ".
>
> When I type the command,the terminal will do two things which are 'recursive searches Examine the working directory' and 'nonrecursive searches read standard input'.In this case, Download should be used as a matching string, but instead of going through all the files in the current directory, the terminal waits for the user's input.
>
> So I think it's a little different from what you wrote.
>

Plain "grep Download" does not use -r, so it's not recursive. Also, it 
specifies no FILE operands, so the sentence you quoted applies, and it 
searches standard input (in this case, the terminal).

The command "grep -r Download", in contrast, is nearly equivalent to 
"grep -r Download .". That is, it recursively searches the working 
directory, ignoring standard input.

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul Jackson" <pj <at> usa.net>
To: bug-grep <at> gnu.org
Subject: Re: bug#56453: 回复： bug#56453: Bug reports
Date: Sat, 09 Jul 2022 21:35:09 -0500

It might not be evident to some, but grep (and many similar commands) do NOT initially decide if a command line argument refers to a file or not by checking (with a stat(2) system call or similar) if the argument actually refers to a file.

Rather it's initial mode of operation is decided by the command line syntax.

If you ask for a recursive search, such as with a "-d recurse" action or a "-r" argument, it expects some directories and/or files to be named, within which it can look (if a file), or recurse (if a directory) to find files, which it then does by actually using a stat(2) or similar system call on the names it finds in the directories it traverses.

Otherwise grep expects some files to be named, which it can open and read, looking for the requested pattern, and in that non-recursive case, grep will complain if one of the names on the command line is a directory, not a file.  It won't realize that failure, however, until it tries to open and read the named item, and fails to do so when a directory is named.

Otherwise, if neither is named, or only a "-" file is named, it tries reading stdin (file descriptor 1) for the data it should search.

-- 
                Paul Jackson
                pj <at> usa.net

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.