bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grep --directories option


From: Marcus Brinkmann
Subject: Re: Grep --directories option
Date: Fri, 30 May 2003 14:50:50 +0200
User-agent: Mutt/1.5.4i

On Fri, May 30, 2003 at 02:33:54PM +0200, Alfred M. Szmidt wrote:
> Anything that requires someone to make an config.cache with specific
> options is wrong.  As for relying on host_os, that might be OK, but I
> still think that just reverting this to the way grep-2.4.x was is
> better.

Now we have two discussions, one about grep and one about source
configuration in general.

In general, you have three options: running a test that can be resolved at
compile time, running a test that must be resolved by running the program on
the host machine, and setting options depending on the architecture string.

And for any of these there are situations where they are the right thing to
do.  There is no "Anything that requires someone to make an config.cache
with specific options is wrong" dogma.  I don't know where you got this
from, but certainly not from actually doing a lot of cross compilation like
I did (and thus I got to see a lot of any of the three cases).

Just as a hint, in particular for unknown architectures, there is often no
known good default.  That's exactly the reason why autoconf works with tests
and not with lists of defaults per host os string.

Now, for grep in particular, the reason to actually test the dir at runtime
is a different one:  It is because the behaviour of directories might change
from filesystem to filesystem.  So skipping those directories that on read
access return EISDIR and reading the others might be the best option.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]