grep is always recursive

[Loïc Grenié]

2009/1/28 Hal Burgiss <hal at burgiss.net>:
> On Tue, Jan 27, 2009 at 11:15:00PM -0400, Derek Broughton wrote:
>>
>> It's hardly fair to blame "Gnu" (or Linux, or *nix systems in
>> general).  It's possible to use practically anything for a file
>> name.  otoh, it is not _practical_ to use anything possible for a
>> filename.   Linux does a better job than some other OS's at handling
>> non-alphas in filenames, but it still isn't smart to use them as the
>> leading character.
>
> I understand that. I never would intentionally name a file like that.
> I have 12,800 files in ~, I never (or rarely) look at file listings
> visually. I use things like find and grep. This one was surely the
> result of some long forgotten command run amuck. It has been a thorn
> in my side for months. Had I known about it, it would not have been
> there for long.
>
>> >       grep [OPTIONS] PATTERN [FILE...]
>> >       grep [OPTIONS] [-e PATTERN | -f FILE] [FILE...]
>> >
>> > says anything other than OPTIONS come before PATTERN and FILEs come
>> > after. There clearly are ways to impart variable syntax.
>>
>> Except that conventionally man pages do _exactly_ that - and yet
>> options are not (normally) restricted to being before non-option
>> arguments.  So your suggestion does not remove the problem.  You
>> could use a BNF representation, but at the cost of making it
>> significantly harder  to understand for most of the people who need
>> the man page.
>
> a) I think overwhelmingly most people would look at that syntax and
> say OPTIONS comes before files. Without having to consult aging Unix
> masters for the finer points in implied man page synopsis
> interpretation. At some level, documentation should be clear, not
> implied or deduced. A personal opinion, of course.
>
> b) I have read man man, and man grep and have not seen a hint that
> this syntax should be interpreted in any way other than how it
> logically reads (ie how I read it :). Possibly, the explanation is
> there explicitly, hinted at, or ambiguously stated, but if so, I
> missed it. If not, it would not take much just say in the description
> "put options anywhere you feel like on the command line" or whatever.
> One sentence wouldn't muddy the works.

    I my man -L C grep I find:

ENVIRONMENT VARIABLES
[snip]
       POSIXLY_CORRECT
              If set,  grep  behaves  as  POSIX.2  requires;  otherwise,  grep
              behaves  more  like  other  GNU programs.  POSIX.2 requires that
              options that follow file names must be treated as file names; by
              default,  such  options are permuted to the front of the operand
              list and are treated as options.  Also,  POSIX.2  requires  that
              unrecognized  options  be diagnosed as "illegal", but since they
              are not really against the law the default is to  diagnose  them
              as      "invalid".       POSIXLY_CORRECT      also      disables
              _N_GNU_nonoption_argv_flags_, described below.

       _N_GNU_nonoption_argv_flags_
              (Here N is grep's numeric process ID.)  If the ith character  of
              this  environment variable's value is 1, do not consider the ith
              operand of grep to be an option, even if it appears to  be  one.
              A  shell  can  put  this  variable  in  the environment for each
              command it runs, specifying which operands are  the  results  of
              file name wildcard expansion and therefore should not be treated
              as options.  This behavior is available  only  with  the  GNU  C
              library, and only when POSIXLY_CORRECT is not set.

  I personally don't like that behavio[u]r either (and I've been Unixy since
  Sep 90, which makes me a relatively long timer). Personal taste I
  suspect...

          Aaaaanyway,

               Loïc