ell@linus.UUCP (Edward L. Lafferty) (06/07/84)
THe chess program supplied with Berkeley (4.1 and 4.2) runs as a pdp-11 compatibility package. Note the following behavior: 1. Run chess. Play a move like p-k4. then err with r-r4 and resign. You will have received the error message "Illegal Move" and some formatting characters 1. ...... etc. 2. Then redirect the output thru a simple filter like cat. chess |& cat -u and do the same things. This time no error message, no format characters and Oh,yes, the title "Chess" is held till the end. When you resign, all the stacked output tumbles out. I have tried many ways to overcome this with no success, including trying piping from a C program. I have run the v7trc (trace compat) to see what is happening and it looks like somehow the program is determining that the output is redirected and holding on to some messages. It runs properly under an emacs shell so I guess mpxio might help. Any ideas for an easy way to attach the (complete) output of chess to a filter and get the error messages piped thru at the time they occur? Thanx. --Ed Lafferty <linus!ell> <ell@mitre-b.arpa>
chris@umcp-cs.UUCP (06/08/84)
You have to change the chess program itself to do ``fflush''es
after writing a line to stdout, or change the compat C library to
fflush even if (!isatty(1)).
[Personally, I'd like to see *all* the FILE entities be fully
buffered unless otherwise specified, and have people use fflush()
where appropriate ... but I suppose that might be a bit too painful
to implement.]
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandguy@rlgvax.UUCP (Guy Harris) (06/09/84)
> THe chess program supplied with Berkeley (4.1 and 4.2) runs as a pdp-11 > compatibility package. Note the following behavior: ... > 2. Then redirect the output thru a simple filter like cat. > chess |& cat -u > and do the same things. This time no error message, no format > characters and Oh,yes, the title "Chess" is held till the end. When you > resign, all the stacked output tumbles out. > I have tried many ways to overcome this with no success, including > trying piping from a C program. I have run the v7trc (trace compat) to > see what is happening and it looks like somehow the program is > determining that the output is redirected and holding on to some > messages. It runs properly under an emacs shell so I guess mpxio might > help. Followup: > You have to change the chess program itself to do ``fflush''es > after writing a line to stdout, or change the compat C library to > fflush even if (!isatty(1)). The problem with "chess" would probably have existed on a PDP-11 as well (sorry, we don't have any here any more so I can't test that). Chris Torek's followup is correct; since the output of "chess" is not a terminal, it doesn't do character-at-a-time writes, but buffered 512-bytes-at-a-time writes. That's the standard behavior for the Standard I/O Library, which I presume the V7 PDP-11 "chess" used. Unfortunately, it's a bit hard to change the chess program, as the source doesn't come with any version of UNIX later than V7 and it's in a mixture of C and PDP-11 assembler. You'd have to get the source from a V7 tape and get the PDP-11 C compiler, assembler, and linker running in compatibility mode (the PDP-11 assembler is written in assembler, so it will only run in compatibility mode on a VAX). This'll probably happen on a VAX as well; it will flush "stdout" whenever a Standard I/O read is done on "stdin", but only if "stdout" is line-buffered; if it's not going to a terminal, it won't be line-buffered but block-buffered. (This may be different in 4.2BSD; I checked our 4.1c source.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
jds@rlgvax.UUCP (Jack Slingwine) (06/09/84)
If you are running under 4.2BSD (or have the BBN or UNET networking
stuff under 4.1) you could solve the problem by using pseudo
ttys. Redirect the standard output and error of chess (pdp11 emulation
program that is) into the slave device of the pseudo tty (/dev/ttyp?),
and have the "filter" read from the master device (/dev/ttyp?). A more
general solution would be to write a program (called something original
like "x") which would do the necessary redirection and run the program.
The syntax would be:
x [-*fileno* ...] pgm [args ...]
An outline of "x":
main(...)
{
Allocate a pseudo tty;
if (fork() == 0){
open the slave device of the pseudo tty;
redirect the necessary file descriptors to
the slave device;
set the tty modes of the pseudo tty slave
to the tty modes of the standard input;
exec "pgm" with "args";
}
open the master device of the pseudo tty;
while (not eof on the master device){
read from the master device;
write to the standard output using whatever
buffering you like;
}
}
Since the pseudo tty *is* a tty (as far as "isatty" is concerned),
standard I/O will be fooled into doing the right kind of buffering.
Jack Slingwine
{seismo,ihnp4,allegra}!rlgvax!jdsrpw3@fortune.UUCP (06/10/84)
#R:linus:-97200:fortune:11600099:000:1233
fortune!rpw3 Jun 10 01:41:00 1984
Re: getting programs to do unbuffered output if you only have binaries of them
All of the previous responses have correctly analyzed the problem (no 'fflush'
when needed on a non-terminal stdout), but none provided solutions. Here is a
generic solution (but I may hate myself when I read this in the morning :-)
[ UGLY UGLY UGLY hack#1 ]
If you have ptys on your system, you can 'cu' to the master side of
a pty (you may have to hack up 'cu' to get this to work), log in again
on the other side, send yourself a redirection LEAVING ECHOING ON
(use "~>>file", note no colon), run your chess example, and close
your log file with 'echo "~>"', and logout, and logout.
[ UGLY UGLY UGLY hack#2 ]
If you have a network, and a 'vtp' that can make a log/script file, "connect"
to the system you are on and proceed as above...
[ UGLY UGLY UGLY hack#3 ]
If all else fails, and you have at least one dialout line plus one more
dialin line, use 'cu', dialout, dialin, and see Lemma #1...
(Sometimes you just have to get the job done, no matter how ugly the hack.)
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065ell@linus.UUCP (Edward L. Lafferty) (06/10/84)
I want to thank those who suggested fixes for this problem. In particular, the change in the chess binary sent by Steven Haflich of MIT. I also intend to try the pty suggestion on 4.2. I have a little curses program that plays chess into a full screen "board" interractively so you can see the progress of the game. If anyone wants it I'll put it into net.sources. --Ed