Csh pipe/fork syncronization

[Richard Todd]

jay at alliant.backbone.uoknor.edu (Jay Liang) writes:
>I am curious to know the correct sequence of csh pipes and forks
>implementation.  Please look at the following script on machine A:

>A% ps | grep ps | grep ps
> 2742 pc Slp     0:00  grep ps 
>10085 pc Slp     0:00  grep ps
>14611 pc Run     0:00  ps

>and on machine B:

>B% ps | grep ps | grep ps
> 7657  p3  R     0:01 ps
>B%

Yeah, that's what ps shows on those machines.  (For the curious, given the
look of the PS output and what I know of the machines at OU, A is probably
an Alliant and B an Encore Multimax running 4.3-tahoe). But the conclusion
is amiss:

>Machine A forks out subshells BEFORE processing the first command
>where machine B processes the command line input in sequence.
>All of the UNIX machines that I have access to acts like machine B
>except one.  What is the _correct_ implementation if there is any?
>Have you seen this before?  Am I missing something here?

Every Unix system I've heard of forks off all the subprocesses in the pipeline
at once instead of doing the commands sequentially.  What's fooling you is
an anomaly of ps: on many systems, ps's output will not show the arguments
of the process, but instead only shows the name of the command.  For
example, here on this machine (a Mac running A/UX), here's what ps has to
say about the editor I'm in now:

	3 servalan ~[7:23pm] % ps -e | grep emacs
	  1057 p1       0:22 emacs

Interestingly enough, on this system, the "w" command manages to get the
command line arguments (or parts of them, at least...):

4 servalan ~[7:24pm] % w | grep emacs
rmtodd   ttyp1     6:00pm         1:35   1:06  /usr/local/bin/emacs +8 /usr/tmp
rmtodd   ttyp3     7:22pm            4      2  grep emacs

  Here's the scoop: In general, on BSD-derived systems (I gather V7 worked
this way as well), ps figures out the command line of a process by tracking
down where the process resides in memory and groveling through the contents
of argv[] in the process's address space.  This scheme suffers from a
drawback, in that processes can manage to hide their own process name and
arguments (since the argv[] strings can be scribbled over by the process).
Presumably because of this, somewhere down the line AT&T changed how exec()
and ps work.  In general, on SysV systems, whenever a process execs the
last part of the name of the file being exec'd is squirreled away in a
special field in the "u" area of the process, and ps reads only this field.
Since processes can't write to their "u" areas, they can't change how they 
appear in ps listings, but since ps reads only this field, ps won't show
the arguments the command was given.  (I say "in general" in all the above
because there are a few BSD systems that do ps the SysV way (like the
Encore), and there are probably examples of SysV boxes with BSD-style ps). 

  So, to sum up, no there's no problem with the commands being run, you're
just looking for the commands the wrong way.  Try this instead: 

8 servalan ~[7:40pm] % ps | egrep 'grep|ps' | egrep 'grep|ps'
  1087 p3       0:00 ps
  1088 p3       0:00 egrep
  1089 p3       0:00 egrep
--
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu  rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp
Motorola Skates On Intel's Head!