grep doubt
in [Shell]
|
Prev: Can sed match a choice of two?
Next: Comparing Files
From: Stephane CHAZELAS on 24 Apr 2008 12:22 2008-04-24, 17:55(+02), pk: > On Thursday 24 April 2008 17:44, Stephane CHAZELAS wrote: > >> A problem with most versions of grep that support the -R >> non-standard option is that it follows the symlinks (as if >> -follow was given to find). > > (do you mean -L?) Yes well, -L is the "more standard" version for the "more portable" -follow. > I understand that this may yield different results between > > find . ... | xargs grep > > and > > grep -R . > > ...but isn't following the symlinks the only sensible behavior for grep? > Or maybe I did not understand what you mean. Well, while it may be what you want in some cases, it generally isn't, as when you do "grep pattern directory", you want do know if "pattern" is in any file in that directory tree, and not in any other directory tree linked to it, especially when you consider that all the other commands that do recurse into subdirectories (ls, find, zsh's **/, chown, chgrp, chmod...) do not by default (exception for chown/chgrp on some systems). That means you may endup looking at the same files twice or more, also consider the case of a symlink to "/" for instance. At least, grep should have an option for disabling it. -- St�phane
From: pk on 24 Apr 2008 12:40 On Thursday 24 April 2008 18:22, Stephane CHAZELAS wrote: >> ...but isn't following the symlinks the only sensible behavior for grep? >> Or maybe I did not understand what you mean. > > Well, while it may be what you want in some cases, it generally > isn't, as when you do "grep pattern directory", you want do > know if "pattern" is in any file in that directory tree, and not > in any other directory tree linked to it, especially when you > consider that all the other commands that do recurse into > subdirectories (ls, find, zsh's **/, chown, chgrp, chmod...) do > not by default (exception for chown/chgrp on some systems). > > That means you may endup looking at the same files twice or > more, also consider the case of a symlink to "/" for instance. > At least, grep should have an option for disabling it. Ah ok. While the programs you mention act upon file metadata, and thus not following links make sense, grep acts upon file content, so to me it seemed kind of pointless for grep to look for the pattern inside the link (which contains just the pointed-to filename). If such an option existed, it would better make grep ignore symlinks altogether, rather than trying to read them, imho. -- All the commands are tested with bash and GNU tools, so they may use nonstandard features. I try to mention when something is nonstandard (if I'm aware of that), but I may miss something. Corrections are welcome.
From: apogeusistemas on 24 Apr 2008 12:47 On Apr 24, 1:40 pm, pk <p...(a)pk.invalid> wrote: > On Thursday 24 April 2008 18:22, Stephane CHAZELAS wrote: > > >> ...but isn't following the symlinks the only sensible behavior for grep? > >> Or maybe I did not understand what you mean. > > > Well, while it may be what you want in some cases, it generally > > isn't, as when you do "grep pattern directory", you want do > > know if "pattern" is in any file in that directory tree, and not > > in any other directory tree linked to it, especially when you > > consider that all the other commands that do recurse into > > subdirectories (ls, find, zsh's **/, chown, chgrp, chmod...) do > > not by default (exception for chown/chgrp on some systems). > > > That means you may endup looking at the same files twice or > > more, also consider the case of a symlink to "/" for instance. > > At least, grep should have an option for disabling it. > > Ah ok. While the programs you mention act upon file metadata, and thus not > following links make sense, grep acts upon file content, so to me it seemed > kind of pointless for grep to look for the pattern inside the link (which > contains just the pointed-to filename). If such an option existed, it would > better make grep ignore symlinks altogether, rather than trying to read > them, imho. > > -- > All the commands are tested with bash and GNU tools, so they may use > nonstandard features. I try to mention when something is nonstandard (if > I'm aware of that), but I may miss something. Corrections are welcome. I made this script and now it works fine... for file in `find . -type f` do grep -w ALTER $file >> /apl/applprox/script1_output grep -w MODIFY $file >> /apl/applprox/script1_output grep -w REPLACE $file >> /apl/applprox/script1_output done Thank you...
From: OldSchool on 24 Apr 2008 15:37
On Apr 24, 9:25 am, apogeusiste...(a)gmail.com wrote: > for file in `ls -R` > do > grep -iw alter $file > /apl/applprox/script1_output > grep -iw modify $file >> /apl/applprox/script1_output > grep -iw replace $file >> /apl/applprox/script1_output > done > > grep: can't open OEXWFOIB.pls > grep: can't open OEXWFOIB.pls > grep: can't open OEXXLINB.pls one of the potential issues w/ the "ls -R" construct is that while you get at list of files in sub-directories, you don't know where the are. The grep is looking for them in the current working directory only regardless of where they really are |