Path: utzoo!attcan!uunet!munnari!otc!metro!basser!natmlab!marka
From: marka@natmlab.dms.oz (Mark Andrews)
Newsgroups: comp.windows.news
Subject: Re: Fun with forkunix
Message-ID: <3168@natmlab.dms.oz>
Date: 16 Nov 88 23:57:16 GMT
References: <MONTNARO.88Nov14170009@sprite.steinmetz.ge.com>
Reply-To: marka@natmlab.dms.oz.UUCP (Mark Andrews)
Organization: CSIRO Maths and Stats & Applied Physics, Sydney, Australia
Lines: 27

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