grep -R (skip symlinks)

[James]

How to recursive grep skipping symlink directories?

TIA
James

[Ben Bacarisse]

James <hsle...@yahoo.com> writes:

> How to recursive grep skipping symlink directories?

My man page says:

-r, --recursive
Read all files under each directory, recursively, following
symbolic links only if they are on the command line. This is
equivalent to the -d recurse option.

do you not have a similar version of grep or does that not do what you
want?

If you don't have the -r option (and I see it's not POSIX) you'll have
to cobble something together using find and grep.

--
Ben.

[Barry Margolin]

In article <dcc95c89-12fa-49c0...@googlegroups.com>,

According to
http://stackoverflow.com/questions/21738574/how-do-you-exclude-symlinks-i
n-a-grep since version 2.11-8 GNU grep follows symlinks if you use -R,
but skips them if you use -r.

If you're not using GNU grep, or you have an older version, you can use
find instead of grep -r.

find $dir -type f -exec grep $pattern {} +

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[James]

> According to
> http://stackoverflow.com/questions/21738574/how-do-you-exclude-symlinks-i
> n-a-grep since version 2.11-8 GNU grep follows symlinks if you use -R,
> but skips them if you use -r.
>
> If you're not using GNU grep, or you have an older version, you can use
> find instead of grep -r.
>
> find $dir -type f -exec grep $pattern {} +
>
> --

My grep is old, so will use grep/find combo.
Thanks.

James

[Geoff Clare]

Barry Margolin wrote:

> find $dir -type f -exec grep $pattern {} +

Tip: if you stick in a /dev/null before the {}, this ensures that the
grep output is all in the form "pathname:matching_line", even if find
expands {} to only one pathname on the last execution of grep.

(Also you should quote the variables, and use "--" in case they
begin with "-")

find -- "$dir" -type f -exec grep -- "$pattern" /dev/null {} +

--
Geoff Clare <net...@gclare.org.uk>

[Barry Margolin]

In article <fc9e0d-...@ID-313840.user.individual.net>,

Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:

> Barry Margolin wrote:
>
> > find $dir -type f -exec grep $pattern {} +
>
> Tip: if you stick in a /dev/null before the {}, this ensures that the
> grep output is all in the form "pathname:matching_line", even if find
> expands {} to only one pathname on the last execution of grep.

You can also use the -H option, which makes it include the filename in
all matches, unless you're using a really ancient version of grep.

>
> (Also you should quote the variables, and use "--" in case they
> begin with "-")

Yeah, I was being sloppy.

>
> find -- "$dir" -type f -exec grep -- "$pattern" /dev/null {} +

--

[Geoff Clare]

Barry Margolin wrote:

> Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:
>
>> Barry Margolin wrote:
>>
>> > find $dir -type f -exec grep $pattern {} +
>>
>> Tip: if you stick in a /dev/null before the {}, this ensures that the
>> grep output is all in the form "pathname:matching_line", even if find
>> expands {} to only one pathname on the last execution of grep.
>
> You can also use the -H option, which makes it include the filename in
> all matches, unless you're using a really ancient version of grep.

$ grep -H foo
grep: illegal option -- H
Usage: [...]
$ ls -l $(command -v grep)
-r-xr-xr-x 3 root bin 22060 Feb 19 2013 /usr/xpg4/bin/grep

I wouldn't call 2013 "really ancient".

--
Geoff Clare <net...@gclare.org.uk>

[Janis Papanagnou]

Erm.., "Feb 19 2013" is the date of the installation, not the age of the
tool. But the key information here is "xpg4"; IOW, option -H seems to be
non-standard.

Janis

[Barry Margolin]

In article <nh4jct$4e1$1...@news.m-online.net>,

Yeah, it's a GNU grep feature. And I think I've been using it for at
least 10 years.

[Stephane Chazelas]

2016-05-12 13:26:23 +0100, Geoff Clare:

[...]

Unfortunately, for "find", "--" hardly helps, you'd still have a
problem for file names that look like predicates ("!", "(", ")"
and anything starting with "-" at least).

If dir is "-H" for instance, "--" would stop it being recognised
as the "-H" option, but find would still complain about an
unknown predicate.

You'd need:

case $dir in
([./]* | "") ;;
(*) dir=./$dir;;
esac

find "$dir" -type f -exec grep -- "$pattern" /dev/null {} +

--
Stephane

[Barry Margolin]

In article <20160514141...@chaz.gmail.com>,

BSD find solved with the -f option, whose parameter is always taken as a
filename.

find -f "$dir" -type f ...

But this doesn't seem to be in GNU find or POSIX find.

[Geoff Clare]

Well, you learn something new every day. Must be to do with the new
packaging system in Solaris 11. I'm sure Solaris releases up to 10
preserved the timestamp of system binaries as they were installed,
instead of setting them to the current time.

What still puzzles me is that shell scripts are not treated the same:

$ ls -l /usr/xpg4/bin/batch
-r-xr-xr-x 1 root bin 417 Oct 21 2011 /usr/xpg4/bin/batch
$ file /usr/xpg4/bin/batch
/usr/xpg4/bin/batch: executable /usr/bin/sh script

So this is not just a simple matter of the installation doing an
extraction from an archive/package file without preserving timestamps.

--
Geoff Clare <net...@gclare.org.uk>

[Janis Papanagnou]

What I was saying is just that a file timestamp is not indicating how old
[the version of] the tool is; the previous poster asked about the age of
the version of the tool. This is independent of preserving the timestamp
of the compilation on installation, if the compilation was done on an old
version of the tool. If Solaris' tools are continuously updated that's no
issue. But from the given data we just can't tell. So in absence of some
information like --version provides, the 'xpg4' part is the best hint on
what we have.

Janis

[Kaz Kylheku]

On 2016-05-16, Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:
> Janis Papanagnou wrote:
>
>> On 13.05.2016 14:26, Geoff Clare wrote:
>
>>> $ ls -l $(command -v grep)
>>> -r-xr-xr-x 3 root bin 22060 Feb 19 2013 /usr/xpg4/bin/grep
>>>
>>> I wouldn't call 2013 "really ancient".
>>
>> Erm.., "Feb 19 2013" is the date of the installation, not the age of the
>> tool.
>
> Well, you learn something new every day. Must be to do with the new
> packaging system in Solaris 11. I'm sure Solaris releases up to 10
> preserved the timestamp of system binaries as they were installed,
> instead of setting them to the current time.

What is the difference between "timestamp .. as they were installed" and
"date of the installation"?

Moreover, if some program that hadn't been maintained since, say, 1984
is built in 2013, it gets a 2013 timestamp.

Being built in 2013 doesn't reduce the "age of the tool" from 32 years
to 3.

> What still puzzles me is that shell scripts are not treated the same:
>
> $ ls -l /usr/xpg4/bin/batch
> -r-xr-xr-x 1 root bin 417 Oct 21 2011 /usr/xpg4/bin/batch
> $ file /usr/xpg4/bin/batch
> /usr/xpg4/bin/batch: executable /usr/bin/sh script
>
> So this is not just a simple matter of the installation doing an
> extraction from an archive/package file without preserving timestamps.

These files are not built. They probably sit verbatim in a version control
system, and the installation perhaps takes the timestamp derived from
their version control timestamp.

[Geoff Clare]

Kaz Kylheku wrote:

> On 2016-05-16, Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:
>> Janis Papanagnou wrote:
>>
>>> On 13.05.2016 14:26, Geoff Clare wrote:
>>
>>>> $ ls -l $(command -v grep)
>>>> -r-xr-xr-x 3 root bin 22060 Feb 19 2013 /usr/xpg4/bin/grep
>>>>
>>>> I wouldn't call 2013 "really ancient".
>>>
>>> Erm.., "Feb 19 2013" is the date of the installation, not the age of the
>>> tool.
>>
>> Well, you learn something new every day. Must be to do with the new
>> packaging system in Solaris 11. I'm sure Solaris releases up to 10
>> preserved the timestamp of system binaries as they were installed,
>> instead of setting them to the current time.
>
> What is the difference between "timestamp .. as they were installed" and
> "date of the installation"?

I had assumed that Feb 19, 2013 was the date the binaries were built
by Oracle, and that the installation process preserved that timestamp.
After Janis's comment, I poked around a bit and realised that Feb 19,
2013 was the date the system in question was updated from Solaris 11 to
11.1. This means the binaries must have had their timestamp set to the
current time as they were installed (by the update process).

>> What still puzzles me is that shell scripts are not treated the same:
>>
>> $ ls -l /usr/xpg4/bin/batch
>> -r-xr-xr-x 1 root bin 417 Oct 21 2011 /usr/xpg4/bin/batch
>> $ file /usr/xpg4/bin/batch
>> /usr/xpg4/bin/batch: executable /usr/bin/sh script
>>
>> So this is not just a simple matter of the installation doing an
>> extraction from an archive/package file without preserving timestamps.
>
> These files are not built. They probably sit verbatim in a version control
> system, and the installation perhaps takes the timestamp derived from
> their version control timestamp.

Having poked around some more, I think the explanation is that the
original Solaris 11 installation preserved timestamps, but the update
from 11 to 11.1 did not. So the files with the Oct 21, 2011 timestamp
are ones that were not included in the 11.1 update. In /usr/xpg4/bin
it just happened that the binaries were updated in 11.1 and the scripts
were not. There are some binaries with the 2011 date in /usr/bin.

--
Geoff Clare <net...@gclare.org.uk>

[Joerg.S...@fokus.fraunhofer.de]

In article <m1to0d-...@ID-313840.user.individual.net>,

Geoff Clare <net...@gclare.org.uk> wrote:
>Janis Papanagnou wrote:
>
>> On 13.05.2016 14:26, Geoff Clare wrote:
>
>>> $ ls -l $(command -v grep)
>>> -r-xr-xr-x 3 root bin 22060 Feb 19 2013 /usr/xpg4/bin/grep
>>>
>>> I wouldn't call 2013 "really ancient".
>>
>> Erm.., "Feb 19 2013" is the date of the installation, not the age of the
>> tool.
>
>Well, you learn something new every day. Must be to do with the new
>packaging system in Solaris 11. I'm sure Solaris releases up to 10
>preserved the timestamp of system binaries as they were installed,
>instead of setting them to the current time.

What usually helps is to check the ELF comments, e.g.:

mcs -p /usr/xpg4/bin/grep
/usr/xpg4/bin/grep:

@(#)SunOS 5.11 snv_130 November 2008

--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[Geoff Clare]

Joerg.Schilling wrote:

> In article <m1to0d-...@ID-313840.user.individual.net>,
> Geoff Clare <net...@gclare.org.uk> wrote:
>>Janis Papanagnou wrote:
>>
>>> On 13.05.2016 14:26, Geoff Clare wrote:
>>
>>>> $ ls -l $(command -v grep)
>>>> -r-xr-xr-x 3 root bin 22060 Feb 19 2013 /usr/xpg4/bin/grep
>>>>
>>>> I wouldn't call 2013 "really ancient".
>>>
>>> Erm.., "Feb 19 2013" is the date of the installation, not the age of the
>>> tool.
>>
>>Well, you learn something new every day. Must be to do with the new
>>packaging system in Solaris 11. I'm sure Solaris releases up to 10
>>preserved the timestamp of system binaries as they were installed,
>>instead of setting them to the current time.
>
> What usually helps is to check the ELF comments, e.g.:
>
> mcs -p /usr/xpg4/bin/grep
> /usr/xpg4/bin/grep:
>
> @(#)SunOS 5.11 snv_130 November 2008

That produces no output on my Solaris 11.1 system. Looks like the
ELF .comment section has been deleted (confirmed with elfdump -c).

I also get no output from "what /usr/xpg4/bin/grep" which would
find the line in your example mcs output, if it was in there.

--
Geoff Clare <net...@gclare.org.uk>

[Kaz Kylheku]

On 2016-05-18, Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:

> Joerg.Schilling wrote:
>> What usually helps is to check the ELF comments, e.g.:
>>
>> mcs -p /usr/xpg4/bin/grep
>> /usr/xpg4/bin/grep:
>>
>> @(#)SunOS 5.11 snv_130 November 2008
>
> That produces no output on my Solaris 11.1 system. Looks like the
> ELF .comment section has been deleted (confirmed with elfdump -c).

What with storage devices continuously shrinking year by year, you have
to scrape for every byte.