[plt-scheme] no #!eof

On Tue, Apr 15, 2008 at 01:55:19AM -0400, Abdulaziz Ghuloum wrote:
> On Apr 15, 2008, at 1:22 AM, Andrew Reilly wrote:
> >I'm pretty certain that this is the behaviour that you'll
> >get in C, too.  (I.e., ^D tells the shell to close the stdin
> >pipe, which the program sees as the end of file.  There's just
> >no coming back from that, no matter how many reads you do
> >afterwards.)
> 
> That's incorrect.  ^D does not close anything.  It just makes read(2)  
> return 0.  Check the man page.

You are incorrectly conflating the control-D character with
the Unix end-of-file marker, in the read() manual.  Of course,
read() does not return 0 if it sees a ^D in the file, it just
returns that character.  So, if not a character, what else does
end of file mean, in the context of a unix file descriptor?  If
the descriptor is connected to a TTY device, then it depends
on the line discipline.  If it is a pipe, it means that the
other end of the pipe has closed, unless the descriptor was set
into non-blocking mode.  If it was a file, then it means you've
reached the end of the file.

> >I have tried the same thing in mzscheme, and it behaves the way
> >that you describe.  I believe that's a bug, because a control-D
> >in that context is just a control-D, not an EOF.  It should have
> >been reported and read as such.
> 
> Reported and read as what?  Pressing CTRL-D while in read is an eof.

Depends on how the input stream is cooked.  It is only an EOF
in cooked mode, and that is supposed to tell the program to
terminate, or at least close the stream.  If you're in uncooked
mode, then you just get character with octal value 4, which is
(for example) delete, if you're in emacs or bash shell (in some
circumstances), not eof.  If, instead, you've got something like
echo -en "\004\004\004" | foo
then foo will read three characters of value four, and then read EOF for
ever more, because that's really the end of the stream.

> >Actually, I think that the
> >mzscheme top-level read is a bit strange: (list (read-char))
> >returns (#\newline) immediately, without waiting for a character
> >from the user.
> 
> Didn't you hit Return after wrote (list (read-char))?

Sure.  My mistake.  I don't normally do character-at-a-time IO in a
command-line scripting environment.

> If you want an eof, you type (list (read-char)) and hit CTRL-D twice  
> without hitting Return (one to flush the expression, and one to flush  
> an eof).

That's kind of funky line discipline too.  I haven't seen that before.

> >>An eof marks the end of one segment in an input stream.
> >
> >In what environment?  In unix, you have pipes, sockets and
> >files to read, and none of them get to EOF until then end.
> 
> That too is incorrect.  With pipes, sockets, and files, you can get  
> many eofs while reading from a file descriptor.

Only for small values of "eof".

I'll happily admit that this is a zone of edge cases that I'm
not particularly familiar with.  Normally I read to the end and
then stop.  Maybe there are other situations that are useful or
important.

Cheers,

-- 
Andrew