Situation: program foobar is running on a Mac OS box and on a Linux box. I verified that using "top" (I'm working in an 80x25 xterm btw). Now the funny part:
Linux:
user@linux$ ps aux | grep foobar root [...] /usr/sbin/foobar --some-options --more --options --even --more --options
Mac OS:
user@macos$ ps aux | grep foobar
Huh? What's going on? I know the program is running on both boxes! Mind-boggling solution after a long time of swearing and wasting time:
user@macos$ ps auxww | grep foobar root [...] /usr/sbin/foobar --some-options --more --options --even --more --options
WTF? I mean... WTF??? Mac OS sticks the physical output on the terminal — 80 characters per line — into the pipe (instead of the full content). That's why the grep for "foobar" returns nothing - the "foobar" part is beyond the 80 character mark...
So if I resize my terminal to 20x10, only 20 characters per line would go into the pipe?!? How stupid is that?
Do all BSD-type OSes do that?
Comments
Try selecting by what it is
I'd try doing something like this instead:
On GNU ps, this selects the process by executable name. You don't need the grep at all. Not sure if this works on Mac OS X, but you get the idea.
ps -C does not work on mac
Just verified under Mac OS 10.5.1. The -C switch does not exist.
But in this version of Mac OS, the "grep" line length limitation described does not seem to exist anyway, neither in xterm nor in Mac OS's terminal.
messing with ps flags
Yeah, what is up with this? I have 10.5.2, and I'm having trouble like Solaris. Does Mac take Sun / system V as a good example of a way forward? If they start messing with BSD I'm going back to linux...
ps -C
Nice, thanks :)
Test with FreeBSD and I have
Test with FreeBSD and I have the behaviour you described, weird...
Not exactly - 80
It's been a long while since I last used a real BSD system, but as far as I remember ps's default line width is 80 and you need "w" to make it 132 and then another "w" for "any other length". If ps looks at the terminal width to determine its output then a possible trick might be to redirect its INPUT to /dev/null:
What does "man ps" says on your Mac?
/dev/null
The /dev/null trick doesn't seem to work for me.
The manpage is correct, though:
-w Use 132 columns to display information, instead of the default which is your window size. If the -w option is specified more than once, ps will use as many columns as necessary without regard for your window size.Strace it?
It's more a matter of satisfying our curiosity now, isn't it? :^)
Anyway - what does strace (or its OSX equivalent) say about this?
A colleague pointed me to the source - apparently it should be available through developer.apple.com but I didn't find it (yet).
strace
Sorry, I won't go any further from here, my curiosity is more than satisfied ;)
It's not my Mac (I don't use proprietary software), I just abused someone else's Mac, so I cannot check strace output etc. right now...
Cheers, Uwe.
On OpenBSD:
$ ps aux | grep cron
root 10806 0.0 0.0 496 244 ?? Is Sun04PM 0:00.23 cron
Longer ps aux line
Um, yeah, but that's shorter than 80 characters (or do you have a smaller terminal?)...
What happens if you
ps auxww, then choose a line which is longer than one line in your terminal, then grep for something that's beyond the 80 characters?Longer ps aux line
FreeBSD 4.11:
bash-2.05b$ ps axu |grep -c getty
1
bash-2.05b$ ps ax |grep -c getty
9
bash-2.05b$ ps axuwww |grep -c getty
9
MacOS termainal
Hmm.... this is what I was trying to find out. My ps aux | grep commands didn't return anything and I unknowningly thought the process wasn't running! Now I know better. And I have all the more reason to get debian running from the USB key now.
thanks.
alias
Yeah, I'm thinking of using some portable alias in my .bashrc file, something like
so that if you say
ps auxit's actuallyps ww aux(which works on Linux, but I didn't test on Mac OS, yet).Uwe.
Use a function, then
How about:
function ps { command ps ww"$@"; }