Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!adm!gary@loki.scc.COM
From: gary@loki.scc.COM (Gary Bisaga)
Newsgroups: comp.unix.wizards
Subject: \"Jobs\", and other stuff
Message-ID: <8070@brl-adm.ARPA>
Date: Sat, 27-Jun-87 16:36:42 EDT
Article-I.D.: brl-adm.8070
Posted: Sat Jun 27 16:36:42 1987
Date-Received: Sun, 28-Jun-87 02:07:49 EDT
Sender: news@brl-adm.ARPA
Lines: 26

Franco:
  I am sure that you have received a din of letters so far about this,
but please put up with one more.  Csh forks when executing commands
under certain conditions:  when a command is being timed with the
builtin command "time" (not, of course, if "/bin/time" is being used),
or when the command is not a "simple" builtin, this being defined as
a non-builtin, any command (builtin or not) whose output is piped into
another process, and so on.  What is confusing is that most commands
work properly in this way.  For example, "history | more" works just
fine, because the forked shell inherits the history list variable from
its parent csh.

  However, the "jobs" command is pid-sensitive and so doesn't work as           
expected.  By the way, you will notice several other commands that do           
the same thing.  For example, "kill %% | more" doesn't work for the             
exact same reason (there is no current child of the forked shell
process).  The example "limit filesize 1000 | more" doesn't work as
expected either (although for a different reason).  In this last
case, the forked shell receives a copy of the parent shell's local
variables (one of them being the filesize limit), but, as they exist
in a different area of real memory, cannot change them.

  I hope this all helps.

			Yours in Unix,
			  Gary Bisaga (gary@loki.scc.com)