Xref: utzoo comp.sys.apollo:1183 comp.unix.questions:8506
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!nic.MR.NET!umn-cs!randy
From: randy@umn-cs.cs.umn.edu (Randy Orrison)
Newsgroups: comp.sys.apollo,comp.unix.questions
Subject: Re: Apollo DOMAIN/IX csh question - job control
Message-ID: <6478@umn-cs.cs.umn.edu>
Date: 29 Jul 88 18:55:36 GMT
References: <2634@quacky.mips.COM> <8261@brl-smoke.ARPA>
Reply-To: randy@umn-cs.UUCP (Randy Orrison)
Organization: Control Data, Arden Hills, Minnesota
Lines: 23

Recently gwyn@brl.arpa (Doug Gwyn) wrote:
|In article <2634@quacky.mips.COM> dce@mips.COM (David Elliott) writes:
|>A few years ago, I worked on an Apollo and used csh.  After a
|>while, someone showed me a way to tell csh to disable job
|>control, which significantly sped up job execution.
|
|I don't know how Apollo implemented it, but on a real UNIX system
|there should be no difference in job execution caused by whether
|your shell is supporting job control or not.

On the Apollos, due to high overhead of fork(), you can tell the shells to
not fork when they exec() other processes (don't ask me how the shell gets
back).  In csh/BSD you can do 'set inprocess' to get this behavior.  The
default behavior is normal.

Remember, Apollos don't run UNIX(tm) or even Unix(which we all know and love),
they run AEGIS(which has everyone confused).

	-randy
-- 
Randy Orrison, Chemical Computer Thinking Battery  --  randy@cctb.mn.org
randy@ux.acss.umn.edu	{bungia, uunet!hi-csc, rutgers, sun}!umn-cs!randy
	"You're only human, what can you do?  It'll soon be over..."