7

So, this isn't a problem as such, just something I'm curious about. I'm using Linux Mint MATE which is branched off Debian. If I do:

ps afx | grep abcdefg

I get:

16599 pts/3 S+ 0:00 | \_ grep --color=auto abcdefg

So, it's showing the process for the grep. But, that's after the ps in the pipe: I would have thought that the above does the ps, gets the results, and then passes them to grep. So how come the grep is actually showing up in the ps results? Doesn't it happen afterwards? I think I'm missing something fundamental about what the pipe actually does.

Improve this question
0

3 Answers 3

Reset to default
4

This question is a duplicate and belongs to unix.stackexchange.com.

To sum up, still, the OpenGroup's Shell Command Language doc is relatively vague on details regarding "pipelines":

A pipeline is a sequence of one or more commands separated by the control operator '|'. The standard output of all but the last command shall be connected to the standard input of the next command.

The format for a pipeline is:

[!] command1 [ | command2 ...]

The standard output of command1 shall be connected to the standard input of command2. The standard input, standard output, or both of a command shall be considered to be assigned by the pipeline before any redirection specified by redirection operators that are part of the command (see Redirection).

If the pipeline is not in the background (see Asynchronous Lists), the shell shall wait for the last command specified in the pipeline to complete, and may also wait for all commands to complete.

Note that while data clearly flows from "left to right" in the pipeline, there's no guarantee about the scheduling itself.

See also:

Improve this answer
0
2

Scheduling doesn't matter much at all. If you consider piping an hour long job, the pipe remains open continuously from when the first program is started until it finishes. The second program runs exactly the same time as the first one and both finish at the same time (in general)..

In other words, ps does not get the output then send it to grep - the two are run at the same time, and the output of one is entered to the second in real time. It doesn't wait for the first program to finish, collect an hour of data, then send it all to the second in one go.

Though in practice there's some level of buffering (a few hundred chars) especially when multiple pipes are involved. But for the most part, think of them both being run at the same time and talking directly to each other.

Improve this answer
1
  • thanks - i gleaned that from the answer to the question this is a dupe of :) Commented Jun 16, 2015 at 14:18
0

I think there is some timing involved here.

mkfifo /tmp/pipe echo >/tmp/pipe

(shell process is hung)

It doesn't matter which gets started first, because the writer will block anyway until a reader opens its end. And so, because practically any sane Unix program will init i/o before seeing to anything else, ps will hang until the grep process is established enough at least to do its open on the read-end of that pipe.

cat </tmp/pipe & echo >/tmp/pipe

(no hang this time)

That order means you'll always wind up w/ a grep in there.

There are other ways, though.

For example, if you're looking for the argv0 of a running process with a GNU ps, you can just do:

ps -C argv0

If you want to use grep, that's totally doable, but, given a search for argv0 again:

ps -eocomm= -opid=| grep ^argv0

...which will exclude each command's arguments.

And of course there is:

pgrep argv0
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.