Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Indicating end of file Message-ID: Date: 9 Oct 90 21:02:51 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <14669@cbmvax.commodore.com> <1990Oct3.172801.26802@jato.jpl.nasa.gov> <14935@cbmvax.com Lines: 33 In article ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>In article <14935@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >[...] >> There is no "end of file" character in amigados. >[...] > >What is ctrl-\ then? Does it not indicate EOF to a stream that is connected >to a console at least? (Yes, I realize that the character is not put as the >last character in a file ala CP/M ctrl-Z). ctrl-\ sent to a cooked console causes the console to send an EOF (i.e. Read() returns an error) to the program doing the Read(). The ctrl-\ character itself is NEVER interpreted by a program as meaning EOF, it is just a specially cooked character by the console device, just like ^X and other control characters. In otherwords, a ctrl-\ inside a text file does not cause, generate or indicate an EOF. The original idea of having an EOF character took off with CP/M, where files were always multiples of the sector size long and an EOF character was required so programs would not misinterpret extra garbage after the 'end' of the file. Unfortunately, the IBM-PC propogated the idiocy, and in fact never phased it out even though PC-DOS/MS-DOS finally did implement a real file length and support calls to handle it. -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA