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
The code is equivalent to this:
if (! fillbuf (save, stats))
if (! is_EISDIR (errno, file) && ! suppress_errors)
error (filename, errno);
This indeed is a bug as it ignores all errors related to reading dirs.
If there is a disk error while reading dir on GNU/Hurd
You are wrong. Obviously such a test can not be run when cross
compiling, but that is true for all tests where you need to run a
program (note that the above is meant as an actual C program doing
a mkdir() and a read()).
And when cross compiling, either the user has to specify the
On Fri, May 30, 2003 at 02:05:42PM +0200, Alfred M. Szmidt wrote:
>> How to differentiate these systems I don't know, maybe a "mkdir
>> foo; cat foo"? Or just using host_os
>
>Thank you very much. I think this is the best solution.
>
> I think this is a bad solution, what about cros
> cat works differently on GNU/Linux and GNU/Hurd, might be worth
> taking a peek at how it does this stuff.
exactly the same way as grep-2.4.2: it doesn't treat dirs
specifically.
It tries to open the file, if it's OK, it proceeds, if there is an
error, it reports it.
Ahh! Can
> How to differentiate these systems I don't know, maybe a "mkdir
> foo; cat foo"? Or just using host_os
Thank you very much. I think this is the best solution.
I think this is a bad solution, what about cross-compilation? You
will compile with crazy options for the target system.
_
Hi,
On Fri, May 30, 2003 at 01:49:27PM +0200, Alfred M. Szmidt wrote:
> cat works differently on GNU/Linux and GNU/Hurd, might be worth taking
> a peek at how it does this stuff.
exactly the same way as grep-2.4.2: it doesn't treat dirs specifically.
It tries to open the file, if it's OK, it pro
Hallo all,
On Fri, May 30, 2003 at 01:19:35PM +0200, Marcus Brinkmann wrote:
> In the Hurd, a directory might be a conventional directory. However, it
> might also be a strange non-standard thingie. That thingie could allow
> directory operations on it like a conventional directory.
oh, that's
Hello!
On Fri, May 30, 2003 at 12:14:40PM +0200, Alfred M. Szmidt wrote:
> I added [EMAIL PROTECTED] to the CC list.
I've removed some people from the CC list. I shouldn't have Cc'ed the
original question to him at first time as they are now going to get
lot of mail...
>* BUT: grep 2.5 intr
I think that on the GNU/Hurd, the read behaviour is more favorable.
It allows for scenarios like the above, without adding a lot of
noise to greps output in case you have a match with a directory
content. On systems where opening a directory always fails, the
error output of grep te
Hi,
the issue is not so much about grepping through the content of a "real"
directory. As the directory content is binary encoded, that is almost never
useful.
I don't mind having skip behaviour on systems like GNU/Linux where
directories always really are directories (if that statement is even
hi!
From: Stepan Kasal <[EMAIL PROTECTED]>:
>
> I'd like to ask you how should grep behave if it encounters a directory
> as an argument on the command line.
> [...]
> The behaviour is controlled by the --directories option.
> There are three possible values:
>
> read: try to read the directory
I added [EMAIL PROTECTED] to the CC list.
* BUT: grep 2.5 introduced a bug [1], which caused that grep behaved
as if the default was ``skip'' on sustems where reading a directory
is a faux pas.
I wouldn't call this a bug, I would call it that grep works as
expected on such systems.
This might be of interest to everyone...
--- Start of forwarded message ---
Date: Fri, 30 May 2003 09:49:07 +0200
From: Stepan Kasal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Content-Disposition: inline
cc: Jori Mantysalo <[EMAIL PROTECTED]>
cc: Alain Magloire <[EMAIL PROTECTED]>
cc: Paul
[EMAIL PROTECTED] wrote:
Unfortunately, gnumach doesn't find any disk and the first boot stops with
ext2fs.static complaining about unfindable device.
I used J2 cds.
Is it possible that it comes from my adaptec 19160 scsi controller (I don't have
any ide stuff)?
I tried to compile oskit-mach (cvs
Hello there!
After having installed successfully the hurd on some of my friend's and
university machines, I tried on mine.
Unfortunately, gnumach doesn't find any disk and the first boot stops with
ext2fs.static complaining about unfindable device.
I used J2 cds.
Is it possible that it comes from m
16 matches
Mail list logo
