dce@hammer.UUCP (David Elliott) (01/12/84)
The 4.2BSD version of _filbuf() immediately returns EOF every time it is called after encountering EOF, unless this is cleared via clrerr() or rewind(). For those of you that don't realize it, _filbuf() is the heart of getc() and getchar(). This may be useful, but it affects some programs. For example, in 4.1c, I can execute: cat - file1 - file2 - file3 > file4 and I can type in a little message before each file. In 4.2, I can only type a message for the first file;all others get an empty message. Is it reasonable for Berkeley to have changed the functionality of a routine when the routine has been around for years with the same functionality? From just the above example, it seems obvious that the implementors of this change did not think about the effect on existing programs. I'd like to hear opinions on this subject. David Elliott tektronix!tekecs!dce
gwyn%brl-vld@BRL-VLD.ARPA (01/14/84)
From: Doug Gwyn (VLD/VMB) <gwyn%brl-vld@BRL-VLD.ARPA> What would you expect to see when reading past the end of a file, anyway? I can imagine answers for keyboards and magtape but not for files in general. Until you do something to reposition the stream, I see no reason for EOF status to be cleared. In answer to the question of whether it is reasonable to change this behavior, I would say that if it was not explicitly documented then programmers have no right to expect it to be stable and should not have relied upon it in the first place. Remember sprintf() return values?
thomas@utah-gr.UUCP (Spencer W. Thomas) (01/16/84)
Oh, come on Doug, you have been able to read multiple EOFs from a tty device since time immemorial (and maybe before that). I have used the "cat with multiple - arguments" thing many times. It's really useful at times. =S
jr@taurus.UUCP (01/18/84)
the documentation for the cat command reads: "if the argument `-' is encountered, cat reads from the standard input file" (ok, thats not from the 4.2 manual - i hope it's the same!) this implies to me that cat - a - b - c > d should read the standard input three times allowing me to enter titles. i'd say it's cat's fault for treating `-' as a special case rather than opening and closing the tty like it would any other file. -- ++jim <england>!ukc!hirst1!taurus!jr ++jim
phil%rice@sri-unix.UUCP (01/19/84)
From: William LeFebvre <phil@rice>
this implies to me that
cat - a - b - c > d
should read the standard input three times allowing me to enter titles.
i'd say it's cat's fault for treating `-' as a special case rather
than opening and closing the tty like it would any other file.
Yeah? And what if standard input is a pipe? Open and close the pipe
three times?
William LeFebvre
ARPANet and CSNet: phil@rice
USENet: ...!lbl-csam!rice!phildbj%rice@sri-unix.UUCP (01/21/84)
From: Dave Johnson <dbj@rice>
"i'd say it's cat's fault for treating `-' as a special case rather
than opening and closing the tty like it would any other file."
Reading standard input each time for the "-" does NOT mean "opening and
closing the tty"! Standard input is whatever is on file descriptor 0 when
the program starts up; it is not always the terminal. Also, if you have
done an "su" to some other user (other than root) after logging on, "cat"
will usually be unable to open the terminal since usually only the person
who actually logged on to the terminal can read from it (although it could
get at the terminal with "/dev/tty" rather than the specific terminal).
"Cat" should simply do a clearerr() on stdin after reaching the end of file
each time, so that when it needs to read stdin again for the next "-", it
won't think that it's already at end of file.
Dave Johnson
Dept. of Math Science
Rice University
dbj@ricegwyn%brl-vld@sri-unix.UUCP (01/21/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> How would you interpret cat - a - b - c <input >output ?
kre@mulga.SUN (Robert Elz) (01/24/84)
> the documentation for the cat command reads: > > "if the argument `-' is encountered, cat reads from the > standard input file" > > (ok, thats not from the 4.2 manual - i hope it's the same!) It is (approximately) that in the 4.2 manual. > > this implies to me that > cat - a - b - c > d > should read the standard input three times allowing me to enter titles. It does just that, it reads standard input 3 times, just that the change to _filbuf has made reads to stdin return EOF after one EOF has been encountered, until that condition is explicitly reset. Whether that is the right thing for _filbuf to do is the point under debate. My thoughts are given by the following example ... What does cat - a - b - c > d < e produce in file 'd'? (I don't care what system that you run this on). Then ask yourself: Why should it matter whether or not I made 'e' by "cp file e" or "mknod e c maj min" (fill in major & minor from your own system for some terminal device, or mag tape, or ...). The whole idea of device independant i/o is to provide similar (at least) operation, whatever kind of beast is connected to the file descriptor. The change to _filbuf is a bug fix, and its immaterial how long the bug had been there, and immaterial who or what looks on this bug as a "feature", and exploits it for all its worth. > > i'd say it's cat's fault for treating `-' as a special case rather > than opening and closing the tty like it would any other file. > If that's what you really want cat to do (that is, read your terminal several times) then using "/dev/tty" will do it quite nicely. However, of course, "-" does not mean your tty, it means standard input, which is not the same thing at all. Robert Elz, Melbourne Uni Comp Sci, decvax!mulga!kre