grep is always recursive
loic.grenie at gmail.com
Wed Jan 28 13:51:57 UTC 2009
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:
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.
(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
More information about the ubuntu-users