Re: grep . /; echo $?

[Charles Levert]

* On Tuesday 2005-10-25 at 13:32:47 +0100, Julian Foad wrote:
> Charles Levert wrote:
> >
> >According to the grep(1p) POSIX "man page":
> [...]
> >This does not restrict GNU grep from being more
> >informative about what happened by documenting
> >and using many exit statuses that are greater
> >than 1 (e.g., open() error vs. read() error),
> 
> Sure, but that's not relevant to this thread as far as I can see.  This 
> thread is about whether to exit with an error, not about how detailed any 
> such error should be.

It should return an error when --directories=read
and it gets one from read().


> >>>`--directories=ACTION'
> >>>   If an input file is a directory, use ACTION to process it.  By
> >>>   default, ACTION is `read', which means that directories are read
> >>>   just as if they were ordinary files (some operating systems and
> >>>   filesystems disallow this, and will cause `grep' to print error
> >>>   messages for every directory or silently skip them).
> >>
> >>I don't know: it all seems a bit arbitrary and inconsistent.  What's the
> >>point of defaulting to ACTION="read" on systems that don't support it?
> >
> >Consistency (for grep) across OSes.  If OSes
> >are inconsistent, that is another issue; grep
> >should merely use its exit status to document
> >what actually happened at a lower level on the
> >OS on which it happens to be running.
> 
> So let me be clear.  You disagree with the current behaviour of silently 
> skipping unreadable directories on some systems.

"some" = inconsistency

But see last paragraph below.


> The default should remain "directories=read",

I didn't address that explicitly.  Should the
default be changed, however, it should be on all
systems, and it would be NEWS worthy.  I assume
one reason this was chosen as the default is
that it's what UNIX grep does.  (Is it?)


> and Grep should (on all systems) report an error if it 
> can't read a directory that it has been told to search in,

Yes, any time --directories=read, whether by
default or if explicitly set by the user.


> and we should 
> remove the words "or silently skip them" from the "info" quote above.  Yes?

Yes, to go along with the change in code.


> That is fine with me.  I would call this "removing unnecessary complexity". 
> I have a niggling feeling that somebody made a conscious effort to make it 
> behave the way it does; but that's the way of things: if a special case was 
> introduced for some reason but the reason wasn't documented, we can't be 
> expected to preserve it indefinitely.

I wasn't around then and from this I understand
that you weren't either.

Here's my point-of-view on usage.  Every single
use of grep is done with a purpose.  When it's
on a system where directories are readable,
then if --directories=read and some directories
are given on the command line, it means the user
hopes to hear about matches in the directories
themselves (with filenames, most presumably).
If it's not want the user wanted, then he'll be
annoyed by either result (reported matches there,
or read() errors) and should probably have used
--directories=skip, or not have provided them on
the command line (e.g., by using "find -type f"
or "*.[ch]").

By the way, I don't see any code (preprocessor
or other) in grep.c to set the default value
of --directories according to the target OS.
Neither do I see use of something like
'#if defined(EISDIR)' along with
'directories == READ_DIRECTORIES',
although it is used with
'directories == SKIP_DIRECTORIES'.  This means
that the behavior for --directories=read is the
same on every OS (unless there are OSes that fail
on open() for directories); i.e., there currently
does not seem to be any "complexity" for this.
That behavior is "silently skip them", so the
code and the doc should be changed together.
If anything, we'll need to add complexity to
propagate the error from read() and write
a message for it.  Should the code not be
changed, then it's "print error messages for
every directory" that should be removed to match
the code's behavior.