Hacker News new | past | comments | ask | show | jobs | submit login
OS X Command Line Utilities (mitchchn.me)
567 points by brianwillis on May 15, 2014 | hide | past | favorite | 235 comments

One command I can't live without: textutil.

Basically it's a command-line front end to Apple's TextKit file import/export library. Works with a bunch of rich text/word processor formats, including OpenDoc, RTF, HTML 5, and MS Word. Critically, the HTML it emits is vastly better than the bloated crap that comes out of Microsoft Word or LibreOffice when you save as HTML ...

Install pandoc and multimarkdown as well and you've got the three pillars of a powerful, easy-to-use multiformat text processing system.

Pandoc and multimarkdown are the greatest. I've never found a way to fit textutil into that workflow, though. Is there anything it can do that pandoc can't by itself?

Textutil handles a couple of apple-specific file formats (rtfd, webarchive) that do an embrace-and-extend on open(ish) standards.

(Annoyingly it doesn't provide a way to get at the guts of Apple's own Pages files. Which sucks because the only tools for transcoding Pages are Pages itself, and icloud.com.)

Thanks! I played with this last night and wrote about it in my followup: http://www.mitchchn.me/2014/and-eight-hundred-more/

What always surprises me is that so many don't know or use the directory stack commands, pushd and popd. I'll admit I was also ignorant of them until something like 2005, but once I learned of them I switched and never looked back. Now I can't see someone write or type "cd" without a little bit of a cringe.

When i first found out about pushd and popd, i loved them, and used them all the time. These days, i never use them.

The way i work now is that i have a bunch of terminal tabs open. Each tab has a shell which pretty much just sits in a single directory. If i need to switch to a different directory, i switch tabs. A nice effect of this is that each tab builds up a recent shell history specific to the directory it sits in; the shell in the source directory has a history full of build commands, the shell in the installation directory has a history full of start and stop commands, and so on.

This works because i generally use a fairly small (<10) set of different directories, and i don't move between directories much as part of a single task. Partly, this is because i use qualified paths rather than cd'ing around everywhere. I am happy writing (mostly, tab-completing):

  vi lib/awesomeapp/dns/client.rb
Whereas a colleague of mine would always do:

  cd lib
  cd awesomeapp
  cd dns
  vi client.rb
He might get a lot of mileage out of pushd/popd. But for me, it just optimises something i don't spend a lot of time doing.

I have the same workflow for switching between tabs, although on Mac the default keyboard shortcut for switching Terminal tabs (Cmd + Shift + '[' or ']') was a little too cumbersome. I swapped it out with (Cmd + '[') which by default will take you to the next Terminal, not tab. I move left to right more, so it made more sense for me.

Easy enough to change in system preferences, though. And with using Vim NERDtree, or some other directory plugin, it makes sitting at the top level directory of your project, with multiple projects in multiple tabs, pretty easy.

Are you on Mac? If so, have you done anything to make tab-switching easier/faster? I'm interested because I only recently set mine up this way, and am always open to more efficient methods.

I'm on OSX using iTerm2. Cmd-1, Cmd-2, etc are how I switch between tabs. I keep specific things at specific numbers so it's easy to move around.

For example, the project I'm working on is always tab 1, pianobar (terminal pandora client) is always tab 4.

This is really nice because it's also how I switch tabs in Chrome. So both Chrome and iTerm have my current work on tab 1.

I am on Mac, and i have to confess i just use the trackpad to click on the tab like some sort of caveman.

Although, now ripter has taught me that ⌘1 etc select tabs (i also use iTerm), i hope i'll switch to using that.

A related trick is to use parentheses to create a subshell, in the case where you have a fixed command sequence you want to execute in another directory but you don't want to stay there:

  $ pwd
  $ mkdir -p a/b/c
  $ ( cd a/b/c ; pwd )
  $ pwd

This is probably the thing I’m missing the most in fish shell.

Many people love them, but I never got the hang of pushd and popd. These days, I use a CDPATH and z[1]. I also use zsh, which supports handy little things such as cd - (cd to previous directory).

If you haven't tried it, I highly recommend z. It's impossible to Google for, but it's oh-so-convenient.

1. https://github.com/rupa/z

'cd -' is implemented by the cd command using the OLDPWD environment variable. It works in all shells.

I did some digging and it turns out I had autopushd set. No wonder I didn't understand the usefulness of pushd/popd; I was already using them.

Also, by "cd -" I meant cd -[tab], cd -1, cd -2, etc.

Thanks! didnt know the tab feature.

cd is a shell built-in, not an external command. It has to be, since it changes the directory of the shell process, which can't be done by a child process. So shells do have to implement this specially.

Since no one has mentioned it and it would seem to be not well known, you can also cd to previous directory in bash:

cd ~-

In ZSH, you can

    setopt autopushd
to have cd work like pushd.


    setopt pushdignoredups
is probably helpful too as it will not push the same directory multiple times on the stack.

I tend to use "cd -" instead, which goes to the previous directory. Coupled with searching the command line history (C-r in the default emacs-like mode of bash, ESC-/ if you have set vi-like mode with "set -o vi") you can move around quite fast and with little thought.

uhh... I have known pushd and popd for quite a long time, but never realized that pushd can be used in place of cd. So what I have been doing all the time is:

pushd .

cd some_dir

I've been using Unix machines and pushd since the mid 1990s and just learned this as well. All those wasted years...

Some examples here:


Edit: change to desktop Wikipedia URL.

Wow. I never knew about those commands. I've been getting by with just plain cd, and "cd -" if I need to go back.

I've always just relied on zsh to deal with my pushd stack automatically. I don't frequently need to pushd (thanks to tmux's vertical splits), but when I do, it's inevitably something I don't think about until after I've swapped directories.

It's nice to alias them to something shorter. Mine are set to "pd" and "qd".

I didn't know about `screencapture`. That's a fun one.

The Linux equivalent of `open` is `xdg-open`. I usually alias it to `op`, since `/bin/open` exists.

Another bit of terminal-sugar for OS X users:

    alias lock='/System/Library/CoreServices/"Menu Extras"/User.menu/Contents/Resources/CGSession -suspend'
And most Linux users:

    alias lock='gnome-screensaver-command -l'
If you find yourself accidentally triggering hot corners, the lock command is your savior.

I've sorta-documented this stuff over the years, but only for my own memory. https://gist.github.com/ggreer/3251885 contains some of my notes for what I do with a clean install of OS X. Some of the utility links are dated, but fixing the animation times really improves my quality of life.

Additional, Linux equivalents of pbcopy/pbpaste are available in a number of competing utilities such as xcut, xclip and xset. Unfortunately none of these are installed by default on standard installations, at least not on any common distribution I've ever seen.


Ctrl + Shift + Eject


Ctrl + Shift + Power (on MacBook Pro's that don't have an eject key)

Cmd + Shift + Eject doesn't do anything.

This sleeps/suspends rather than just locking. Equivalent to closing your MacBook.

If you have your Mac set to never sleep/are using Caffeine for instance, then it simply puts the display to sleep, the rest of the computer keeps on humming along.

Not entirely equivalent to closing your MacBook.

Doesn't change the fact that cmd+shift+eject doesn't actually do anything (unless it's on an older version of OSX)

Correct, I wrote the wrong key.

These are awesome. I didn't know about many of them.

One tiny thing though, at the bottom it says

> Recall that OS X apps are not true executables, but actually special directories (bundles) with the extension .app. open is the only way to launch these programs from the command line.

Actually, you can launch them in other ways. Example

    /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome  --user-data-dir=/Users/<username>/temp/delmechrome --no-first-run
Will start a new instance of Chrome with it's own datastore in ~/temp/delmechrome. add some URL to the end to have it auto launch some webpage. Delete ~/temp/delmechrome to start over.

Although this technically works, in some cases it may lead to strange bits of misbehavior. (Depending on where you do it, the app may end up in the wrong audit session or mach namespace, and it may also be missing some environment variables that it was expecting).

The open command does allow you to specify command-line arguments to pass to the application (via --args), which is generally a safer way to do things.

But the open command doesn't allow you to pass the environment, and Apple seems hellbent on breaking every workaround they've implemented over the years (e.g. ~/.MacOSX/environment.plist).

So, doing Foo.app/Contents/MacOS/Foo is often the only way to launch a GUI app while inheriting the full environment that you have on the command line.

I often have to do this to launch various developer tools, and have them be able to inherent important environment variables, e.g. database credentials or secrets,

> But the open command doesn't allow you to pass the environment

Uh? I’ve been using open to pass NSZombieEnabled and other debugging stuff to apps all the time and it works.

From man open(1):

    Opened applications inherit environment variables just
    as if you had launched the application directly through
    its full path.  This behavior was also present in Tiger.

What?! Awesome! I would swear that was once not the case... (checks man page)

    Opened applications inherit environment variables just
    as if you had launched the application directly through
    its full path.  This behavior was also present in *Tiger*.
Sigh, I'm old...

Some apps will break entirely.

Another one that I can't live without:

   ssh-add -k keyfile
Integrates with keychain meaning you can have a passworded private key without having to play around with ssh-agent and shells and profiles. Put keychain access in the menu bar and you can lock the keychain on demand as well. Integration of ssh into the OSX workflow is absolutely awesome.

That and some of the examples in that article really make it a killer platform for Unix bits.

'open' is on of the things I long for most as a Linux user. There are several ways to achieve something that are all inferior or downright broken. Usually you don't have a huge problem, until you have. xdg-open for example could've solved this, if it was universally working.

I wrote related rant once[0] when I tried to debug an issue of a misconfigured default browser.

[0]: http://f5n.org/blog/2013/default-browser-linux/

xdg-open works for me with the GNOME-configured default application.

While xdg-open also works well for me with KDE's default applications, when I used to use Openbox or LXDE, it was much less successful. The breadth of the group of tools that respond correctly to KDE settings as opposed to the less-common environments has been one of the reasons I've been so happy to switch.

Also works great in XFCE, in my experience.

The fish shell [1] gives you an open command on Linux. Really it's just a function that calls cygstart, xdg-open, or mimedb.

It's incredibly handy.

1: http://fishshell.com

Could you imagine Apple would have gone for BeOS or a custom developed kernel with no significant terminal-based userland when making OS X? It would probably still be used by many casual users or those doing graphical work, but I doubt it would be used by hackers at all.

I believe they considered Windows NT at one point. Can you imagine using NT's fake DOS terminal? Ugh.

I suspect the GNU toolchain would have been ported over at some point.

Didn't BeOS ship with bash and everything?

/usr/local is the default location for user-installed stuff, but I personally like to have my package manager do its stuff in a separate directory.

I like the way Fink [1] uses the /sw (software) directory.

Does anyone have a valuable opinion on the comparison between Fink and Homebrew — or maybe MacPorts?

[1] http://www.finkproject.org

I work on pkgsrc which is another alternative. Its main advantages are:

* A large number of pre-built binary packages with an apt-get style command (pkgin) to install them. Over 10,000 packages are available for OSX in the most recent release (2014Q1).

* It is cross-platform to over 20 different platforms. At Joyent we provide binary packages for SmartOS/illumos, OSX, and Linux, so you can use identical packaging tools across multiple platforms, rather than having to use different tools on each OS. It is the default package manager on SmartOS, with over 12,000 binary packages available for that platform.

* As the 'src' in 'pkgsrc' implies, it's very easy to build from source too if you want to tweak build options or compiler flags. You can also install into any prefix you desire (we default to /usr/pkg), even as an unprivileged user to your home directory.

Our binary packages are available from http://pkgsrc.joyent.com/installing.html and we'd love to hear feedback on how to improve them or adding support for different platforms.

/usr/local is a wasteland on OS X. Package installers love to dump stuff in there blindly. This leads to fun-to-debug problems where two different things are overwriting files in there and blowing up because of version mismatch problems.

I ended up making a /rr tree ("rwg's root"), building things I care about from scratch, and using GNU stow to manage it.

Homebrew actually uses /usr/local/Cellar for all its installations, and then makes symlinks in the relevant /usr/local/{bin,sbin} directories. Not sure if that's what you meant.

Thanks for the clarification. Still, a quick Google search seems to indicate that this does not solve all related problems (symlinking, overriding, etc.).

Brew does refuse to link anything that would collide, and it knows to not link e.g. gettext, as a lot of Mac programs rely on BSD gettext

I agree about staying out of /usr/local. I install stuff there -- I don't want my package manager taking it over. That's kept me away from Homebrew.

I use homebrew in /homebrew for exactly this reason. The homebrew folks make noise about this, but I don't install language specific packages via brew, so I've never had a problem.

> I don't want my package manager taking it over. That's kept me away from Homebrew

That was an early blocker for me as well; however, when I discovered that I could just install homebrew at ~/.homebrew, that made it all work out.

I created https://github.com/wilmoore/homebrew-home to automate this; however, you technically don't need this install script as you could do it yourself if you really wanted to. I like it because I no longer have to think about it.

It does bother me that Homebrew advocates using /usr/local, that is a choice that needs justification and I don't believe they offer anything convincing.

That said, you can configure homebrew to use any path (check the wiki), you just have to set other environment variables as needed (eg, PATH). For example I'm currently using /opt/homebrew.

(note: a large downside to this is that you have to compile everything and cannot take advantage of Homebrew's pre-compiled "bottles" for some packages)

/opt/homebrew would be consistent with other large systems. I'd like to see that be the default.

I've used portage on Gentoo (a long, long time ago), yum a little bit on Fedora, apt-get a fair amount on debian (a long time ago) and on Ubuntu (a tiny bit, recently), the Cygwin gui package manager on windows (a medium-amount of time ago; shudder), and fink and macports on OS X (a medium-amount of time ago), and I will say this...

Homebrew is, by far, the most pleasant package manager I have ever used.

I couldn't even tell you why, but it's just nicely designed, and shit just tends to work. Part of it is that it targets a very well-defined system (MacOS), and it has an explicit aim to integrate with that system as well as possible. (I guess this could be true of e.g. apt on ubuntu, but ha ha ha.)

As an example, most package managers have some funky, one-off , more-or-less shitty way to update the packages list. Homebrew has...git! Which works great.

I highly recommend checking it out.

Another example: Most package managers say, "you're installing random software off the internet? Better give it root access!" Homebrew installs as the current user, no root access. Much saner default policy, IMO.

Or maybe you want to see a list of installed packages? "brew list". Oh, you wanted one-per-line, that's "brew list -1", just like ls.

Or maybe you want to install some software from a 3rd party repo? "brew tap $somewhere; brew install $something".

It's just a very thoughtful, well-made piece of software. Strongly recommend checking it out.

This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic.

I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoined mouse-based GUI experiences.

Here are some recommendations pertaining to mastering the command line on a Mac specifically:

-You can make the terminal start instantaneously instead of it taking several seconds. Remove the .asl files in /private/var/log/asl/. Also remove the file /users/<username>/Library/Preferences/com.apple.terminal.plist

- Install iterm2. It possesses many fancy features but honestly I hardly ever use them. The main reason to use it instead of the default Terminal application is that It just works©.

-Make your terminal look gorgeous. It may sound superficial but it actually is important when you spend expanded period of time in the terminal. You go from this http://i.imgur.com/cx3zZL8.png to this http://i.imgur.com/MQbx8yK.png . You become eager to go to your terminal instead of reluctant. Pick a nice color scheme https://code.google.com/p/iterm2/wiki/ColorGallery . Use a nice font (Monaco, Source Code Pro, Inconsolata are popular). Make it anti aliased.

-Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code.

-Install Alfred. It's the command line for the GUI/Apple part of your system. Since I installed it I stopped using the dock and Spotlight. Press ⌘+space then type what you want and it comes up. In just a few keystrokes you can open an application, open gmail/twitter/imdb/..., make a webs search, find a file (by name, by text content), open a directory,... It's difficult to describe how empowering it is to being able to go from 'I want to check something out in the directory x which is somewhere deep deep in my dev folders' to having it displayed in 2 seconds flat.

-Make a few symlinks from your home directory to the directories you use frequently. Instead of doing cd this/that/code/python/project/ you just do cd ~/project.

-Learn the shell. I recommend the (free) book The Linux Command Line: http://linuxcommand.org/tlcl.php . It guides you gently from simple directory navigation all the way up to shell scripting.

-Use tmux. Essential if you want to spend some time in the terminal. You can split the window in multiple independent panes. Your screen will have multiple terminals displayed simultaneously that you can edit independently. For example I'll have the code in one side and on the other side a REPL or a browser. You can also have multiple windows each with its own set of panes and switch from on to the other. With the multiple windows I can switch from one aspect of a project to another instantly. E.g: one window for the front-end dev, a second one for the backend and another for misc file management/git/whatever.

-Pick an editor and work towards mastery. I don't care if you choose vi or emacs. You'll be surprised how simple features can make a big change in how you type. You'll be even more surprised at how good it feels

The terminal is here to stay. It's a skill that bears a lot of fruits and that deprecate slowly. The more you sow the more you reap.

Look into getting Emacs in one of its native OS X incarnations rather than using it in the terminal. Emacs is going to have a lot more options for colors (font locking is the Emacs-speak, I think) in its own app than when it's boxed into a terminal. You also get support for multiple "frames" (windows); Vim can't do this at all and I still miss that from Emacs. I use Linux rather than OS X but if you are parked in Emacs for a long time there's no reason to do it in a terminal. I always used the GTK or the Athena version.

Vim can absolutely do multiple "frames". They're called splits.

No, it cannot. An Emacs "frame" is a separate editor window, managed by the window manager. Different Emacs frames running the same Emacs session talk to each other--they share the buffer list, etc. Within the Emacs "frame" you can have split "windows".

One Vim session can live only in one window that is managed by the system window manager. You cannot have multiple windows that talk to each other. You can split a single window manager window using ":split" and the like. Vim calls these "windows". You can have multiple tab pages, each of which holding multiple Vim windows, but all these tab pages must reside in a single system window-manager window.

Vim has a help file somewhere saying that Bram Moolenaar knows this is a problem and it's on the todo list.

You can also run Emacs as a daemon, and connect to it from both graphical and tty sessions. So you could ssh into your desktop and (with emacsclient), work with the same instance running on your X desktop.

I did this back in college with XEmacs (90's). I'd leave gnus running at school and open a new frame from home to check mail and news. (You can use this to have two people editing at once too, but you have to avoid avoid opening a minibuffer.)

Although it is not exactly the same, what you can do is start a `screen' session (which can be split with ^a S), and then split your `vi' instances.

A frame in Emacs terminology is actually a top-level window.

So MacVim does have this functionality then, yes? You can have multiple top-level windows, each having multiple tabs, each having multiple splits.

I was curious so i just tested this to see if it did. It does not. Yes you can have multiple tabs and splits, but in emacs each frame shares the same buffer list as well.

They don't share anything. Different buffers, registers, and I think even different extensions loaded.

unless you are remote, then the terminal emacs + tmux are a good combo.

emacs in daemon mode can manage both tty and window manager sessions, and lately, it's started working on OS X! I build git HEAD every week or so and this feature is fantastic. I can ssh into my main work machine and be right back in ENSIME where I was when I left off.

> - Install iterm2. <snip> The main reason to use it >instead of the default Terminal application is that It just works©.

What's wrong with the default Terminal application? I use it daily and have been for close to a decade. I never found myself wishing it did anything than what it already does.

> -Use tmux.

Meh. For most people screen works just as well. Perhaps more importantly, you can rely on screen being available pretty much anywhere. Just like vim. Speaking of which: vim is great. Use vim. The world needs more vim.

Been loving vim for several years. Finally decided to learn emacs, partially spurred by interest in clojure.

It seems that as more languages are created that include native repl experiences, emacs becomes more appealing to me because it fits nicely with editor+repl, where in other editors a repl seems more of an afterthought or nice-to-have.

I would say definitely learn vim first, but it's great to know both vim and emacs. It just opens up more doors.

iTerm2 does vertical and horizontal splitting better than Terminal.app.

tmux does vertical and horizontal splitting better than screen.

That's my rationale for using iTerm2 and tmux instead of Terminal.app and screen.

(yes, I'm aware that screen has improved its splitting recently, but I switched to tmux in 2011, after seeing a presentation about it by Nicholas Marriott)

Why split your terminal if you have screen / tmux?

iterm has special integration with tmux. The big advantage is that you can quickly scroll the history with the mouse which is way faster and more convenient that going back up screen by screen with a shortcut.

Also with some work you can synchronize the OSX clipboard with tmux's one.

I scroll using the mouse in tmux all the time in any mouse capable terminal (aka not Terminal.app, also regular linux terms).

I have a toggle to turn it on off in my tmux.conf, have a looky: https://github.com/mitchty/src/blob/master/dotfiles/tmux.con...

You can scroll in Terminal.app too, use the MouseTerm SIMBL plugin

Well, once you're bolting on plugins for features that come with iTerm2, why not use iTerm2?

Because I find iTerm to be a pile of crap on most of my systems

Out of curiosity iTerm or iTerm2? If the latter what is crap about it?

I have one huge gripe that I haven't been able to fix but its not that huge a deal. Every so often the terminal will lose its mind and start displaying mouse escape sequences. Nothing resets it out of this state, have to close whatever window I have open and start anew. Not a huge deal due to tmux but annoying enough to frustrate.

> The big advantage is that you can quickly scroll the history with the mouse...

I've not found that to be faster than <CTRL+F> or <CTRL+B>. Same keys as in vim. I haven't found the value in using iTerm over terminal + tmux (same could be said for those that are more comfortable in screen).

Copy and paste support mostly.

TMUX provides this.

How do you get it working? I've never been successful

I encountered some problems with command-line emacs control sequences not being captured correctly, though the last time I tried was a while ago.

iirc Terminal has some preferences for properly handling special keys like Ctrl and meta. Does that help our was your problem something different?

Actually, those two points are related: I started using iterm2 precisely because I also started using tmux, and tmux integration is much better with iterm2 than with the native terminal (and for me at least I find tmux much simpler than using screen). So there are advantages.

> Speaking of which: vim is great. Use vim. The world needs more vim.

Agreed :)

tmux seems to choke on tons of console output far earlier than screen.

Another trick I learned from an older HN comment is to create a .marks directory in your home directory and then add the following to your .zshrc

  export MARKPATH=$HOME/.marks

  function jump {
      cd -P $MARKPATH/$1 2>/dev/null || echo "No such mark: $1"

  function mark {
      mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1

  function unmark {
      rm -if "$MARKPATH/$1"

  function marks {
      ls -l $MARKPATH | sed 's/  / /g' | cut -d' ' -f9- | sed 's/ -/ -/g' && echo

  function _marks {
      reply=($(ls $MARKPATH))

  compctl -K _marks jump
  compctl -K _marks unmark
Now to remember a directory you type

  % mark <any_string>
and to jump to that directory you type

  % jump <any_string>
To list all your shortcuts

  % marks
Depending on the version of ls you might have to change the -f9 parameter to -f8 for marks functions

Or just install autojump and be done with it ;-).


You can use hop to similar end, and it's got support for shortest unique name and tab completion. https://github.com/Cue/hop

I have a minimal take on this: j <project> to jump to any directory below ~/Projects. Supports tab completion, as it should.


I prefer using z, which is purely written in bash.


I'd add installing zsh+oh-my-zsh. Impressive autocompletion, fuzzy matching, shortcuts, themes (I think agnoster is great), plugins... It's really great and I wouldn't go back to bash. Some resources:

https://github.com/robbyrussell/oh-my-zsh/wiki/Cheatsheet http://www.quora.com/zsh/What-are-the-cool-features-of-zsh-t...

I'd also install autojump https://github.com/joelthelion/autojump to jump quickly between directories instead of using symlinks. Instead of cd ~/project, you just do j project, or maybe j proj is enough for autojump to know where you want to go.

> You can make the terminal start instantaneously instead of it taking several seconds.

Terminal has started instantaneously on all my Macs for years, since the advent of SSDs. A tiny fraction of a second.

If it is taking several seconds to launch, I think something must have gone haywire somewhere.

A friend of mine was experiencing multiple-second launches for Terminal. When he looked, he saw that it was occupying about 1 GB of memory.

Turns out the option to maintain ALL HISTORY EVER as scrollback was turned on. So he had the last year of compiler output and whatnot stored in a file somewhere, getting loaded into memory the first time he launched Terminal after a boot, and then eating a big chunk of his laptop's memory. Turning off the option was a major improvement.

Holy crap.

I leave Scrollback limited to "available memory", which I assume is what you're referring to, but I also compulsively hit ⌘K to clear my scrollback.

It might be parsing through logs to find out last login information.

So, like any unix os, ensure you do this:

touch $HOME/.hushlogin

That will short circuit that stuff. Like you said I've not had issues with terminals opening fast but it can't hurt. I don't give a rats when I last logged in on any unix os I log into.

Don't need symlinks. Just set the CDPATH environment variable!

Also set up case insensitive completion, saves the extra shift press for all those Mac paths.

Does that really not work by default? I would figure it's only an issue if you have your disk formatted as case sensitive, which is usually a bad idea because a lot of devs don't test on it.

No, case-insensitive auto-completion doesn't work by default on OS X. For example, `cd /appli <tab>` does nothing by default (it's not finding `/Applications/`) even though my disk is formatted case-insensitive. However, after adding `set completion-ignore-case on` to my `~/.inputrc` file, I can now type `cd /appli <tab>` and it will auto-complete to `cd /Applications/`.

Any idea why Apple has it set up that way? I don't spend much time in the terminal, but case sensitive auto-complete just doesn't sound helpful.

By default OSX's HFS+ volume is configured to be case-insensitive, but case-preserving. So, the filenames will preserve the case, but the filesystem doesn't distinguish based on case. It makes for interesting bugs.

You sir just changed my life. I never knew about CDPATH..

Case-insensitive auto-completion: brilliant!

To set this up, add `set completion-ignore-case on` to your `~/.inputrc` file (create it if it doesn't exist).

Be careful with CDPATH, it can result in some mind-boggling build script bugs.

Instead of doing the sym link think manually there is a great script that is stupid simple to use and only a few lines in your zshrc/bashrc file.

It's called jump/mark. I aliased j to jump and added tab completion to zsh and it's made all the difference.


Mark .

Marks the current directory to be in the jump list.

Jump <dir name>

Jumps to that directory.

Zsh is a much nicer shell than bash too and there are no glaring incompatibility issues I have seen in daily usage.

Specifically for jump, from my .bashrc:

    export MARKPATH=$HOME/.marks
    function jump {
        cd -P $MARKPATH/$1 2> /dev/null || (echo "No such mark: $1" && marks)
    function mark {
        mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1
    function unmark {
        rm -i $MARKPATH/$1
    function marks {
        ls -l $MARKPATH | sed 's/  / /g' | cut -d' ' -f9- && echo
        local cur=${COMP_WORDS[COMP_CWORD]}
        COMPREPLY=( $(compgen -W "$( ls $MARKPATH )" -- $cur) )
    complete -F _jump jump

More information on jump and mark available at: http://jeroenjanssens.com/2013/08/16/quickly-navigate-your-f...

Basically there is a jump oh-my-zsh plugin, but be sure to add the auto-completion mentioned in this article too...

I wholeheartedly agree that it's a good investment to spend time learning your way around the shell. And I've been quite successfully proselytizing it at home: the terminal and the UNIX toolset has been part of my sons' introduction to computing. I actually wrote it down in form of a (free, online) book. It began with my sons in mind, but it soon became a more serious endeavor:


HN is not the target audience, but it might be helpful for somebody.

> Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code.

This is an excellent point and one that's not nearly as appreciated as it should be. Fullscreen mode was written off in Lion as an example of Apple dumbing down the platform and making it more like iOS, but it's the perfect mode for writers, coders--and really just about any kind of creator who needs to focus.

I wish fullscreen mode didn't switch to a different desktop. Tabbing out causes this weird "whoosh" animation to play which is so annoying.

Check out iTerm2. Full-screen iTerm2 doesn't switch to a different desktop and tabbing to another app is instantaneous.

I use sizeup[1] to maximize the terminal (or any other app) with a keystroke, instead of native full screen. It works across all applications that allow window resizing, and has handy shortcuts for "half" full screen, which is great to position, say, a browser and editor next to each other across the whole screen.

Which reminds me, I really will go and pay my 13 bucks for it now, it's more than worth it. But the free version is fully functional with just an occasional nag screen.

[1] https://www.irradiatedsoftware.com/sizeup/

Sounds very similar to Spectacle [1] which is open-source with a github repo [2].

[1] http://spectacleapp.com/ [2] https://github.com/eczarny/spectacle

+1 to this. I use CTRL+ALT+CMD+M many times per day.

I do front-end web development and full-screen doesn't work for me. I never spend that much time just coding. I switch to test in the browser often so switching between full-screen windows is jarring.

Also great if starved of screen space.

Quicksilver is similar to Alfred in intent and quite featureful/customizable. It is open source. https://github.com/quicksilver/Quicksilver

Quicksilver used to be great, but then the main developer went to work on some dead end project for Google and abandoned Quicksilver. Is the project still alive?

It's too late for me anyway - I have moved to Alfred, the new kid on the block at the time, and like it much more (much less clutter). Plus, I can't trust the QS developer anymore after he's abandoned the project once.

As far as I know, Quicksilver has been taken over by another team, and is in constant development at the moment.

I know because I regularly see "Quicksilver has been updated" messages ;)

Thank you very much for this write-up and post. I am in a similar boat you are -- every month that passes as a developer makes me hungry to automate those repetitive tasks I do every time I develop something.

I also think this sentiment will be growing. I think there's a large disconnect between "traditional" UNIX users and people entering from the web / Rails / other kinds of worlds, and that gap is slowly shrinking. That's why we are seeing things like npm tools (bower, grunt) replacing makefiles, Docker replacing traditional sysops, the whole idea of "DevOps" as a thing vs "IT".

I'm very very excited about this transition and want to help be a part of it. I think I'm going to write a similar tutorial outlining my current mac / terminal workflow.

The killer for using iTerm2 is the ability to drop another split in with Cmd+D/Cmd+Shift+D. That's pretty much the only iTerm2 feature that I use with any level of regularity, but it's awesomely handy when you're working.

Being able to save and restore the window arrangement is also awesome. I keep iTerm2 in full-screen mode and I have it split into 4 terminals. If I need to restart iTerm2, I simply choose Window -> Restore Window Arrangement and my split terminals are restored.

As for symlinks from your home: I prefer to add aliases for directories I move to a lot. For example:

alias cdss='cd /Users/username/somewhere1/somewhere2'

then I just go 'cdss' to get there from anywhere.

> You can make the terminal start instantaneously instead of it taking several seconds.

You can fix that properly in two steps:

1. Create a symlink to your preferred shell. E.g. `sudo ln -s /bin/bash /usr/bin/bash`

2. In Terminal Preferences, use /usr/bin/bash as your shell, instead of the default login shell.

To confirm that you've fixed the problem:

- Open a new terminal window.

- "Last login" should NOT be displayed.

- Hit Command+I to show the inspector. The command should read: login -pfq username /usr/bin/bash.

The -q switch on /bin/login is what speeds things up. (.hushlogin does not solve the problem)

In order to get Terminal to pass the -q switch to /bin/login you have to use a non-standard shell, hence the symlink.

> Make a few symlinks from your home directory to the directories you use frequently. Instead of doing cd this/that/code/python/project/ you just do cd ~/project

If you are using ZSH, you can just append paths to the $cdpath environment variable. This will allow you to "cd name-of-project" (assuming you've added your project directory to $cdpath). No need for a mess of symlinks in this case.

Or you can use "cdargs" [1], available in Homebrew [2]

[1] http://www.skamphausen.de/cgi-bin/ska/CDargs

[2] brew install cdargs

I have my current git branch display as part of my command prompt when I'm in a project directory.

parse_git_branch() { git branch 2> /dev/null | sed -e '/^[^]/d' -e 's/ \(.*\)/(\1)/' }

export PS1="\u@\h \[\033[32m\]\$(parse_git_branch)\[\033[00m\] \W $ "

You might want __git_ps1. Similar idea, but more functionality & maintained by someone else!

I noticed your main editor is emacs? I consider myself a Terminal Native as well, but why dont you like using GUI Emacs and Eshell/m-x Shell instead?

In practice I find Terminal/tmux/emacs a more pleasant experience to me than GUI emacs/frame and window/shell.

GUI emacs does brings nice features: -multiple fonts / font sizes at the same time (nice for minimap http://www.emacswiki.org/emacs/MiniMap !) -more shortcut possibilities with s- added to the usual C- and M-- -more colours

Shell/ansi-term modes don't work well enough. There's always problems with shortcuts/encoding/escape sequences/Ncurse.

It doesn't seem to work properly. It doesn't pick up my .bashrc, it doesn't have colors, etc.

Where did you find a GUI Emacs that doesn't have colors? I use http://emacsforosx.com. To set a color theme: M-x customize-themes.

You might want/need to install more themes, you can do that with the package manager (M-x package-list-packages)

If you want your ~/.profile to be sourced, a quick fix is to open the GUI app from the command line. Apps launched by finder don't source your profile.

my emacs does have colors. It's M-x shell that doesn't have colors.

And this goes to the point of why emacs users like myself use iTerm. Because it works. The only thing I had to setup in iTerm was my color scheme. And even that wasn't required! (iTerm is launched by finder and finds my profile just fine.)

Why don't you just exclusively use something like Arch Linux

9. /usr/sbin/system_profiler

10. /System/Library/CoreServices/Applications/Wireless Diagnostics (with built-in wifi stumbler)

11. /System/Library/CoreServices/Screen Sharing.app (Built-in VNC client with hardware acceleration)

12. /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources (Command-line wifi configuration and monitoring tool)

Combine with sed, awk, and cut, and these tools can provide useful monitoring.

Another thing you can do to improve speed is learn the keybindings for readline. They are the same keybindings as emacs, and lots of other things use readline too like python shell, sqlite, etc. A very useful set of keys to have in your muscle memory. See the readline manual: http://tiswww.case.edu/php/chet/readline/rluserman.html#SEC3

if your a vi/vim user in you're .inputrc set:

    set editing-mode vi
    set keymap vi-command
see more settings @ https://github.com/shawndumas/dotfiles/blob/master/readline/...

This won't work for some standard stuff that OS X ships with, for instance Python (when started as a command-line interpreter). That's because .inputrc is read by the GNU readline utilities, and Apple links with the BSD equivalent.

To make this work for Python:

Add a file called .editrc with the following content:

bind -v

Add a file called .pythonrc with the following lines:

import rlcompleter import readline

Add a line to your .bashrc which makes Python run .pythonrc when it starts interactively:

export PYTHONSTARTUP="$HOME/.pythonrc"

Now Python will understand your vi keystrokes :-)

mdfind / Spotlight can be a fairly powerful tool. Consider this query, which finds all Xcode projects I've tagged as "Active":

  ~$ mdfind tag:Active kind:xcode
Queries like this also work in the Cmd-Space UI, or as a Saved Search. By default each term is joined with AND, but you can specify OR too.

Put this in your path somewhere, find files, links, directories instantly, with globbing. Makes mdfind actually useful.

  $ mdf "*invoice*.pdf"

I use multiple POSIX environments (OS X at work, Linux Mint and Xubuntu at home), and I find it handy to create common aliases for differently implemented commands to keep the environments consistent.

For example, I set the letter 'o' as an alias for 'open' on OS X, and to "thunar" on Xubuntu and "nemo" on Linux Mint.

My favorite command is 'say'. You can do all kinds of silly voices.

Try this out: say hello -v Good

It knows how to sing "In The Hall Of The Mountain King" as well:

say -v cellos "Dum dum dum dum dum dum dum he he he ho ho ho fa lah lah lah lah lah lah fa lah full hoo hoo hoo"

OK, how did you discover that?

The "cellos" voice always sings that song, regardless of the words you ask it to speak. The syllables were chosen to fit the song.

Nice! You can do something like:

    python -c "print 'foo ' * 26" | say -v cellos

I used `say` to read out the cricket scores from a screenscraping bot whilst the TV (which was the radio at the time) was in use for games. Not quite TMS but it had a certain charm.

Whenever I had to run something that would take awhile, I would append '; say "YOUR THING IS DONE"' to the end so I'd be aware of when it finished.

Just mucking around, came up with this:

    wc -l < /usr/share/dict/words | xargs -I {} jot -r {} 100000  | paste -d " " - /usr/share/dict/words | sort | awk '{print $2 "! "}' | say

If you install coreutils (`brew install coreutils`), you can cut that down a bit:

    gshuf /usr/share/dict/words | head -n 10 | awk '{print $1 "! "}' | say

For anyone wondering, you can also do this:

say -v '?' (This gives you a list of voices)

say -v Good (This let's you type in a stream of text)

A newer trick (as of Mavericks) is that say can also highlight words while reading text:

   say --interactive=/green spending each day the color of the leaves

In Mavericks, selecting Customize from the System Voice dropdown of the Dictation & Speech preferences brings up a list of voices you can download as well. I think Alex was my default, but some of the others seem much better.

After years of living on the command line, OS X specifically, and learning its quirks and tricks, I am actually ready to move on.

Right now I am more interested in creating simple visual interfaces on top of UNIX-y tools, for my own personal use cases. The main benefit of this is the ability to better experiment with and optimize my workflows for different properties as needed through different combinations of single responsibility interfaces and single responsibility programs.

I am sensing that there is great promise in seeing much higher APMs (actions per minute) for many tasks, even compared to the all-powerful command line. Also, there are lots of interesting possibilities for better visual representations of data to improve comprehension and usability.

Why do you think that having a visual interface will make it easier to experiment with your workflow?

This is a genuine question - personally, i find command line interfaces to be far more hackable than graphical ones, so i would expect the opposite to be true, and hence i'm interested in your perspective.

The command line is a textual interface, and both code and data can be represented as text at a low level. It would seem that this is a good thing for efficiency and usability, as it minimizes context switching between interface paradigms, and offers direct access to a low level representation of the system using a high bandwidth input device (a keyboard).

I still think textual interfaces are a great thing for those reasons, but I don't believe they are the best thing in many cases. Yes, they are very capable and customizable, but have serious weaknesses with usability, especially when working with data of higher dimension.

I don't really think of it as text versus graphics, but rather an issue of data being represented in its best form for doing some particular work with it, and having the best interfaces to those different forms and the work. The traditional one-domain/one-application GUI model is unsustainable for this purpose, and has the weakness of constant context shifting. Composable visual interfaces are an anti-application paradigm, and more focused on data flow. To avoid problems with pure visual programming environments, symbols would still be considered the best representation for certain work (like editing text and working with logic).

Not the parent, but personally I can't remember the huge list of available Unix commands. Every time I want to do something outside my normal workflow, I end up in google. For me, "Google + man page + command line" is slower than a nice GUI optimized for specific tasks. The hard part is designing this mythical nice GUI.


* lunchy: wrapper over launchctl, written in Ruby – https://github.com/mperham/lunchy

* brew cask: "«To install, drag this icon...» no more", as they say – https://github.com/caskroom/homebrew-cask

* have fun with "say" – https://github.com/andreis/different

Speaking of fun with "say", this was a hit around my office for a while: https://github.com/xraystyle/talking-computer

There's been a few of these lists over the past few years, most recent one is https://news.ycombinator.com/item?id=7494100

It seems like a large portion of HN is less experienced re sysadmin, but is interested in it nonetheless. Perhaps there's room to make a 'codecademy for unix' type course? Curious to see what folks thing.

It does feel I'm retreading ground that's already been covered too many times, but my whole motivation for this blog was more or less what you're observing. There's a huge group of people on the fringes of hacker culture who are looking for a way in and don't know where to start. Definitely a fan of the idea of 'Nixacademy.

Here is a very handy script that takes a screenshot, places it in Dropbox's public directory, shortens the public URL, then puts the short URL in your clipboard. Making for very quick screenshot sharing. It combines a few of these hints. https://gist.github.com/jpb0104/1051544

Great list! Includes all the old favorites with clear explanations.

This is only tangentially related, but I recently wrote a little Automator Service to gather any selected file and folder paths from Finder. I very often need to grab the path of something for programming-related stuff, and doing it from the command line or with the mini-icon drag-and-drop takes way too long. Maybe somebody here will find it useful! http://cl.ly/1a3s3g1u2Q2w

Definitely useful. Thanks !

If you do Go development, you can do this to quickly get to root folder of any Go package:

  function gocd {
      cd `go list -f '{{.Dir}}' $1`
It uses the same syntax as go list to specify packages, so you can do, e.g.:

  ~ $ gocd .../markdownfmt
  markdownfmt $ pwd
  markdownfmt $ _
So nice.

I want "remote pbcopy"! I'd like to be able to log in to any remote host (usually Linux in my case), then tack something onto the command line I'm typing to copy it into the pastebuffer.

    ssh somehost
    cd /some/dir
    grep -lr foo . | remote_pbcopy
I guess something like this is possible with GNU Screen or with Tmux, and perhaps the Tmux/iTerm interaction helps, but I've never figured it out.

I usually try to stick it all on one line when I have to do that, something like

    ssh somehost 'cd /some/dir; grep -lr foo .' | pbcopy
not very flexible, but it works for many cases

On your Mac:

    ssh -R 19999:localhost:22 remote_host
On the remote host:

    command_that_prints_stuff | ssh localhost -p 19999 pbcopy


The first command routes the port 19999 on the remote host to port 22 on the computer you're using.

ssh part on the second command connects to 19999 (and thus 22 on your computer) and runs the pbcopy command in the current shell (which is the pipe from command_that_prints_stuff)

You could probably squash the 'ssh localhost -p 19999 pbcopy' into an alias too, to reduce the typing further.

EDIT: oh wait.. remote host.. ok, maybe, maybe not. depends on your environments I guess.

Why not just

    ssh remote_host command_that_prints_stuff | pbcopy


Depends on the situation, if you want to run a quick script then yours would be better. If you're spending a lot of time in remote_host then mine might make more sense.

That's cool. Thanks!

I don't know if there's an equivalent for OSX but if you're running linux you can use x11 forwarding to do this:

  ssh -x example.com
  cat /var/log/syslog | grep event | xclip -i
Your X clipboard will be shared with the host so the output will be placed into your local clipboard.

It seems odd to have

  open /Applications/Safari.app/
as an example, when

  open -a safari
does the same thing.

It's hard to beat

  cmd+space safari

Agree, but it's actually more like:

    cmd+space sa <return>
For most people. Because it seems to prioritise based on frequency of past selection.

Except that the first one is supported by TAB-completion.

With the right zsh plugin, either of them will tab complete properly. (I think "osx" from oh-my-zsh is the one that does it on mine)

Edit: looks like this is actually built into zsh. Slightly surprised, but just goes to show I know almost nothing about the shell I use every day.

Yes but I use the default bash, as do probably most OS X users.

Check out Alfred[1] it supports tab completion.


The -a flag is also great to open a file in a specific app, e.g. `open -a Safari logo.svg` or `open -a Marked README.md`.

Also worth mentioning is dotfiles (not specific to OS X). Basically various well known "power users" share their bash, homebrew, etc settings on github so that they can easily set up a new machine with minimum of fuss. There are a lot of neat trick in those boilerplate files.


Why the hell would someone change the title from "Eight Terminal Utilities Every OS X Command Line User Should Know" to "OS X Command Line Utilities".

The original title is clearly more accurate / useful / canonical. The overwritten title is ambiguous. This is indeed not a list of every OS X command line utility.

I changed it. The HN guidelines call for taking linkbait out of titles ("every user should know") and for not having arbitrary numbers in titles—which are also a form of linkbait. Taking those things out as well as the redundancies (terminal/command-line, utilities/users) yields something pretty close to "OS X Command Line Utilities".

I don't see any ambiguity. The article is precisely about OS X Command Line Utilities; it doesn't matter how many there are in the list. Nor is it misleading. There's no implication of completeness.

HN has a blurb in the guidelines about "number (rest of the title)" articles being rewritten. Never understood it or the reason why, but there you go.

no love for macport?

Homebrew is the new hotness. I'm not entirely sure how it's been able to so quickly eclipse Macports, but having used both, I Homebrew tends to stay more out of my way and be friendlier with the stuff I want to use. Maybe that's how, I suppose.

I'm a happy macports user, never had any issues with it especially after having set +no_x11 in the default variants :).

The only bad thing about it that "port upgrade outdated" must be used carefully, but that is probably true of most port-like systems.

I'm pretty sure that homebrew is to MacPorts as git is to svn.

No, it's as Go is to Java.

My understanding is that macports is a lot more finicky and hacky, especially when it comes to built-in dependencies. homebrew is specifically designed to avoid such problems.

My understanding is quite the opposite. There are a number of trivial differences between MacPorts and Homebrew - for example, MacPorts recipes are written in Tcl, Homebrew's are written in Ruby, MacPorts puts things in /opt/local, Homebrew puts things in /usr/local/Cellar, MacPorts gets its metadata with rsync, Homebrew uses Git. But there is, as far as i know, only one non-trivial difference: MacPorts links everything against versions of libraries that it has installed, whereas Homebrew links them against the ones supplied by Apple.

The Homebrew maintainers think that linking against Apple's libraries is better, because you need to install less stuff.

The MacPorts maintainers used to agree, several years ago, and used to do just that. Then, Apple released a software update which changed some libraries and broke everyone's MacPorts installations. So then they changed their mind. Now, they think that linking against their own, coherently managed, set of libraries is better, because Apple can't break stuff.

To me, Homebrew just looks like an exercise in reproducing others' work without learning from their experiences. I don't see any advantages to it myself.

Less fundamentally, there's also quite a difference in the number of packages. MacPorts's homepage indicates that they have 18530 ports. An ls|wc in Homebrew's repository indicates that they have 2802 formulae. That said, i suspect that 95% of what people actually need is in the collection that Homebrew has.

I don't think Homebrew was so much reinventing the wheel, as it was trying to create a modern replacement in an era when MacPorts/DarwinPorts was stagnate and Fink was in a similar state of upheaval.

I remember having issues getting Fink and MacPorts to run correctly in the early days of Snow Leopard, which was frustrating if you needed a library. Homebrew came in, was easier to install and had less legacy code issues.

As for tbe package counts, I'd say most of those packages are probably relics from the PPC days. I was hesitant to switch to Homebrew, but in really do think it has a better implementation.

I did try MacPorts for the first time in over a year on a new system recently, and it has improved dramatically.

But really, package management systems are all about reinventing the wheel. I'm glad both projects are active.

I thought like what you describe at first, but after using it, I realized it was just much more productive because of the simplicity. In homebrew, if a linked lib breaks, it's pretty easy to fix by simply reinstalling, and it doesn't happen very often. It's also trivial to change build options. So, basically, it's more disjoint, but because of this, it moves much faster and is way more flexible.

The important thing is not to use them together. I did, and it was a nightmare.

Can you be more specific? macports works wonderfully for me.

YYMV but I've been using Macports for 3 years and never had the impression it was finicky or hacky or had any problems with it really.

No-no-no. No. We've moved on.

Could you explain why?

The screencapture options are wrong.

    "Select a window using your mouse, then capture its contents without the window’s drop shadow and copy the image to the clipboard:

    $ screencapture -c W"
-c captures the cursor, W is not an option. The real command for this is:

    $ screencapture -C -o

It was a typo, but it was supposed to be the -W flag not -o. Fixed now.

pbpaste and pbcopy can specify multiple clipboards; one very handy thing I do is

"cmd-a" "cmd-c" (copy all)

double click on a word I'm looking for, "cmd-e" to enter it into the find clipboard

'pbpaste | fgrep --color `pbpaste -pboard find`'

I have that aliased as 'pbg'.

Aaaaand I just learned about Cmd-E and Cmd-J. Love all the little useful shortcuts OSX has. :)

The hot keys for screen capture are more useful for daily use. You can paste what you've capture directly into most email clients. Or go to Preview where creating a new file uses what's on your clipboard if its an image.

Notably the screen capture terminal command, while neat, is sold as "more flexible". I think the author is unaware of Command+shift+4 followed by tapping the spacebar. It'll give you the window capture.

Otherwise good article.

If you have Cloudup installed, that command sequence will also upload the screenshot automatically.


I don’t use a Mac, but have used espeak-via-ssh to deliver a message to my sister who was near my laptop, from the comfort of my bed… I could have (a) called out, or (b) gotten up, but where would the fun have been in that?

The biggest change I have found for my terminal was adding this to my .bash_profile:

export CLICOLOR=1

export LSCOLORS=GxFxCxDxBxegedabagaced

I thought that was one of the most amazing things when I used a linux system, but OS X is black and white by default.

`ls -G` will show colors with BSD ls, much like `ls --color' with GNU ls.

This is neat. I'll be getting a mac soon, and this is right up my ally.

Awesome. I knew about `pbcopy`, but i never knew you could also pipe stuff into it. That saves a lot of time saving script outputs to temporary text files and copying!

alias copyssh="cat ~/.ssh/id_rsa.pub | pbcopy"

Or without the extraneous cat: "pbcopy < ~/.ssh/id_rsa.pub"

Ah yes, thanks, I always forget about <

Personally, I was surprised that there is not a command line interface to OS X's Notification system. Seems like it would be handy for long running batch jobs.

Install this:


Add this to your .bashrc:

function notify { terminal-notifier -title "$1" -message "$2" }

Interest. Thank you.

I wonder if it's possible to make OS X to say "As you request, Stan" in Lexx's voice.

That alone might be sufficient reason to migrate from ubuntu.

+1 for the reference!

The '-name' argument of mdfind makes it useful to find files with the query string in the name. E.g.: "$ mdfind -name resume".

The one utility I can't live without is caffeinate, which prevents a Mac from sleeping.

It's super useful for keeping long running tasks running.

Why not just disable sleep? I only ever sleep my Macs manually (if ever).

it's useful to be able to switch between the two without having to open up the preferences

If you work with images a lot, look up sips. I use it a lot, for converting images, rescaling and resizing, etc.

The article doesn't mention the fun you can have with ssh + say.

My co-workers and I used to ssh into the iMacs of non-technical users in our office and have a good laugh from a nearby room.

It does mention that. Read again :)

Thanks for sharing

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact