piet@ruuinf.UUCP (Piet van Oostrum) (05/20/88)
Is there a way to find out what kind of file is connected to a file handle, e.g. disk file/keyboard/screen. In some old Atari doc I found F_ioctl, but that doesn't seem to be implemented. The problems come up when you run a program with stdin/stdout redirected by a shell. -- Piet van Oostrum, Dept of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!piet
david@bdt.UUCP (David Beckemeyer) (05/27/88)
In article <447@ruuinf.UUCP> piet@ruuinf.UUCP (Piet van Oostrum) writes: >Is there a way to find out what kind of file is connected to a file handle, >e.g. disk file/keyboard/screen. >In some old Atari doc I found F_ioctl, but that doesn't seem to be >implemented. The problems come up when you run a program with stdin/stdout >redirected by a shell. > >-- >Piet van Oostrum, Dept of Computer Science, University of Utrecht >Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands >Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!piet Micro RTX added this feature to TOS. There are two calls to determine characteristics of a file handle. Here's the simplest way: type = Ftype(fd); The value returned by this call tells you what the handle is: 0-15 The BIOS level device number (e.g. 2=console) 16 A regular file 17 A pipe Maybe a future versiaon of Atari TOS will also support this. -- David Beckemeyer | "Reckon the Ball's plumb open now, Beckemeyer Development Tools | and it's `swing partner'!" 478 Santa Clara Ave, Oakland, CA 94610 | - Unnamed Cowboy, upon seeing UUCP: ...!ihnp4!hoptoad!bdt!david | heap many Indians approaching
piet@ruuinf.UUCP (Piet van Oostrum) (05/30/88)
I got a few mail replies on my question regarding where a file resides.
Some experimenting and combining the answers gave me a simple way to find
out if a file is on disk or a `terminal':
what I think is the easiest way to do it: if you seek to an illegal
position (like -1), you get an error (-64) if the file is on disk,
otherwise you get 0. If the file is on disk, its position is not changed,
so the operation is effectively always a no-op. So I use:
isatty (fd)
int fd;
{ return (Fseek (-1L, fd, 0) == 0); }
Please could any of the TOS developers comment on this?
--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!pietkbad@atari.UUCP (Ken Badertscher) (06/01/88)
in article <465@ruuinf.UUCP>, piet@ruuinf.UUCP (Piet van Oostrum) says: > what I think is the easiest way to do it: if you seek to an illegal > position (like -1), you get an error (-64) if the file is on disk, > otherwise you get 0. If the file is on disk, its position is not changed, > so the operation is effectively always a no-op. That may be an easy way to do it, but I wouldn't recommend relying on an undocumented feature of what Fseek returns. Hardly safe. The approved method of determining isatty is to save your current position in the file, seek to 1 byte from the beginning, then restore your current position. If the seek to 1 byte from the beginning returns 1, you're not a tty. It involves a couple more seeks, but it's safer: int isatty(fd) int fd; { long savepos; long seekret; savepos = Fseek(0L,fd,1); /* save where we are */ seekret = Fseek(1L,fd,0); /* seek to 1 byte from beginning */ Fseek(savepos,fd,0); /* then back to where we were */ return (seekret != 1L); /* if the seek didn't work, it's a tty */ } Ken Badertscher Atari Software Test/Support
piet@ruuinf.UUCP (Piet van Oostrum) (06/02/88)
In article <1066@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: in article <465@ruuinf.UUCP>, piet@ruuinf.UUCP (Piet van Oostrum) says: > what I think is the easiest way to do it: if you seek to an illegal > position (like -1), you get an error (-64) if the file is on disk, > otherwise you get 0. If the file is on disk, its position is not changed, > so the operation is effectively always a no-op. That may be an easy way to do it, but I wouldn't recommend relying on an undocumented feature of what Fseek returns. Hardly safe. I agree. So, *WHAT* is the documented return value from Fseek, especially in the case I use. I never saw any description of Fseek telling what the return code (except in case of an error) is. Is the return code you use (the actual position in the file, 0 for a non-file) documented? In fact if it is documented to ALWAYS return 0 on a terminal, then my code is reliable. -- Piet van Oostrum, Dept of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!piet
kbad@atari.UUCP (Ken Badertscher) (06/06/88)
in article <479@ruuinf.UUCP>, piet@ruuinf.UUCP (Piet van Oostrum) says: > So, *WHAT* is the documented return value from Fseek, especially > in the case I use. I never saw any description of Fseek telling what the > return code (except in case of an error) is. Is the return code you use > (the actual position in the file, 0 for a non-file) documented? > > In fact if it is documented to ALWAYS return 0 on a terminal, then my code > is reliable. According to the GEMDOS manual, Fseek "returns the current, absolute position in the file." If there is an error, Fseek should return an error code. It is not documented to always return 0 on a terminal. The method I posted is taken directly from the TOS release notes for the latest version of TOS, and it will be making its way to developers via the developer newsletter soon. In fact, I believe this method originally came from David Parsons and was posted on the net some time ago (sorry, I can't seem to find David's address at the moment). If you use the approved isatty, you won't lose. Ken Badertscher Atari Corporation Software Test/Support