4.2bsd eof flag in stdio
Brandon Allbery
bsa at ncoast.UUCP
Thu Dec 6 02:52:55 AEST 1984
The Plexus manuals have an entry for a command (I forget the name and
I'm 25 miles or so away from the manuals at the moment :-) that works
like cat except that EOF it sleeps for some user-specified amount of
time and then tries to read to the next EOF, so on forever. This is
for ORDINARY FILES, mind you (i.e. redirected output from make; I'd like
to see that option); if an ordinary file can be so handled, why should
a terminal be any different? Especially since the terminal works that
way anyway??? (About you DECcies: I remember a problem on a DEC 20/60
that forced a shutdown because the program was looking for hardware EOF
on a terminal. I don't expect to EVER see that on a Unix system. If
that bug exists in TOPS-20, why not other nonsensical bugs -- and I choose
to treat sticky EOF as a bug, given that a terminal doesn't sticky EOF
at all, in reality.
I give you 3 choices:
1) inconsistent file handling. What sticky EOF is in 4.2bsd, what it
is on any system that treats magtape EOFs as not absolute (most, I think)
EXCEPT standard Unix. And if you do that to Unix, you lose the whole
argument for Unix because files are *no longer* always identical in the
view of the program. In fact, I don't think the result can be CALLED
Unix.
2) consistent file handling with sticky EOF. And how do you propose
to make compatible magtapes?
3) consistent file handling with NON-sticky EOF. What most Unix versions
do. Thus working nicely with magtapes and terminals; and also useful
in examining dynamic files like the running output of make (or
/usr/spool/uucp/LOGFILE :-)
--bsa
--
Brandon Allbery @ North Coast Xenix | the.world!ucbvax!decvax!cwruecmp!
6504 Chestnut Road, Independence, Ohio | {atvax!}ncoast!{tdi1!}bsa
(216) 524-1416 \ 44131 | E1439 at CSUOHIO.BITNET (friend's acct.)
| BALLBERY (161-7070) on MCI Mail
---------------------------------------+---------------------------------------
Keeping the Galaxies safe for Civilization... :-)
More information about the Comp.unix.wizards
mailing list