jay@alliant.backbone.uoknor.edu (Jay Liang) (07/13/90)
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 4769 pc Run 0:00 ps 4798 pc Slp 0:00 grep ps 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 8524 p3 R 0:01 ps B% ps | grep ps | grep ps 7657 p3 R 0:01 ps B% 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? Jay Liang (jay@alliant.backbone.uoknor.edu) Geosciences Computing Network University of Oklahoma Norman, OK 73019
rmtodd@servalan.uucp (Richard Todd) (07/14/90)
jay@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@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!