4.2bsd eof flag in stdio

[geoff at desint.UUCP]

In article <560 at cbosgd.UUCP> ka at cbosgd.UUCP (Kenneth Almquist) writes:

>And if I don't want to write software that is portable to anything other
>than another UNIX system?  And anyway, I have never heard of a system that
>couldn't support reading on a terminal after EOF.  Such a system would be
>a bit awkward to use since every time you typed an EOF at your terminal
>all programs, including the command processor, would presumably encounter
>and EOF indication and you would be logged out.

If you want to write non-portable software, use UNIX system calls.  They
handle EOF in the UNIX way.

Just because you haven't heard of an operating system that has hard EOF's
doesn't mean one doesn't exist.  Your presumption about logouts shows
a strong UNIX prejudice.  *Very* few operating systems interpret EOF's to the
command processer as a logout indication.  Furthermore, many operating
systems put the command processor in the kernel, so that an EOF delivered
to a user program is not at all the same as an EOF given to the command
processor.  Indeed, this is frequently part of the reason they have "hard"
EOF's.  (No, I don't like this design either -- shells should be user
processes.  But such systems do exist.)

>Seriously, differences between UNIX variants
>create problems for people.  The idea that "they won't break very many
>programs" is not a justification.  Obviously nobody would have raised the
>issue if no programs were affected.

Yup, catching up with the real world is frequently painful.  Check out the
heat that has risen over 6-character externals in the draft ANSI standard.
But in that case and this one, I would rather bite the bullet and do it the
way that will make life easier in the future.

BTW, I have an editor that is very similar to EMACS, and it does not object
at all if its descriptors are redirected to files.  I added the feature
because I had a need for it.
-- 

	Geoff Kuenning
	...!ihnp4!trwrb!desint!geoff