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:
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/
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.
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
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(?)
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:
cd to
/home/your id/Documents
directory.
copy
/etc/YaST2/licenses/base/license.txt
to current dir.
issue
cd …
to go up one level.
copy
/etc/YaST2/licenses/base/license.txt
to current dir.
issue command:
fgrep -irn 'public' *.txt
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
issue
fgrep -irn 'public' *
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.
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.
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.