andrew@kcl-cs.UUCP (Andrew Smith) (06/10/86)
Hi, I have just written a 'shell' for the ATARI ST and implemented I/O redirection from the command level. I have a real problem when redirecting stdin as the called program has no way of detecting EOF if the input is from a redirected file. When trying the following: cat < file 'cat' just keeps trying to read past the end of file (cat is just a while not EOF getc loop). I have implemented redirection as: handle = Fopen(filename,R_ONLY); Fforce(KEYBOARD,handle); Is this OK ? (there is a small problem when the file is closed - I get a never ending bleep from the speeker - it appears as if stdin is not being set back to the console correctly). The problem appears to be because the GEMDOS call 'READ' ($3F) has no notion of EOF (the manual states that to detect EOF you must compare the size of the file with the number of characters read), so if you open the file with fopen all is OK as it is taken care of by the library stdio functions. The only way around this (as far as I can see) is to write my own detect_eof function which would return the standard FEOF if we have a 'real' file, but if we have stdin from the console look for say ^D, else check for EOF on the redirected file. The only problem with this is how do I check a file descriptor to see if it is realy stdin or a redirected stdin ? Can anybody help me ? I would be pleased of any help. Thanks in advance, Andrew Smith (..!mcvax!ukc!kcl-cs!andrew).
tech@usceast.UUCP (System Technician) (06/18/86)
In article <691@neon.kcl-cs.UUCP> andrew@kcl-cs.UUCP () writes: > >Hi, > >I have just written a 'shell' for the ATARI ST and implemented I/O redirection >from the command level. I have a real problem when redirecting stdin as the >called program has no way of detecting EOF if the input is from a redirected >file. When trying the following: > > cat < file > >'cat' just keeps trying to read past the end of file (cat is just a while not >EOF getc loop). > >I have implemented redirection as: > > handle = Fopen(filename,R_ONLY); > Fforce(KEYBOARD,handle); > >Is this OK ? (there is a small problem when the file is closed - I get a >never ending bleep from the speeker - it appears as if stdin is not being >set back to the console correctly). > >The problem appears to be because the GEMDOS call 'READ' ($3F) has no notion >of EOF (the manual states that to detect EOF you must compare the size of the >file with the number of characters read), so if you open the file with fopen >all is OK as it is taken care of by the library stdio functions. > >The only way around this (as far as I can see) is to write my own detect_eof >function which would return the standard FEOF if we have a 'real' file, but >if we have stdin from the console look for say ^D, else check for EOF on the >redirected file. The only problem with this is how do I check a file descriptor >to see if it is realy stdin or a redirected stdin ? > >Can anybody help me ? I would be pleased of any help. > >Thanks in advance, > >Andrew Smith (..!mcvax!ukc!kcl-cs!andrew). Hello, I have been working on a cross-compiler (VAX to 520st) and in building the run time library have found many of the bugs with redirection. There are several problems. 1) DO NOT USE Cconin/Cconout -- use Fread(0,buf,sizeof(buf)) There is a bug (as far as I can tell) in gemdos and the system bombs on redirection. 2) The read call works as follows. a) if sizeof(buf) = 1 and the read call is to the keyboard the system will hang waiting for a character to be typed. There is no way to report an end of file. In the library I am writing I look for CNTL-Z. b) if sizeof(buf) >1 and the read call is to the keyboard the system is doing (line at a time) input. What this means is that the Fread call inputs a line as though you were using the Cconrs system call. Note that line editing is invoked I.E. CNTL-H typed will scrub the last character entered. The returned value from Fread in this case is the COUNT of the characters in the line. This means that a blank line (typing a return) will give back a count of ZERO. soooo you must still look for a CNTL-Z from the keyboard. c) if sizeof(buf) >1 and the read call is from a duplicated file handle -- using Fforce for instance. Then the system reads the file block at a time and a ZERO means EOF. So, all you have to do is let your shell know which type of EOF trap to use depending on where the file is coming from. If it is truly from the keyboard ignore a ZERO and look for a special character CNTL-Z for instance. If input is from a FILE then look for ZERO instead. Some other notes: The Cconin routines DO NOT work as advertised. Use Read instead. If you try to build an error channel you must do this. also the micro c-shell uses the busted DRI C run time library. ( I wish those guys would quit sending out toro-poo poo ) BTW will the sources for this shell be available? Because of the problem mentioned above I have a great need. This is my first posting. So go ahead flame me make my day W.R.Wood P.S. Good Luck