Path: utzoo!attcan!uunet!ginosko!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.sys.apple Subject: Re: console FST EOF Keywords: Apple IIGS GS/OS console FST EOF Message-ID: <10740@smoke.BRL.MIL> Date: 15 Aug 89 07:26:33 GMT References: <10727@smoke.BRL.MIL> <3539@internal.Apple.COM> <10736@smoke.BRL.MIL> <3571@internal.Apple.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 21 In article <3571@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: > Take a look at any ASCII chart, look at the definition of character > number 26, and you will see that it is CTRL-Z, the EOF marker. I wish people would follow their own advice. Ctrl-Z results in code value 26 almost by definition. However, if you do consult an ASCII chart, you will see that code 26 has nothing to do with EOF. It is in fact the ASCII SUB(stitute) character; ASCII has no end-of-file character, although it has a couple of likely candidates EOT and ETX (which do NOT do what I was asking for). Nevertheless, Ctrl-Z was among the first things I tried (right after Ctrl-D), because I was aware that some OSes have historically pressed SUB into service for a terminal EOF indicator. CP/M and RT-11 even used an embedded SUB (followed by NULs to pad out the block) to mark the end of a text file, since they maintained disk file size only in blocks, not in bytes as on UNIX. Typing Ctrl-Z does NOT cause the GS/OS console FST to report end-of-file, at least not at a C application's getchar() level. A more reliable source claims that NUL will do the trick. I haven't had a chance to try it yet, although I could have sworn it was one of the things I had already tried.