5 ms·

Interesting new Unix commands/binaries in OS X Mountain Lion

199 points by telemachos 14y ago

veyron 14y ago
`caffeinate' seems to be a command-line ripoff of http://www.lightheadsw.com/caffeine/ http://www.lightheadsw.com/caffeine/
- fredsted 14y ago
  Quite obvious ripoff, too. Apple could at least have named it "nosleep" or something like that.
  - smashing 14y ago
    Nosleep would be a ripoff of this project: https://code.google.com/p/macosx-nosleep-extension/ https://code.google.com/p/macosx-nosleep-extension/
- DrJokepu 14y ago
  There isn't much to rip off, the whole thing is a few dozen lines long, trivial utility. The program name is probably a bona fide reference to the app. The source code of caffeinate(8) is available at http://opensource.apple.com/source/PowerManagement/PowerManagement-271.1/caffeinate/caffeinate.c http://opensource.apple.com/source/PowerManagement/PowerMana...
- djhworld 14y ago
  Hmm, never heard of that, but I can see myself using this caffeinate command quite often. Sometimes I leave command line programs running overnight then get annoyed when I find that my Mac went to sleep after an hour because I'd forgotten to adjust the power saving settings. So running caffeinate -u <my command> will be very handy indeed
- heretohelp 14y ago
  More importantly, it'll make these utilities easier to write.
deleted 14y ago
[deleted]
humpolec 14y ago
More like command-line commands. Isn't that a bit like calling Windows command-line utilities 'new DOS commands'?
- 0x0 14y ago
  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 14y ago
    So these new commands are available for any UNIX? Or are they just new OSX tools that happen to run from a shell?
    - msbarnett 14y ago
      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 14y ago
        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.
telemachos 14y ago
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/darwin/reference/manpages/man1/sharing.1.html https://developer.apple.com/library/mac/#documentation/darwi... [2]: https://developer.apple.com/library/mac/#documentation/darwin/reference/manpages https://developer.apple.com/library/mac/#documentation/darwi...
deleted 14y ago
[deleted]
rabidsnail 14y ago
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 14y ago
  If you do not have Mountain Lion yet, brew install proctools
  - malandrew 14y ago
    Yup. Besides pgrep, pkill is invaluable as well.
0x0 14y ago
Is anyone else's Terminal.app crashing when trying to type "~" on an international keyboard layout?
amichail 14y ago
The enscript command is gone though.
- andyzweb 14y ago
  I think that was removed in the course of Apple's anti-GNU crusade
deleted 14y ago
[deleted]
drhowarddrfine 14y ago
Didn't look through the list but just because OSX is Unix and they create some new command line operations, it doesn't make them a "Unix command".

199 points by telemachos 14y ago

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

fredsted 14y ago
Quite obvious ripoff, too. Apple could at least have named it "nosleep" or something like that.
- smashing 14y ago
  Nosleep would be a ripoff of this project: https://code.google.com/p/macosx-nosleep-extension/ https://code.google.com/p/macosx-nosleep-extension/
DrJokepu 14y ago
There isn't much to rip off, the whole thing is a few dozen lines long, trivial utility. The program name is probably a bona fide reference to the app. The source code of caffeinate(8) is available at http://opensource.apple.com/source/PowerManagement/PowerManagement-271.1/caffeinate/caffeinate.c http://opensource.apple.com/source/PowerManagement/PowerMana...
djhworld 14y ago
Hmm, never heard of that, but I can see myself using this caffeinate command quite often. Sometimes I leave command line programs running overnight then get annoyed when I find that my Mac went to sleep after an hour because I'd forgotten to adjust the power saving settings. So running caffeinate -u <my command> will be very handy indeed
heretohelp 14y ago
More importantly, it'll make these utilities easier to write.

deleted 14y ago

[deleted]

humpolec 14y ago

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

0x0 14y ago
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 14y ago
  So these new commands are available for any UNIX? Or are they just new OSX tools that happen to run from a shell?
  - msbarnett 14y ago
    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 14y ago
      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.

telemachos 14y ago

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/darwin/reference/manpages/man1/sharing.1.html https://developer.apple.com/library/mac/#documentation/darwi... [2]: https://developer.apple.com/library/mac/#documentation/darwin/reference/manpages https://developer.apple.com/library/mac/#documentation/darwi...

deleted 14y ago

[deleted]

rabidsnail 14y ago

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 14y ago
If you do not have Mountain Lion yet, brew install proctools
- malandrew 14y ago
  Yup. Besides pgrep, pkill is invaluable as well.

0x0 14y ago

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

amichail 14y ago

The enscript command is gone though.

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

deleted 14y ago

[deleted]

drhowarddrfine 14y ago

Didn't look through the list but just because OSX is Unix and they create some new command line operations, it doesn't make them a "Unix command".