montnaro@sprite.steinmetz.ge.com (Skip Montanaro) (11/15/88)
I've been trying to get around a bug in NeWS that makes starting programs from user.ps unreliable. (It's bug #1004790. It's been around since NeWS 1.0 and is still present in 1.1. I'll send the workaround to anyone interested.) The symptom is that when starting programs from user.ps, such as: (psterm -ls -bg -li 16 -co 80 -sl 128 -C) forkunix (emacs) forkunix sometimes the windows show up, but most times not. Sometimes it appears that only the first command doesn't get run, so I reasoned, what's the simplest command forkunix might accept so I could use it as a sacrificial command (as it were)? The empty string! I tried executing () forkunix from a psh session and got a core file plus some pyrotechnics, apparently due to gazillions of newlines sent to whatever window the cursor was in. I eventually had to kill and restart the NeWS server to get straightened out again. When running the -debug version of the server, the screen mangling disappeared, but the core file remained. This appears to be a bug in the implementation of forkunix (passing a NULL to strchr()). It should be more graceful in the face of such (admittedly stupid) input. I've posted an official bug report to hotline@sun.com. -- Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa)
gnu@hoptoad.uucp (John Gilmore) (11/16/88)
montnaro@sprite.steinmetz.ge.com (Skip Montanaro) wrote: > I've been trying to get around a bug in NeWS that makes starting programs > from user.ps unreliable. (It's bug #1004790. It's been around since NeWS 1.0 > and is still present in 1.1. I'll send the workaround to anyone interested.) > The symptom is that when starting programs from user.ps, such as: > > (psterm -ls -bg -li 16 -co 80 -sl 128 -C) forkunix > (emacs) forkunix > > sometimes the windows show up, but most times not. I believe this is because at the time user.ps runs, the server has not yet started accepting connections. The forked commands, e.g. psterm, race the news_server to see whether they'll attempt to connect to it before it creates the server socket. If the server wins the race, the window comes up; if not, the command dies and prints a message to /dev/null (where forkunix sends stdio -- boo). The easiest fix might be for user.ps to fork a lightweight PostScript process that periodically attempts to connect to the server (itself!), and only then runs the set of forkunixes, e.g: /waittilserving { .... } def { waittilserving (psterm) forkunix (emacs) forkunix } fork pop -- John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com "The network *is* the confuser."
marka@natmlab.dms.oz (Mark Andrews) (11/17/88)
In article <MONTNARO.88Nov14170009@sprite.steinmetz.ge.com> <montanaro@sprite.steinmetz.ge.com> (Skip Montanaro) writes: > >I've been trying to get around a bug in NeWS that makes starting programs >from user.ps unreliable. (It's bug #1004790. It's been around since NeWS 1.0 >and is still present in 1.1. I'll send the workaround to anyone interested.) >The symptom is that when starting programs from user.ps, such as: > > (psterm -ls -bg -li 16 -co 80 -sl 128 -C) forkunix > (emacs) forkunix > >sometimes the windows show up, but most times not. Sometimes it appears that >only the first command doesn't get run, so I reasoned, what's the simplest >command forkunix might accept so I could use it as a sacrificial command (as >it were)? The empty string! I tried executing > I would not call this a bug as such. Starting programs such as psterm, emacs which expect to be able to talk to the server before you actually start the server are bound to cause trouble. "user.ps" is designed to TAILOR the SERVER. NeWS does not provided as it comes any way to layout a desktop reliably. The way we got around this problem was to define another configuration file "desktop.ps" and cause it to be executed AFTER the server is started. We did this by adding one line to $NEWSHOME/lib/NeWS/init.ps right at the end. (desktop.ps) LoadFile pop
tom@nlgvax.UUCP (Tom van Peer) (11/17/88)
In article <5897@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >montnaro@sprite.steinmetz.ge.com (Skip Montanaro) wrote: >> I've been trying to get around a bug in NeWS that makes starting programs >> from user.ps unreliable. (It's bug #1004790. It's been around since NeWS 1.0 >> and is still present in 1.1. I'll send the workaround to anyone interested.) >> The symptom is that when starting programs from user.ps, such as: >> >> (psterm -ls -bg -li 16 -co 80 -sl 128 -C) forkunix >> (emacs) forkunix >> >> sometimes the windows show up, but most times not. > >I believe this is because at the time user.ps runs, the server has not >yet started accepting connections. Let me first state that I don't know about bug #1004790 (so please flame mildly if the following doesn't work). When looking at init.ps I find that &main is run after the server has started. So if you define &main in user.ps and put your forkunixes in there like: /&main { go! % necessarry to get processes running. (psterm -ls -bg -li 16 -co 80 -sl 128 -C) forkunix (emacs) forkunix } def everything should work fine. -- Tom van Peer Nederlands Philips Bedrijven, Dependance Nat. Lab. Building XP Willem Alexanderlaan 7B, 5664 AN Geldrop - The Netherlands. Tel: +31-40-892334 E-mail: mcvax!philmds!nlgvax!tom or tom@pcg.philips.nl
msc@canth.SGI.COM (Mark Callow) (11/22/88)
In article <3168@natmlab.dms.oz>, marka@natmlab.dms.oz (Mark Andrews) writes: > I would not call this a bug as such. Starting programs such as > psterm, emacs which expect to be able to talk to the server > before you actually start the server are bound to cause trouble. > "user.ps" is designed to TAILOR the SERVER. > > NeWS does not provided as it comes any way to layout a desktop > reliably. The way we got around this problem was to define > another configuration file "desktop.ps" and cause it to be > executed AFTER the server is started. We did this by adding one > line to $NEWSHOME/lib/NeWS/init.ps right at the end. > > (desktop.ps) LoadFile pop We created an array of procs called RestartActions which your user.ps can fill with actions. Init.ps executes these procs after the server is running. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
dwiggins@atsun.UUCP (Don Dwiggins) (11/22/88)
Here's what works for me; put the following in user.ps:
{ % Wait for server to be started (this is a hack based on knowing
% that init.ps defines ROOTPROC, then removes it as its last action)
{ systemdict /ROOTPROC known not {exit} if pause } loop
pause pause
(psterm -f -C -t sun -li 16 -co 80 -sl 128
-ic -il console -ixy 1050 20) forkunix
(roundclock) RunDemoProgram
} fork pop
The arguments to psterm are understood by the Grasshopper version. There
are a couple of minor annnoyances with this:
I have to set the location of the clock by hand, as when invoking it from
a menu. Does any expert out there know how to specify a location for it
from the PS code?
When invoking NeWS from suntools, defining a console window "breaks" any
console association in an underlying suntools window. How can I get
that association back without killing and restarting the suntools console
window?
Don Dwiggins
dwiggins@ashtate.uucpdshr@SUN.COM (David Rosenthal) (11/23/88)
> > When invoking NeWS from suntools, defining a console window "breaks" any > console association in an underlying suntools window. How can I get > that association back without killing and restarting the suntools console > window? > This is a problem with the definition of the TIOCCONS ioctl. There is no way to re-establish the association. Do not run a NeWS console if you are running on top of SunView. David.
david@sun.uucp (David DiGiacomo) (11/24/88)
In article <8811221635.AA10468@devnull.sun.com> dshr@SUN.COM (David Rosenthal) writes: >> >> When invoking NeWS from suntools, defining a console window "breaks" any >> console association in an underlying suntools window. How can I get >> that association back without killing and restarting the suntools console >> window? >> >This is a problem with the definition of the TIOCCONS ioctl. There is no >way to re-establish the association. Do not run a NeWS console if you >are running on top of SunView. ????? Simply run this program in the SunView (ex-)console window, and it will be the console once again: /* * setcons.c * * Makes the argument tty (default /dev/tty) the console. */ #include <stdio.h> #include <sys/file.h> #include <sys/ioctl.h> main(argc, argv) int argc; char *argv[]; { char *dev; int fd; dev = argc > 1 ? argv[1] : "/dev/tty"; if ((fd = open(dev, O_WRONLY)) < 0) perror(argv[0]); if (ioctl(fd, TIOCCONS, 0) < 0) { perror(argv[0]); exit(1); } exit(0); }