grep recurse fails

[MMARAIS]

Hi,

When using grep or fgrep like the following, if a sub-directory starting
with "---" is present in the current directory, grep fails with the
message "grep: unknown option  « ---<<directory name>> »"

Example :

$ ls
profil.centrapel.com
---recrutement.centrapel.com
recrutement.centrapel.com

$ fgrep -R "find me" *.*
grep: option non reconnue « ---recrutement.centrapel.com »

$ cat /proc/version
Linux version 2.4.27-3-686-smp (horms@...) (gcc
version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Wed Feb 8 12:27:28 UTC 2006

$ fgrep --version
fgrep (grep de GNU) 2.5.1

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de
reproduction. AUCUNE garantie n'est donnée; tant pour des raisons
COMMERCIALES que pour RÉPONDRE À UN BESOIN PARTICULIER.

Thanks.

--
Maxime MARAIS
Pôle Développement
Poste 5321 - 0173502307

[Dave B-6]

On Monday 12 October 2009, CENTRAPEL - Maxime MARAIS wrote:

> Hi,
>
> When using grep or fgrep like the following, if a sub-directory starting
> with "---" is present in the current directory, grep fails with the
> message "grep: unknown option  « ---<<directory name>> »"
>
> Example :
>
> $ ls
> profil.centrapel.com
> ---recrutement.centrapel.com
> recrutement.centrapel.com
>
> $ fgrep -R "find me" *.*

fgrep -R -- "find me" *.*

--
D.

[John Cowan]

Dave B scripsit:

> > When using grep or fgrep like the following, if a sub-directory starting
> > with "---" is present in the current directory, grep fails with the
> > message "grep: unknown option  « ---<<directory name>> »"
> >
> > Example :
> >
> > $ ls
> > profil.centrapel.com
> > ---recrutement.centrapel.com
> > recrutement.centrapel.com
> >
> > $ fgrep -R "find me" *.*
>
> fgrep -R -- "find me" *.*

That works, but it's still a bug that grep recognizes options after the
pattern argument has been given.

--
There is / One art                      John Cowan <cowan@...>
No more / No less                       http://www.ccil.org/~cowan
To do / All things
With art- / Lessness                     --Piet Hein

[Dave B-6]

On Monday 12 October 2009, John Cowan wrote:

> Dave B scripsit:
> > > When using grep or fgrep like the following, if a sub-directory
> > > starting with "---" is present in the current directory, grep fails
> > > with the message "grep: unknown option  « ---<<directory name>> »"
> > >
> > > Example :
> > >
> > > $ ls
> > > profil.centrapel.com
> > > ---recrutement.centrapel.com
> > > recrutement.centrapel.com
> > >
> > > $ fgrep -R "find me" *.*
> >
> > fgrep -R -- "find me" *.*
>
> That works, but it's still a bug that grep recognizes options after the
> pattern argument has been given.

I'm not sure that would be a bug. I've found nothing in POSIX that says that
behavior is illegal, and that the pattern must be the last argument. This is
from the "utility syntax guideline":

Guideline 14:
    If an argument can be identified according to Guidelines 3 through 10 as
an option, or as a group of options without option-arguments behind one '-'
delimiter, then it should be treated as such.

That seems to imply that, unless -- is used (guideline 10), options can and
should be catched and recognized anywhere in the command line. But of course
that's just my interpretation.

--
D.

[Andreas Schwab-2]

John Cowan <cowan@...> writes:

> That works, but it's still a bug that grep recognizes options after the
> pattern argument has been given.

export POSIXLY_CORRECT=1

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Dave B-6]

On Monday 12 October 2009, Andreas Schwab wrote:

> John Cowan <cowan@...> writes:
> > That works, but it's still a bug that grep recognizes options after the
> > pattern argument has been given.
>
> export POSIXLY_CORRECT=1

This is interesting. Using that makes grep (and I suppose all the utilities
that honour that) ignore options after operands, which is what guideline 9
says.

"All options should precede operands on the command line."

with "should" interpreted as "shall" as explained later. But then what's the
meaning of rule 14, and how would that be supposed to be enforced when
POSIXLY_CORRECT is set? It would seem to be clashing with 9.

Thanks.

--
D.

[Eric Blake]

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

According to Dave B on 10/12/2009 9:22 AM:
> with "should" interpreted as "shall" as explained later. But then what's the
> meaning of rule 14, and how would that be supposed to be enforced when
> POSIXLY_CORRECT is set? It would seem to be clashing with 9.

POSIX rules only hold when POSIXLY_CORRECT is set.  Rule 14 states that:

foo -b -ar

should be recognized as

foo -b -a -r

and not

foo -b ./-ar

if all of -b, -a, and -r are recognized options (historically, not all
utilities followed this rule: for example, 'set -vx' behaved differently
than 'set -v -x').  Rule 9 states that, when complying with POSIX:

foo a -b

will be treated like

foo a ./-b

even though -b is recognized.  There is no conflict between 9 and 14.  But
GNU Coding Standards recommend that, unless reorganizing arguments will
break the tool's semantics (think xargs, env, sudo), then reorganizing is
in the user's favor, so:

foo a -b

is treated like

foo -b a

Finally, both POSIX and GNU Coding Standards state that:

foo -- -bar a

is treated like

foo ./-bar a

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrT56wACgkQ84KuGfSFAYC58ACgybfJd6tC4PuHrAHsVby5bY69
yNAAoJ+ENtCMIZPZ/69jhvULWACDMLLE
=VsZ8
-----END PGP SIGNATURE-----

[Dave B-6]

On Tuesday 13 October 2009, Eric Blake wrote:

> According to Dave B on 10/12/2009 9:22 AM:
> > with "should" interpreted as "shall" as explained later. But then what's
> > the meaning of rule 14, and how would that be supposed to be enforced
> > when POSIXLY_CORRECT is set? It would seem to be clashing with 9.
>
> POSIX rules only hold when POSIXLY_CORRECT is set.  Rule 14 states that:
>
> foo -b -ar
>
> should be recognized as
>
> foo -b -a -r
>
> and not
>
> foo -b ./-ar
>
> if all of -b, -a, and -r are recognized options (historically, not all
> utilities followed this rule: for example, 'set -vx' behaved differently
> than 'set -v -x').

Ah, then my interpretation was different. I read it as meaning that

foo -b blah -r

should be interpreted as

foo -b -r blah

or even as

foo -br blah

if -b and -r are valid options. But then I was wrong.

> Rule 9 states that, when complying with POSIX:
>
> foo a -b
>
> will be treated like
>
> foo a ./-b
>
> even though -b is recognized.  There is no conflict between 9 and 14.  But
> GNU Coding Standards recommend that, unless reorganizing arguments will
> break the tool's semantics (think xargs, env, sudo), then reorganizing is
> in the user's favor, so:
>
> foo a -b
>
> is treated like
>
> foo -b a

Ah, so that's a GNU thing. Thank you very much for the clarification.

--
D.