Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
ps -e | grep bash

sample output from a linux machine:

1128 pts/14   00:00:00 bash
7491 pts/7    00:00:00 bash
12651 pts/14   00:00:00 bash
16145 pts/2    00:00:00 bash

sample output from a mac machine:

58352 ttys000    0:00.09 login -pfl username /bin/bash -c exec -la bash /bin/bash
58353 ttys000    0:00.02 -bash
58390 ttys000    0:00.00 grep bash
20372 ttys005    0:00.06 login -pfl username /bin/bash -c exec -la bash /bin/bash
20373 ttys005    0:00.18 -bash

My question is that why we see "grep bash" in the second case but not the first case.

share|improve this question
how piping works is related to the program bash, how the output looks is related to ps. Maybe MacOS has a different version/variant of ps installed. Have you noted any difference in the output before piping? – Baarn Oct 6 '12 at 8:43
What kind of linux? I vaguely remember getting the latter behaviour in ubuntu – Journeyman Geek Oct 6 '12 at 8:59
On Linux I've seen this work one way one time and the other way the next time. I think it has to do with the task IDs assigned as much as anything, though I can't offhand explain how. – Daniel R Hicks Oct 6 '12 at 11:50
Or probably it's a function of pipe buffer size and the thread list order. In the first case ps had traversed beyond where it would find grep in the thread list before it filled the first pipe buffer. Since it got kicked off first, it did this before grep was started. In the second case the buffer was filled before the place where grep would be was reached in the task list. – Daniel R Hicks Oct 6 '12 at 11:57

I cannot reproduce the Mac OS X behavior right now – it's likely related to process scheduling details in the OS, and might depend on timing and number of processors.

$ ps -e | grep bash
86880 ttys000    0:00.18 -bash
87718 ttys000    0:00.00 (bash)

Generally, OS X provides mostly BSD command-line programs, and Linux distributions bring the GNU variants. They are (mostly) compatible implementations of the same basic tools, but will behave differently, with often different features and arguments.

Given that the programs used (or versions in cases they're actually the same) are so different, I don't think it's possible to determine what causes the grep bash to show up on your system.

share|improve this answer
I get grep bash as well in the output, as I expected, because when I grep for something, I'll usually grep -v grep afterwards to get rid of that. – slhck Oct 6 '12 at 8:48
@slhck Thanks, added the right now to clarify. I'm used to this as well, therefore my assumption of timing/process scheduling being involved. – Daniel Beck Oct 6 '12 at 8:50
And actually I usually see the grep <string> when I ps aux | grep <string> in linux. – m4573r Oct 6 '12 at 9:19

In any case, the difference observed has nothing to do with the pipe and everything to do with ps. Try redirecting ps's output to a file and searching for the string there.

share|improve this answer
I suspect it has to do with pipe buffer size. – Daniel R Hicks Oct 6 '12 at 11:58
I doubt it, maybe this particular version of osx ps filters out the grep itself. Useful feature really. I just don't think it is piping that makes the difference. – terdon Oct 6 '12 at 12:28
How/why would ps "filter out" grep, vs any other task? How does it know you're not looking for a hung grep to kill it? – Daniel R Hicks Oct 6 '12 at 19:59
Well, everyone knows ps stands for "precognitive software" :). I have no idea what I was thinking... – terdon Oct 6 '12 at 20:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.