
Interesting new Unix commands/binaries in OS X Mountain Lion - telemachos
http://apple.blogoverflow.com/2012/07/interesting-new-unix-commandsbinaries-in-os-x-mountain-lion/
======
telemachos
The _sharing_ command is new to desktops, but not new to OSX. I've used it in
shell scripts on a Snow Leopard (10.6) server. (It's very useful if you are
creating or updating the permissions for hundreds of shares at once. The
manual method is brutal, as you can imagine.)

Checking the Apple man pages, they show documentation for it on 10.7.4 and for
10.4-intel[1], so it's been around on the servers for some time. (Also, the
man pages still list it as a server-only command. Those may not have been
updated yet for Mountain Lion.)

(If you're not already aware of them, Apple has a very full set of man pages
online. The framed browsing style is a pain, but the pages are still great for
scanning and finding new commands[2].)

[1]
[https://developer.apple.com/library/mac/#documentation/darwi...](https://developer.apple.com/library/mac/#documentation/darwin/reference/manpages/man1/sharing.1.html)

[2]:
[https://developer.apple.com/library/mac/#documentation/darwi...](https://developer.apple.com/library/mac/#documentation/darwin/reference/manpages)

------
humpolec
More like command-line commands. Isn't that a bit like calling Windows
command-line utilities 'new DOS commands'?

~~~
0x0
OS X is proper UNIX®, so this sounds accurate.

Win32 command line utilities aren't really related to the DOS APIs in any way.

~~~
jamesbritt
So these new commands are available for any UNIX?

Or are they just new OSX tools that happen to run from a shell?

~~~
msbarnett
Some are. pgrep and pkill come from Solaris, IIRC.

But a unix program need not be available for every unix under the sun to still
be a unix program.

~~~
bcantrill
Yes, pgrep and pkill originally come from Solaris. If anyone cares about the
history here, they were added by Mike Shapiro in Solaris 7 to speed boot time
-- he discovered that there were a ton of RC scripts that were doing "ps -el |
grep foo | grep -v grep", and he was able to shave significant boot time by
distilling this into one command. (pgrep and pkill both originated with this
work; in as much as they had direct inspiration elsewhere, it was from the
"slay" command found in QNX.)

If my long-windedness can be excused, a pgrep anecdote that I feel must be
told: when Mike was originally doing pgrep and pkill, he wanted one to be able
to search on every field specified in proc(4), including the wchan (denoted by
pr_wchan), an archaic field that was actually a stowaway from Multics (!).
Even by Solaris 7, the wchan had no real significance in Unix, and the co-
inventor of /proc, Roger Faulkner, flew into an indignant rage that Mike would
include it -- and "pgrep -w" quickly disappeared from both Mike's workspace
and his PSARC case. Now, Mike and I were also the gatekeepers on Solaris 7,
and we both wore pagers (aside: I'm old) that would page us whenever anyone
integrated anything into Solaris with the bug synopsis. Sometime after
pgrep/pkill integrated into Solaris 7, I decided to screw with Mike a little:
he was headed to watch a Boston Celtics playoff game, and I knew he would be
away from a machine for a few hours, so I started paging him with fake
integrations that I knew would enrage him. The first integration that I fooled
him with was someone that he disliked rewriting a command that Mike himself
had just taken from the same engineer and himself rewritten -- and I really
tweaked him by making the synopsis be that the "error messages could be
improved" (trust me that this was a sore point). Now, I wanted the fake
integrations to get more and more absurd over the course of the playoff game,
so I next paged him with an integration from Roger: "pgrep(1) needs to be able
to search on wchan". I was just getting ready to send my next page (after all,
I had a couple hours of mischief planned) when Mike suddenly appeared in my
office, drenched with sweat, panting "please just tell me the first one was a
joke too!" As it turns out, he had taken my first page a little too seriously,
had immediately stopped watching the playoff game, got back in his car and was
returning to work to "throw [disliked engineer]'s monitor out his office
window." When he saw the wchan option to pgrep, he knew that I must be
screwing with him, and fortunately stopped at my office before doing anyone
(or anything) physical harm. And that's how "pgrep -w" saved a monitor -- if
not a life.

~~~
djeikyb
This is awesome. Do you have it written up in a blog post by chance? I'd love
to link it to this answer: [http://askubuntu.com/questions/27501/whats-the-
difference-be...](http://askubuntu.com/questions/27501/whats-the-difference-
between-killall-and-pkill)

~~~
bcantrill
No blog post, no -- but you can link to my HN comment[1]. Also, as long as I'm
commenting again on this, I should point out that pkill also had an Easter egg
of sorts: "pkill -V" was a shorthand for killing everyone's least favorite
Solaris daemon: vold. (This option was ripped out when vold itself was ripped
out in 2006.)

[1] <http://news.ycombinator.com/item?id=4306515>

------
veyron
`caffeinate' seems to be a command-line ripoff of
<http://www.lightheadsw.com/caffeine/>

~~~
fredsted
Quite obvious ripoff, too. Apple could at least have named it "nosleep" or
something like that.

~~~
smashing
Nosleep would be a ripoff of this project: <https://code.google.com/p/macosx-
nosleep-extension/>

------
rabidsnail
Pgrep is super-cool.

Ex: What are all of the python subprocesses started by PID 1234? `pgrep -P
1234 python`

I've been missing it on osx for a long time.

~~~
didip
If you do not have Mountain Lion yet,

    
    
        brew install proctools

~~~
malandrew
Yup. Besides pgrep, pkill is invaluable as well.

------
0x0
Is anyone else's Terminal.app crashing when trying to type "~" on an
international keyboard layout?

------
amichail
The enscript command is gone though.

~~~
andyzweb
I think that was removed in the course of Apple's anti-GNU crusade

