grep and recursive -r - not working

works fine on a FAT32 dsk:

fgrep -iRn -C 2 'print' *.txt

—also recurses one level and displays all kinds of data

in root / ext4 directory:

fgrep -iRn -C 2 'print' *.* or fgrep -iRn -C 2 'print' *.txt

—displays msgs:
fgrep: .: No such file or directory
and
fgrep: *.txt: No such file or directory

I am probably missing something very basic.

recursive does not seem to work from root directory. Is this (as they used to say) a feeture? :’(

This is on an 11.2 system, upgraded to 11.3 (ran zypper verify to verify. According to it… all is well).

Thnks…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I believe this is a feature. You are saying to match *.txt, and I doubt
you have any directories matching that so then recursion does not happen
into those directories. A better way to do this, imo, follows:

find / -type f -iname *.txt | xargs grep -in -C 2 ‘print’

Good luck.

On 08/09/2010 02:06 PM, danperecky wrote:
>
> works fine on a FAT32 dsk:
>
> Code:
> --------------------
> fgrep -iRn -C 2 ‘print’ *.txt
> --------------------
>
>
> —also recurses one level and displays all kinds of data
> ---------------------------------------------------------------
> in root / ext4 directory:
>
> Code:
> --------------------
> fgrep -iRn -C 2 ‘print’ . or fgrep -iRn -C 2 ‘print’ *.txt
> --------------------
>
>
> —displays msgs:
> fgrep: .: No such file or directory
> and
> fgrep: *.txt: No such file or directory
>
>
> I am probably missing something very basic.
>
> recursive does not seem to work from root directory. Is this (as they
> used to say) a feeture? :’(
>
> This is on an 11.2 system, upgraded to 11.3 (ran zypper verify to
> verify. According to it… all is well).
>
> Thnks…
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMYGC/AAoJEF+XTK08PnB5hnAP/jlbovJrJnsGsBsMYpA350Sd
9M+x9U28wolZ2L18k76H1slQjR64HIpg5qP5PBCqgUVR90cZ2Dpb6//0WKsrCYJL
u6ThFiMM8R4wN/bU811uuqwZkrxmVGcuj/gdyAoHpVVwmXCrlWsGoveYTF6+BMHy
PtqeML14vAGlbDEmmIrtmkOTfUZhg2iI5i0tp20EKjY/+0dYwF3tb27WKC+wii4J
gcEjWwyApyDzJjKhjHK9FZCQ4OlZ47xOxWozCemGrNJIhbCOWe59+bKbBQ0di5NL
psHuldH22mNiPgZv4lhXFTd+4dHeTxqhVcWzZQb/tUPJyQL1k7ZuOAytopneTwYv
qL1iC2iHyLqwcXlmweNo/4fy/sV644Uua8i/o0dV6DVKz9b5BYur+d9sO11YsQst
txMJ4AkERO5qpZFWgf8FUZIew859P9xbi/wqbHPbxzhEK6R/dsvQAmboQQN/gYUt
H1oV6JQiNHeS82aExUomGV4cvfT+phkIgsa3MriS35Uc3gPRg7cEcXDdsOzmWLFq
bF/16D69CicX4FdmQ26gEOcxYpH/52DXVYWWCPZJKiBF0WRqGYn+NMm2DWjvKYYx
Kjg1eAM3vVRLkdSxfEgTqoICk+zGzbGF4v3iP5P5E4E4Egk9ioRvy70KKLOJkElz
Nrzs711qEXxiG8to/GC3
=MX1H
-----END PGP SIGNATURE-----

How do you think this is functioning?

Even if one does not know what all the arguments in

fgrep -iRn -C 2 'print' *.* or fgrep -iRn -C 2 'print' *.txt

should do, the shell comes first and will try to expand . and .text. I assume there is no file in /* that answers to that pattern, thus those arguments stay as they are. And then later fgrep gets . as an argument and tries to find (literaly) that file. Which does not exist. same for* .text. And it tells you so.

And in the first case I suppose that the names that match the pattern *.txt are files, not directories. You can walk down the file tree along directories, but not along files.

ab@novell.com wrote:

find / -type f -iname *.txt | xargs grep -in -C 2 ‘print’

Thanks… it’s elegant and works very nicely.

A quick related question…

I added

2> /dev/null
to direct error msgs to null. This only worked for the ‘grep’ part, I believe… as error msgs still appeared from ‘find’:
find: ‘xfn’: Permission denied

Is there a way to redirect these msgs as well?

Henk wrote:

And in the first case I suppose that the names that match the pattern *.txt are files, not directories. You can walk down the file tree along directories, but not along files.

I may be off, but I think it’s the other way around… files<->directories(?)

And… is this a bug?

Thanks

find / -type f -iname *.txt 2>/dev/null | xargs grep -in -C 2 'print' 2>/dev/null

Ken_Yap… Works great… thnks.

So, is this a bug?

Is what a bug?

Thank you for your help with ‘find’ and ‘grep’. But if grep would recurse from the root ‘/’ directory when specified, none of those workarounds would be necessary… I’m thinking.

I may have missed it, but AFAIK there is no clause for the -r option in the man pages that state that the grep -r command option will not work from root. :?

What is your evidence that grep doesn’t work starting from /? It’ll probably take far too long and may even get stuck reading devices in /dev if you are root, but in principle it works. AFAICT you didn’t understand how wildcards work.

Sorry, but it appears that I was unclear about the original anomaly. I still think that there is a problem. Maybe this will clarify it somewhat. I want to scan only *.txt file type documents. This does not seem to be possible with only fgrep. Try this if you would:

  1. cd to

/home/your id/Documents
directory.

  1. copy

/etc/YaST2/licenses/base/license.txt
to current dir.

  1. issue

cd …
to go up one level.

  1. copy

/etc/YaST2/licenses/base/license.txt
to current dir.

  1. issue command:
fgrep -irn 'public' *.txt
  1. you will see one instance (I think) where ‘public’ is found in the license.txt file.
    6a. This should have, as I understand it, found at least two instances- one in

/home/your id/
and one in
/home/your id/Documents

  1. issue
fgrep -irn 'public' *
  1. fgrep will then traverse the directories recursively and search all files (including both license.txt files in the current directory and sub-directory).

The same disfunction occurs when starting from the root directory. I’m thinking that fgrep should recurse when *.txt is specified as a file type (and there are no *.txt files in the root dir).

According to the man pages, the fgrep -r option should:

-R, -r, --recursive
Read all files under each directory, recursively; this is
equivalent to the -d recurse option.

Recursing not supposed to, AFAIK depend upon the file type that fgrep is searching in. Maybe I’m still thinking too much like a DOS user. If I’m off, please let me know. If you have any questions, please let me know.

This is how your command works:

fgrep -irn 'public' *.txt

First of all, even before fgrep is invoked, the shell expands the pattern *.txt. If there are any files matching that pattern, say license.txt and warning.txt, then it will appear to fgrep as you had typed in:

fgrep -irn 'public' license.txt warning.txt

However if there are no files matching the pattern, then fgrep will get:

fgrep -irn 'public' *.txt

However fgrep doesn’t do anything with wildcards so it will try to look for a file that’s named *.txt literally. Since there is probably no such file in the directory, it will say cannot open *.txt.

Your error is thinking that fgrep does the patten expansion. It doesn’t. It’s done by the shell. And there are no “file types” enforced by the OS. The suffix is an application level convention.

ken_yapp wrote:

Your error is thinking that fgrep does the patten expansion. It doesn’t. It’s done by the shell. And there are no “file types” enforced by the OS. The suffix is an application level convention.

This was not obvious or intuitive to me (as you can tell). I guess I need to read up on shells. Thank you for shedding some valuable light on this aspect of the mechanism and operation of linux commands.