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

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

Re: [gawk-stable] bug: fatal error when getline from directory


From: Paolo
Subject: Re: [gawk-stable] bug: fatal error when getline from directory
Date: Mon, 5 Jan 2009 01:35:03 +0100
User-agent: Mutt/1.3.28i

On Sun, Jan 04, 2009 at 04:59:47PM -0700, Eric Blake wrote:
> > POSIX 'text file' is any sequence of chars except for '\0', in 1+ lines
> > shorter than LINE_MAX, which is OS/implementation-specific.
> 
> And one more requirement - the file must end in a newline.  Ending in any
> other byte makes the file non-text.

Already there in:

(POSIX) 'lines' = A sequence of zero or more non- <newline>s plus a terminating 
<newline>.

> > *I* might agree that dirs aren't "text" nor "binary" files, yet you can 
> > open(2)+read(2) a dir without a glitch - you get an EOF.
> 
> Not necessarily.  That is the behavior on some OS, but not all.  Some

not really important, either ...

> behaviors after the open(2) succeeds: the read(2) fails with EISDIR (think
> Linux), it succeeds with 0 bytes (your report of EOF, think BSD), or it

nope, succeeds on Linux - that's where my eg came from.

> > But that's not the point.
> 
> Exactly.  The point is that the only portable choice that we can implement

yes, I do agree that a plain open(x) might WFM but not on your OS/whatever,
that might be an option for (limited portability) extension/whatever.

But it must not *abort* the script, there's no (portability/anything else)
reason to not let the script go on and handle the exception the way the
programmer has devised. Think bash(1), what if 'set -e' were the
unmodifiable default?


-- 
paolo




reply via email to

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