[comp.sys.atari.st] IO questions

jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (03/15/88)

I'm looking for hints on the 'right' way to do character output to the
screen.  (the real goal is to figure out what stuff wants to go in my C
library).  I've tried Bconout and Cconout, but both have their problems.
Cconout observes Xon/Xoff, but is confused by things that redirect file
handle 1 (0?, 2?), such as Gulam.  Bconout takes a dev, thus avoiding
the redirected handle problem, but doesn't observe Xon/Xoff, or
control-C.  Neither of those behaviours is acceptable.  I've also
considered doing Fwrite's, scanning the buffer for newlines on TTY
devices, but that seems like a fairly excessive amount of work; there
ought to be an easier way.  I guess it's also possible to build my own
Xon/Xoff handler, but, again, it seems like there ought to be an easier
way.  Anybody got any hints on how this is done elsewhere?

On a related topic, what's a good way to discover whether a handle is
actually connected to a disk file, as opposed to the screen?  The MUN
stuff does Fdatime at the handle, checking for error status as an
indication that you've got a terminal device as opposed to a file
device.  That sort of works, but it's unbelievably slow, and has the
extra disadvantage that the error return is really the result of an
address fault internal to the OS.  That works ok as long as you don't
have a debugger loaded, but if you do, you bomb into the debugger in
high memory with an illegal address trap.  I can think of things I'd
rather do...

Thanks in advance for any info.

david@bdt.UUCP (David Beckemeyer) (03/22/88)

In article <19880314183759.3.JRD@GRACKLE.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes:
>I'm looking for hints on the 'right' way to do character output to the
>screen.  (the real goal is to figure out what stuff wants to go in my C
>library).  I've tried Bconout and Cconout, but both have their problems.
>Cconout observes Xon/Xoff, but is confused by things that redirect file
>handle 1 (0?, 2?), such as Gulam.  Bconout takes a dev, thus avoiding
>the redirected handle problem, but doesn't observe Xon/Xoff, or
>control-C.  Neither of those behaviours is acceptable.  I've also
>considered doing Fwrite's, scanning the buffer for newlines on TTY
>devices, but that seems like a fairly excessive amount of work; there
>ought to be an easier way.  I guess it's also possible to build my own
>Xon/Xoff handler, but, again, it seems like there ought to be an easier
>way.  Anybody got any hints on how this is done elsewhere?

The Fwrite call using handle 1 (STDOUT) is my recomendation.  Why do you
need to scan for new-lines?   Cconout has a bug that causes it to not
work correctly with redirection (Fforce).  Fwrite does not have this
bug.  If you use Bconout() then your program will never work with redirection.

>On a related topic, what's a good way to discover whether a handle is
>actually connected to a disk file, as opposed to the screen?

If you can seek the handle it is a file.  If you can't seek, all you know
is that you can't seek, and it probably is a device and the output was not
redirected (but it could be a pipe with RTX).  But you don't know that
the output is the screen, because somebody might be using your program
from a terminal or (with RTX) on a custom installed device. You should
try to avoid making assumtions here, especially if you want your program
to be usable with multiuser systems like MT C-Shell.  Fwrite() should
work OK in all the cases anyway, so you shouldn't really have to worry.

If RTX is running, there is a better way with the Ftype() system call
which tells you whether the handle points to a file, device, or pipe.
-- 
David Beckemeyer			| "To understand ranch lingo all yuh
Beckemeyer Development Tools		| have to do is to know in advance what
478 Santa Clara Ave, Oakland, CA 94610	| the other feller means an' then pay
UUCP: ...!ihnp4!hoptoad!bdt!david 	| no attention to what he says"