Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Starting tcpd in rc.local
Message-ID: <4f01870e.1bc5b@pisa.ifs.umich.edu>
Date: 4 Jan 91 16:11:41 GMT
References: <9101040350.AA05473@hwcae.cfsat.honeywell.com>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 26

In article <9101040350.AA05473@hwcae.cfsat.honeywell.com>, davidy@HWCAE.CFSAT.HONEYWELL.COM (David Young) writes:

  I just read the January 1991 issue of "Workstation HP/Apollo" (Volume 7, Number 1).
  An article starting on page 22 entitled "SR10.3: What's new, what's not" by David
  Krowitz states:
  
      "Another user reported stumbling over a minor typo in the /etc/rc.local file
      that can cause the "init" process to hange while processing the file.

I'm the user who reported this here in comp.sys.apollo.  I had wanted to run
without the '-c' switch (which I think is a stupid option), so, not giving
it much thought, I commented out the line that had the '-c' and uncommented
the one that didn't.  Unfortunately the one without the '-c' also had output
redirected to /dev/console.  This made init hang in the rc file.

I don't remember whether I suggested putting the tcpd in parens, but that's
not what I did.  What I did was remove the output redirection.  This works
fine.

But I still don't understand why putting the tcpd in parens should cause a
problem.  This shouldn't cause the tcpd to run asynchronously.  If it does,
something is screwed up.

The whole business of putting echo redirections in parens has always seemed
ugly to me.  Why doesn't init just give the console to the shell while it's
running rc, then take it back when it's done?