[plt-scheme] no #!eof

From: Abdulaziz Ghuloum (aghuloum at cs.indiana.edu)
Date: Tue Apr 15 01:55:19 EDT 2008

On Apr 15, 2008, at 1:22 AM, Andrew Reilly wrote:

> Are you talking about putting a control-Z character into the middle  
> of a
> DOS text file?  I thought that was a bug then, too.

I think DOS, CP/M, and some VMS variants allowed that, but I can't  
say for sure.  I believe this is a file-system dependent feature, not  
an OS feature and that these OSes had such file systems.

> 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.

> 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.

> 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))?
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).

>> 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.


Posted on the users mailing list.