Hacker News new | past | comments | ask | show | jobs | submit login
Quick tip for developers who use OS X
1145 points by gargarplex on Jan 13, 2014 | hide | past | favorite | 395 comments
OSX Terminal: hold option and click a position in the current line to move your cursor to that position. #yearslost

Bash, running in your terminal, understands both the Emacs and the Vi commands. By default is Emacs, so you can C-a (control-a) for beginning of line, C-p to go back in command line history, or C-r to search it.

I prefer the Vi mode, though. Add to your .bashrc

set -o vi

Then you can press escape to go from input mode to normal mode; there k will take you to the previous line in command line history, j to the next line, ^ and $ to the beginning and end of the line, /something will search something back.

Editing is really fast; move by words with w (forward) and b (backward), do cw to replace a word, r to replace a letter, i to go back to input. It will remember the last editing command, just as Vi, and repeat it when you press . in normal mode.

I use these settings in my .inputrc. The get me a few more commands and even the ability to escape using jj.

    set completion-ignore-case On
    set bell-style none
    set editing-mode vi

    $if mode=vi
      set keymap vi-command
      "gg": beginning-of-history
      "G": end-of-history
      set keymap vi-insert
      "jj": vi-movement-mode
      "\C-p": history-search-backward

>set completion-ignore-case On

Thanks. Keeping track of whether certain directories were capitalized or not has been unnecessarily occupying my mental bandwidth for years.

Is there a functional difference between putting...

    set editing-mode vi
... in one's inputrc and...

    set -o vi
... in one's .bashrc?

I realize that .inputrc is the config file for Readline, and .bashrc is essentially a start-up file for Bash. But is it ever necessary to use both snippets?

I would imagine that .inputrc would serve as a superset in that all programs (for instance gdb) whiich use readline would now default to vi mode.

This is the most useful thing I've heard this (short) year. I've always been looking for a way to make readline globally default to vi mode. Thanks for that.

Indeed. It also works in things like irb, for example.

Thanks for this. I switched my input mode to VI and was greatly missing using Ctrl-L to clear the screen when in input mode. I hadn't known about the inputrc before. Adding this line below your "\C-p" line fixed that for me:

    "\C-l": clear-screen

Signs you have to revert to Emacs mode. Unless it's an assemblage, it's always a smell if you replace a unit of a body with that of a "competitor."

Oh wow, I didn't even think about that. I've been making do with Cmd+K on OSX and aliasing c to clear to get around the problem.

Command-K also does the trick

Command-K won't play nicely with tmux panes though.

I've been wanting to use 'jj' to enter normal mode on the command line for some time. This solution actually didn't work for me, but adding the following to my .zshrc did:

  bindkey -M viins 'jj' vi-cmd-mode

That is because zsh does not make use of readline. I ran into this issue myself recently, since I use bash on my personal machines and zsh on my work ones.

Super off-topic, but I bet you'd be far happier if you used only one.

Very cool, does anyone know a way to set a visual indicator (diff cursor?) when in edit mode?

> set completion-ignore-case

works well with "\t": menu-complete

But I had to delete this entry. I need the case to differentiate between which path I really wanted :(

C-a : beginning line, C-e end line, alt+f forward word (unless system shortcut for file menu), alt+b back word, C-k kill line, C-b back char, C-f forward char.

At least in my current setup, C-w yank and C-y paste works as well.

Immensely helpful. Sometimes at+left/right does forward/ back word depending on the terminal emu.

Note most of these keystrokes are valid in nano as well.


- C-u to kill (cut) from current location to beginning of the line

- C-k to kill (cut) from current location to end of line

- C-w to kill (cut) from current location to beginning of word

- C-y to paste (copied / cut) lines

- C-l to clear screen (I use the shit out of this)

- Ctrl + shift + '-' (holding ctrl, shift, minus at the same time), for undo.

That is it.

EDIT: Damn it, I didn't realize I was saying a bunch of the same things as you did.

EDIT2 Thanks oinksoft for clearing up C-u and C-w.

Also, most emacs keybindings (C-u and C-w don't, but C-k, e, a and y do, at the very least) work in all Cocoa text fields. This (in general) means you have two copy buffers: the normal, system wide Cmd-C (or X), Cmd-V and the "Cocoa wide" C-k C-y buffer

The basic emacs shortcuts even work on iOS, if you're using a Bluetooth keyboard. Now the muscle memory works everywhere.

Right! Weirdly enough, C-k kills a word in (at least) the Editorial writing app in iOS7 (only writing app where I have tried since upgrading my iPad)

My favorite undocumented keybinding: C-t (transpose) for sloppy typers like me.

Didn't know C-t worked in Cocoa's. Thanks for pointing it out, always useful!

Just wanted to note:

C-u kills from cursor to start of line.

C-w kills from cursor to start of previous word. M-d is its friendly forward sibling.

Note: Ctrl-U and Ctrl-W are not from Emacs. They are instead from the same group as Ctrl-C for interrupt, Ctrl-D for End-of-File, etc; i.e. traditional Unix TTY driver keys. Run “stty -a” to see them all; the stty command can also be used to change them.

Thanks! fixed.

I never noticed C-u was from cursor. I tend to use it mostly from the end of the line.

And that's why C-e C-u is burned into my hands :^)

Is it any different from C-a C-k ? Both seem to stuff things into the kill ring (or whatever it's called in bash).

I guess lots of people leave C-a as the default escape key for screen.

Yea, there's the GNU Screen mapping conflict, and also I rarely use C-k so it's not in my muscle memory.

Makes sense; I use emacs in addition to just the emacs-like readline bindings, so C-u conflicts with "prefix argument". I also nest screen sessions using ^Z as the outer one's escape key and ^O as the inner one's, partly so I can use C-a / ^A.

Pressing ESC and then _ will insert the last argument of the last line. Repeat to go up in the history.

If you go through the command history and press CTRL-o on a line it will be executed and the command on the commandline will be replaced by the next line in the history.

Also M-. (meta-period). Keep banging on M-. to pull in the last argument of preceding commands.

With a numeric prefix argument N, it grabs the Nth-from-the-end argument of the previous command, so M-3 M-. grabs the 3rd-from-last argument from the previous command.

In Bash, you also can use the $_ variable which is the last argument of the previous command:

  $ stat /tmp/foobar
    File: `/tmp/foobar'
    Size: 0         	Blocks: 0          IO Block: 4096
  $ rm -v $_
  removed `/tmp/foobar'

You can also use `!$`.

!$ runs the last command. it's bad if the last command is of the form command arg... because it'd run command without every other argument passed in the command line

also alt + backspace, works similar to ctrl + w, but word is defined as only alphanumerics. Very useful when deleting parts of the long file paths because it will stop on / character (unlike C-w that deletes the whole path)

It's worth noting that that the C-w/C-k/C-y yank ring is a distinct buffer from the system Cmd+X/C/V pasteboard.

That way, you can have two different things on your clipboard without having to use a fancy clipboard manager. (Or, alternatively, you can be confused why the thing you're pasting isn't the thing you thought you copied last.)


These work in most GUI inputs as well.

Mac OS X uses libedit (http://thrysoee.dk/editline/, http://www.opensource.apple.com/source/libedit/libedit-39/), not GNU readline.

But yes, the keybindings work in Cocoa text controls, too, for example in TextEdit, in the Safari URL/search control, etc.

you can also go into visual mode (at least in vi mode).. pressing esc then v will launch your default editor with the current command in the buffer; saving an exiting runs the command; very useful for long commands and/or iterating

bash/emacs has C-x C-e to open up the command in a editor.

Agreed, this was the reason for me to learn my first emacs shortcuts. Also, the option+click thing doesn't work in iTerm, so unfortunately it doesn't help me but -side note- it's amazing that after years of using OS X I can still discover small productivity features like this, and I think it stands for the thoughtfulness of the people behind it.

you sure? it works for me in iterm2

To get

on the right side of the terminal like in Vim, I put this in my .zshrc file:

  function zle-line-init zle-keymap-select {
      VIM_PROMPT="%{$fg_bold[yellow]%} [% %{$reset_color%}NORMAL%{$fg_bold[yellow]%}]%  %{$reset_color%}"
      RPS1="${${KEYMAP/vicmd/$VIM_PROMPT}/(main|viins)/} $EPS1"
      zle reset-prompt

Is there a bash version of that? I don't care about where it is too much.

I started using vi mode recently. The only thing that I really miss are ci and di commands.

ci and di aren't commands. c and d are operators and the i is part of the motion--specifically, text objects.

> Then you can press escape [..]

Don't forget Ctrl-[ instead of Esc. I find that more quick, especially with Ctrl in place of CapsLk. :)

I just realized you can use some of these Emacs commands in the Chrome browser address bar (not sure about others).

Most text inputs in Mac OS support at least C-a and C-e too.

great tip. on my system i added it to .bash_profile.

zsh also has these modes.

I you tried Evil-mode, i actually using Emacs with this, now i got the power of emacs with the efficiency of Vi in one place.

Depends on how much of Vi/Vim you use. IIRC, Evil-mode doesn't implement everything.

Pretty much 90%, but that is enough at least for me.

Another really useful command is the open

    $ open filename.png
    $ open .
    $ open -e filename.txt
    $ open -a Pixen filename.png
The first command will open the file with the default application.

Open . will open the current directory in finder, which I find very helpful.

The -e flag will open the file in textedit.

The -a will open the file in the given application name.

Under Linux there is a similar command: xdg-open

For the lazy:

  $ echo "alias o='xdg-open'" >> ~/.bashrc

or gnome-open.

On Windows the equivalent is start (e.g. start C:\ )

I use start all the time, but also frequently curse at its stupid argument grammar and its interaction with auto-quoting on auto-completion. For example, type

  start C:\Doc
Next, hit tab to get

  start "C:\Documents and Settings"
Now, hit return, and watch a new command window open with title "C:\Documents and Settings".

Reason? If the first argument is a quoted string, it is used as the title of the window being opened (http://www.microsoft.com/resources/documentation/windows/xp/..., http://stackoverflow.com/questions/154075/using-the-dos-star...)

If you ever use start in batch scripts, pass a dummy first argument of ""

You can use `explorer`, which doesn't exhibit this behavior:

    explorer "C:\Documents and Settings"
does what you'd expect.

I think xdg-open defers to gnome-open/kde-open/... depending on what DE is currently running. Not sure about that. Anyway, xdg-open should be installed anywhere where any kind of DE is installed.

open -n is also useful: Allows you to run two instances of the same app at a time.

Thank you for this! It always frustrated me that I couldn't open multiple videos at once in VLC.

Try "open -h NSString.h"...

Also very useful for similar use cases is qlmanage.

    $ qlmanage -p <file>

This seems to run whatever code usually runs when you hit [space] on a filename in a Finder window. (Except that it outputs a bunch of debugging information.) Under what circumstances is that any better or more useful than "open"?

Correct (man 1 qlmanage). Depending on the type of file, it is usually faster to open quicklook than opening the file in its default application, especially if you just want to take a look and you don’t actually need to edit the file.

You can hide the debugging info by redirecting the output streams.

    $ qlmanage -p <file> &>/dev/null

Because it essentially acts like quick look for the terminal.

After making the switch to OS X in the last couple years after living in Linux and Windows before that, I think it's objective to say that keyboard shortcuts in OS X are much worse in both ease of use and consistency across applications.

Sorry, but this is laughable. Keyboard shortcuts are far more useful and consistent across applications in OS X. I'm failing to understand how you could form this opinion...which shortcuts / programs don't meet your expectations?

I guess I can sum this up by saying OS X has an additional modifier key than Windows, so you basically have 33% more power right out of the gate. The "Windows Key" is nearly useless.

And OS X doesn't steal Control for menu shortcuts. Control-V (literal) is not the same as Command-V (paste), Control-Z (suspend) is not the same as Command-Z (undo), and so on.

X Window software used to get this right, too; Unix workstations generally had another modifier (e.g. Meta, diamond on Suns) since they knew better than to hijack keys people would type in a terminal. It's only the this-​is-​finally-​the-​year-​of-​Linux-​on-​the-​desktop crowd slavishly imitating Microsoft's mistakes that screwed it up.

"X Window software" hasn't really changed very much in the last couple decades. I use distinct Control, Shift, Meta/Alt, and Hyper keys.

The blame lies with "desktop environments", not X.

X has plenty of its own problems without getting Gnome's problems heaped on top.


> It's only the this-​is-​finally-​the-​year-​of-​Linux-​on-​the-​desktop crowd slavishly imitating Microsoft's mistakes that screwed it up.

Most of the recent garbage they've cargo-culted from Apple (and common software for OS X), not Microsoft. Witness the really shitty reimplementation of Growl, the really shitty (and shamefully unmandated) window menu bar -> system menu bar consolidation.

Oh, I agree with you — I perhaps should have written something like “*nix workstation software” rather than “X Window software”. I do use a separate Meta as well, and try to avoid programs that can't be configured to use it (GNOME-aligned ones being the most common).

And hey, as far as ‘really shitty reimplementations of Growl’ go, even Apple has one now.

Ah, with that edit I agree, with the caveat that I was never exposed very much to ye olde-school Xe applicationse.

> Sorry, but this is laughable. Keyboard shortcuts are far more useful and consistent across applications in OS X.

I don't agree with this at all.

I find it baffling that a company of great designers made such bad decisions about keyboard shortcuts.

Perhaps they are consistent, but they are consistently bad.

Paste and match style (incredibly useful) is "alt-shift-command-v" i.e. four keys. There are plenty of other shortcuts that also require four keys. Four is too many. Three is too many for such an important function. This is absurd.

Using shortcuts in IDEs is a nightmare on most apple keyboard. e.g. Intellij, to run your program: alt-shift-f10. This is daft in itself, but it actually translates to function-alt-shift-f10 on many keyboards. Yes, you can change your settings, but then you could remap all your keys in any O/S. Miss the function key and you've just muted your volume.

I have no interest in slagging Apple off; I use their products almost exclusively, but this is obviously an area where they messed up. I'd love to see this fixed, although I understand why they probably won't.

"Paste and match formatting" shouldn't be necessary for most programs, and isn't a platform standard. Paste is command-V. A sensible application should do the most likely thing the user wants with paste and overload the shortcut for weird stuff. The fact that Microsoft consistently does the weird thing by default isn't a platform problem with the Mac, just with Word.

Now you could point out Pages has the same shortcut and same stupid behavior. I agree, but that's what happens when there's a clear market leader.

(Oddly enough, I've been implementing a web-based word processor, and we make paste-and-match (paragraph) style while retaining (character) styles the default. You can't actually do this in Word or Pages — default or not — despite the fact it's what users want 99% of the time. So if I paste some text with an italicized passage, the font changes to match the ambient styling, but the italics remain. When we implemented it, the UX people were flabbergasted -- they assumed it must be impossible because no word-processor does it.)

"Paste and match formatting" shouldn't be necessary for most programs, and isn't a platform standard.

Yes, it is. https://developer.apple.com/library/mac/documentation/UserEx... says "Table A-2 lists the system-reserved and commonly used keyboard shortcuts mentioned in the rest of this document."

Table A-2: contains ../art/ks_option_2x.png ../art/ks_shift_2x.png ../art/ks_command_2x.png V Apply the style of the surrounding text to the inserted object (equivalent to the Paste and Match Style command). See “The Edit Menu.” That links to https://developer.apple.com/library/mac/documentation/UserEx..., which describes the command, too.

I disagree with the claim that this is a bad choice, though. It may not be optimal if starting from a tabula rasa, but Apple did not do that when it introduced the combination, five years ago or so, in my memory. By that time Command-V has done styled paste for about 25 years, making it difficult to dethrone.

We must be glad that we have a standard for this, not angry that it may be a bit complex to type.

OK I didn't know Apple had made that a standard -- so I agree with the GP that it's dumb. If I can't easily type a shortcut with one hand, it shouldn't be a standard shortcut.

I'm suggesting the standard paste should behave as expected, not adhere to some literal definition the user doesn't care about. If I copy a passage of text from one document and paste it into another, I generally want it to look like it belongs in the destination document but I don't want to lose obvious intentional styling such as italicization.

The common case should be the easy case. Instead we have the common case and the four-fingered shortcut both doing the wrong thing. Awesome.

I think implementing "obvious intentional styling" is an AI problem. Suppose you copy a header, click in a normal paragraph, and paste. Keep styling information? Case 2: copy styled text from Keynote, and paste. Keep styling?

Maybe, the logic in a word processor should be to keep character styling, but not paragraph styling, but I think there will be many edge cases (for example, the user might be using the word processor as a document layout package)

I doubt those edge cases can be programmed away; user intervention is required. Microsoft solves that after the paste. That may be the better solution.

You can't program away edge cases, but the current standard behavior fails in the bog standard common case.

> "Paste and match formatting" shouldn't be necessary for most programs, and isn't a platform standard.

If I copy and paste from a web browser, sometimes I want the formatting and sometimes I don't. It's not an usual case. Places where I use this shortcut include Word, Evernote and Mail. It's just not a sensible key combination.

>If I copy and paste from a web browser, sometimes I want the formatting

The default SHOULD be to lose the formatting of the original and to use the font/style that is in Word. I would think that 99% of time anyone is copying and pasting into Word this is their intended result.

I agree with the other post, it is incredibly stupid to have it keep formatting from the original by default.

Yes. This is a feature where you wonder if whoever though of that shortcut ever used a word processor. Such a bad design choice for such a common action.

This isnt just about copying Word. Mac Mail has the same paste with formatting behavior. As does Evernote for that matter.

> Using shortcuts in IDEs is a nightmare on most apple keyboard. e.g. Intellij, to run your program: alt-shift-f10. This is daft in itself, but it actually translates to function-alt-shift-f10 on many keyboards. Yes, you can change your settings, but then you could remap all your keys in any O/S. Miss the function key and you've just muted your volume.

I really find that hard to see as anything but the IDE's fault, probably due to cross platform shortcuts not rethought for OS X - but even then, something like 40 base non-function keys times at least four combinations of modifiers, and something as important as running the program gets relegated to alt-shift-F10?

> I really find that hard to see as anything but the IDE's fault,

That's fine, but the IDE is an application running on the OS X platform. OS X has these problems just as much as any platform, but the situation is made worse by their use of the function keys and by poor choices for other shortcuts.

System Preferences -> Keyboard -> Use all F1, ... as standard function keys

I found this issue when using all kinds of programs, so here's a little trick using AppleScript. Put the following into a file in your home directory (I call mine .f12Keys)

  tell application "System Preferences"
      set current pane to pane "com.apple.preference.keyboard"
  end tell

  tell application "System Events"
      tell application process "System Preferences"
          click checkbox 1 of tab group 1 of window "Keyboard"
      end tell
      tell application "System Preferences" to quit
  end tell
Then, put the following line into your .bash_profile.

  alias f12="osascript .f12Keys"
Now whenever you need to switch the default behavior of function keys, simply open a new terminal window and type "f12". It takes my computer about half a second to execute. That's kind of the brilliance of Apple products and Cocoa. If there's something you do frequently, if it's in a GUI or otherwise, so long as it's written in Cocoa you can automate it. Yeah, most Apple users have never heard of AppleScript, but for those who use it for the little things every day, it's quite helpful.

IntelliJ actually provides two sets of MacOS keyboard shortcuts, for some reason. The non-default (MacOS 10.5+) is generally far better.

And the IntelliJ family of products has one of the most configurable sets of keyboard shortcut sets I've ever seen. You can literally set any feature available to any keyboard shortcut you want to, if you want paste to be 5 keys go for it, so complaining about this is senseless.

If you don't like it, change it. Keyboard shortcuts can be (re)defined, on a per-app basis or universally, in the Shortcuts tab of the Keyboard preferences.

I could never remember the various screen shot shortcuts, so for me it's command-escape for the clipboard and option-escape for straight to a file.

It took me less than a minute to change Pages so command-v pastes matching style, and command-option-v pastes with the original style. Even better, Pages's menus display the new shortcuts.

The latest Pages doesn't really seem to have paragraph styles vs. character styles, so it might be more difficult to pull that off, but Automator is very clever, and AppleScript moreso, so I'm betting it's possible.

    > Paste and match style (incredibly useful) is "alt-shift-
    > command-v" i.e. four keys . . . Four is too many. Three 
    > is too many for such an important function.
I've literally never heard of this functionality before, in any application, on any platform.

I couldn't agree with you more! I used to be (a long time ago) a avid Windows user, and scoffed at Mac's. I then got into the publishing world where everything is Mac. The keyboard shortcuts are by far much more consistent and easier on OS X. I am scratching my head wondering how anyone could ever come up with a different conclusion, the difference is night and day.

It all depends on what you are doing.

The WindowsKey is often overlooked, for example, there are great key combinations for manipulating application windows. WindowsKey+Arrow moves the current window around in a logical way (up maximizes, left docks to left edge of screen, etc), WindowsKey+Shift+Arrow moves the current window to another monitor in a sensible fashion. Out of the box OS X doesn't seem to have equivalents.

You are right. This behaviour only appeared in Windows 7 +, and didn't exist on older OSes, unless you used a utility such as WinSplit Revolution.

On OSX, you can install something like ShiftIt, but if ANYONE discovers such a utility for Linux that is DE agnostic, I would cry with joy because I am using tile -m at the moment...

Not to mention that the Mac community also pioneered keyboard driven launchers and Linguistic user interfaces like launchbar -> quicksilver -> Alfred. Even though I put a lot of effort into learning windows keyboard shortcuts it always frustrated me how difficult it was to use windows in situations where I didn't have a mouse, while I'd barely notice the same situation with a Mac.

OK here's one. I press command-option esc to Force Quit an app. But how do I then close the Force Quit window (which stays on top of all other windows) without the mouse? Thanks to anyone who's figured this out.

As was already said, Command-W. This will always close the active window.

What’s not as obvious is how to close this window without the mouse when you have switched to some application and Force Quit is no longer the active window. Command-Tab won’t allow you to switch to the Force Quit window since it’s not treated as an app by OS X. However, you can switch to the window by simply using the command for Force Quit again, i.e. pressing Command-Option-Esc, then closing the now active force quit menu with Command-W.


Which is the same way you close any other document...

Or Esc.

>I press command-option esc to Force Quit an app

why? command-Tab (switch between and show running apps) and command-Q (force quit)

also you can use command w to close a window if really really want to go that route

If an application has hung, command Q won't work. Happens to me with Mail sometimes. Also, all the helpful suggestions to use Command Q to close the Force Quit window will work - thanks - unless you first command tab to another app. At that point, the Force Quite window becomes inaccessible from the keyboard (it has no entry in the command tab app switcher), even though the window itself is still sitting on top blocking view of other windows. At that point, I believe, it's back to the mouse.

Edit: Thanks arrrrg, just noticed your solution - alt command esc to reactivate the Force Quit window, then command W.

You press Esc

However, the way to access the menu is dumb. Ctrl-F2? Why not Alt-<letter> like Windows?

And such dumb commands within the menus! eg. Xcode show debug area: cmd-shift-y, continue: ctrl-cmd-y; these seem stupid to me, but probably because they have repurposed the Fn keys (F1-F19) to show expose etc. instead of having real function key behaviour, and probably because some function keys are missing from the tiny wireless keyboards...

To be fair, I am perfectly used to both of them but moving from OS to OS was a horrible learning curve to begin with!

I would say that keyboard shortcuts are consistently bad across OSX but I am perfectly used to them :-)

I mostly agree with you, with the exception of Final Cut Pro... Its keyboard layout to OSX's is like Finnish to Samoan.

After switching to OS X after spending years using Windows and then Linux, I found it patently the case that the keyboard shortcuts in OS X are much better in both ease of use and consistency across applications.

The use of the Command key and a bunch of standard shortcuts using it are particularly notable.


After switching to OS X after spending years using Windows and then Linux, I found it patently the case that the keyboard shortcuts in OS X are much better than Windows and much worse than Linux in both ease of use and consistency across applications.

Saurik makes most of the points that I would have if I had expounded on my comment here: https://news.ycombinator.com/item?id=7051899

If naught else, I will say that:

- The use of Cmd so widely and consistently makes it easy to bind one's own shortcuts to Ctrl/Shift/Alt/... (every menu in almost every application I use contains only Cmd shortcuts).

- The ability to remap shortcuts to anything in a menu being built into the system for all apps systemwide (System Preferences -> Keyboard) is amazing and underappreciated, methinks.

- The almost completely consistent use of a single windowing toolkit (Cocoa) everywhere makes a whole bunch of controls incredibly consistent in feel, which includes all textboxes supporting OS X and Emacs cursor movement keys, irrespective of the application - the mind boggles. o_O

- Similarly, the systemwide use of Cocoa means that the endless tools that allow for keyboard rebinding and window movement that we see (Slate, BetterTouchTool, ...) not only can exist but work very reliably and with few corner cases with most-every application on the system, oftentimes through the Assisted Access APIs (another thing Apple do well on all their platforms, I'm quite reliably informed).

OTOH, on Linux I use Xmonad as my DE and I will admit to missing the amazing keyboard-based window control I get with the tiling window manager (I use Slate on OS X for a poor facsimile to the same effect).

> The ability to remap shortcuts to anything in a menu being built into the system for all apps systemwide (System Preferences -> Keyboard)

Well, I didn't know this was possible... and I have used Macs for a few years!

I agree. I like in same order Linux > OSX > windows

After switching to OS X after spending years using Windows and then Linux, I have forgotten the feelings about keyboard shortcuts in both ease of use and consistency across applications on Windows/Linux.

After using OS X for a few months, I weep every time I use the commandline on Windows.

There's just no reason for Windows to be that bad.

Did you try Powershell?

Yup. I'm not going to get into a vacuous PowerShell bashing discussionlet here, but let's just say that PS didn't fulfill the promises the documentation made. I found that the marshaling semantics were often quite surprising and required awkward workarounds (really don't unflatten lists of people, okay?).

I second the "everything is about five syllables" and sure, you can set up aliases, but I went through that hell on VAX/VMS and don't want to go back.

I've tried powershell, but it still seems to launch in that same ancient command window they've used for years with the exceptionally strange copy & paste characteristics (seriously, why can't it copy wrapped multi-line wrapped commands without inserting newlines when I paste?). Also why does it want to scroll past the end of the buffer? Ugh.

Plus why are all the built-in commands like 20 characters long and camel cased?

The built-in commands are aliased, which is probably the most infuriating part; clearly they thought it necessary to name the listing functionality 'Get-ChildItem' and refer to it by that in all the documentation so as not to blow our pretty little sysadmin minds when we discover ls/dir could list more than directories now. Who knew Microsoft was fractal in nature?

Anyway, if you have to suffer PowerShell at least do it in the ISE.

You need ConEmu.

I tend to find the opposite to be true.

C-a is always "beginning of line" and Command-C is always Copy.

and never the twain shall meet.

(I've had issues in linux going from terminal to windows, in fact very recently I kept ^W'ing while in GUI mode)

Not sure if I'm falling for sarcasm, or just an outlier for feeling the exact opposite...

Same (and to be clear, this is from someone who only "switched" to OS X a few years ago because of the demands of my user community: and for the first year I hated it, as I liked neither the hardware nor OS X 10.5). So, to add some concrete-ness: what fundamentally makes OS X better at this is the way the command key is used; almost everything that has to do with the UI or the system is bound to the command key, which means that control and option are free for usage by my terminal. I thereby never run into any confusion using ctrl-c to copy something or alt-tab to switch between windows: command means nothing to my terminal, and control and option get bound to control and alt (not the default in Terminal, but its one checkbox to fix), passed to whatever actual application I'm running. On both Windows and Linux the control and alt keys tend to overlap in usage between graphical and console applications, meaning the graphical terminal I'm using invariably has some confusing overlap with the keyboard commands I might want to send to my console app. (Now, there are some unfortunate defaults in Terminal with relation to page up/down and home/end, but those are both easily fixed--a few minutes of setup before sitting down--and somewhat irrelevant as any one who even remotely cares about using a terminal should have installed iTerm2 forever ago.) (Ironically and relevantly, the reason Terminal has irritating defaults is specifically because Apple has actually been really good about having keyboard shortcuts be consistent across every application: they want option, page up, and home to do the exact same things in Terminal that it would do in any other app, even to the extent to which those behaviors are useless and counter-productive when you are actually just trying to use vim/emacs and bash/zsh like a normal person ;P.)

Everyone hates on Terminal, but I've made the changes you mentioned and I tend to prefer it to iTerm. I can't really quantify it. I definitely think TotalTerminal is superior to the equivalent feature in iTerm, and due to the nature of my work I tend to pop in and out of the visor frequently.

My key problem with Terminal is that its terminal emulation is not actually that good: I often would run into scenarios where it would miscalculate some width, fail to winch a pty across a level of screen, or get wedged in a state that reset was unable to fix, that I simply couldn't take it anymore.

Why would you even put the word "objective" in there, especially without providing any arguments? What's the point? To rile people up?

Besides totally disagreeing with you; are you aware that you can always bind you own shortcuts to any menu item via System Preferences -> Keyboard -> Shortcuts ?

It's especially painful if a Mac is not your primary development environment but you need to hack on one occasionally. I can have a familiar terminal or a familiar desktop but cannot have both simultaneously and there's no way to train myself to use the command key due to frequency.

Not just keyboard shortcuts, but straight out keys (e.g. Page up / Page down)

Cmd + Arrow keys. Simple.

Fn+up/down and Fn+left/right are easier to use and just make much more conceptual space to me than the PgUp/PgDown/Home/End key blob.

Hrm.. I don't use OSX, in my fingers... home goes to the beginning of the line, and ctrl+home goes to the beginning of the document.. If I want to select to the begining of the document ctrl+shift+home... in OSX does that mean to select to the beginning of the document it'd be something like fn+command+shift+left ?

These are command-arrow functions. Cm-left is beginning of line, Cm-up top of document, and so on. Select to beginning of document is Shift-Cm-Up, and so on.

If you're lucky enough to have an Fn key on your keyboard. Is there an equivalent for those of us who are bereft?

I wouldn't call it objective, but I've been using osx exclusively for 3 years now and shortcuts still come slower than windows, primarily because on windows I can press control and any key using just one hand by using my pinky for the control key.

I've found that lots of Windows converts haven't learned to use a thumb to hold the command key instead of a finger. Much easier to chord that way and you don't need to leave home position. It's easier for me than pinky-control since I have more dexterity in my thumbs.

I started using OS X about 6 months ago. Even though I am totally fine using the thumb now for pressing the command key, I do always feel as if I was moving an octave down on a piano keyboard (I used to learn when I was a kid).

Depending on where the control is on your keyboard (Windows vendors keep swapping FN and CTRL unfortunately, and rebinding might not be easy), I think the position of the hand is more natural - on the other hand, you might strain your pinky when pressing CTRL (or SHIFT) for long time and I haven't noticed that with using my thumb yet (and I doubt it will happen, given it is a much stronger finger).

I use that and remapping control to caps lock, for all my custom bindings in terminal.

Remap capslock to control.

I have to agree. I fought with it a while, looking for third party utilities to fill the void, but eventually I realized it was more trouble than it was worth and gave up. I guess I got used to it, because I don't even miss them any more.

If you want to change command key-centric menu shortcuts for a program, you can do that in the keyboard pane of system prefs.

No. In Linux I have global keyboard shortcuts to launch specific applications and do some other stuff. I hit a key combo and a new terminal pops up, or a new tab pops up in my browser, or a new email, or the Python shell, or whatever else I want. It launches regardless of what other application I'm currently using.

In OSX, last time I looked (maybe a version or two ago), there was really no builtin way to achieve the same thing. Command+Space then typing what I want to open is pretty close, but way more keystrokes, and not as powerful.

This have been available for many versions.

It's not quite as straightforward, but you can define custom services using Automator, and subsequently bind them to any key combo using System Preferences.

Since Automator workflows can do pretty much anything (like running AppleScripts, shell scripts, manipulating other apps etc...) you're pretty much free to do what you want.

I think I used Automator in OSX to open a terminal window after missing such a shortcut that I used on Linux. For your reference:


It won't reduce keystrokes, but if you're looking for something more powerful try Launchbar. Alternatively, Quicksilver's free, but I haven't used it in a couple years and management changed hands; so I'm not sure how good it is now.

Quicksilver nearly died, but the community resuscitated it and it is currently working better than ever (YMMV, I never used half of the crazy stuff Quicksilver can do)

Generally speaking, OS X is amazingly bad at all things UI given how good it is.

Examples? If you don't get on with the OS X UI then there is little help left for you.

Useful when copy/pasting things to share with other people in email and such:

    $ pbpaste | pbcopy
takes the current contents of the copy/paste buffer and removes color/font/background color rich formatting and puts just plain text back into the paste buffer.

And of course pbcopy and pbpaste are also very useful on their own.

You can also use shift-option-cmd-v to directly paste without markup :)

I can never remember which combination that is, but thanks.

You can override any key combination using the Keyboard preferences.

Just make a new shortcut under the All Applications group named exactly the same as the one you want to replace. http://i.imgur.com/JqBncTy.png

I've also had to add an entry for "Paste as Quotation" because that's Mail's default use of Command-V.

Quite a lot of OS X applications support pasting with matching style (Cmd+Shift+V), which does exactly the same thing.

Actually, natch's trick does just the opposite. It strips out any formatting information that may accompany the text on the clipboard.

I've used the same trick on occasion when copying text from web pages into Gmail. When you paste such text into a Gmail draft, Gmail tries to duplicate the format of the original, which is often not what you want. pbpaste | pbcopy solves the problem nicely.

Edit: But Shift-Option-Cmd-V is easier. Thanks, Janteh!

Be warned, though, that these do not work inside of a tmux session without special steps being taken. I believe that they work in screen, but tmux requires some additional work.

You have to install "reattach-to-user-namespace" which you can do with homebrew.

Then you need to add the following to .tmux.conf

  set-option -g default-command "reattach-to-user-namespace -l zsh"
There's a good writeup on what and why here, https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard/blob/...

Sweet! To take it to the next level:

pbpaste |sed 's/FIND/REPLACE/g' | pbcopy

Maybe make this into a script you can run from alfred. ;)

Also if you want to have access to pbcopy remotely, try this:


I use Plain Clip (http://www.bluem.net/en/mac/plain-clip/) for this. It also gives you optional text processing steps (e.g., remove all trailing whitespace) which are super useful.

This command has immediately become an alias in my .profile.

Nobody seems to have posted this yet:

    python -m SimpleHTTPServer
I'd recommend an alias like "serve". It basically puts the current directory online (binds to


  python -m smtpd -n -c DebuggingServer localhost:25
A makeshift SMTP server that logs all messages to the console.

It does not support large files, so sometimes I have to fall back to https://npmjs.org/package/http-server (npm -g install http-server .. then just run http-server /path)

similarly, you can get a janky json pretty printer by doing:

   curl -s http://some/json/url | python -m json.tool

When your needs stretch beyond that, try 'jq'. http://stedolan.github.io/jq/

For pretty-printing without modification,

    cat myjson | jq '.'

Am I wrong to have long dismissed this as little more than an easter egg, or, at best, a toy server to test basic webpage functionality?

Yes. It's like a ghetto SCP for giving files to people on windows who don't have SCP. You can use it for basic web functionality, you can use it (carefully) as a mechanism for testing or serving test results. I wouldn't keep it running for days, but it's an amazingly useful tool.

Whoa, never thought of it that way. The makeshift SCP is really a good idea!

I use it quite a lot to move files between my computers, stream content to my phone, test out web designs. I suppose it's like net cat, it's useful for some. I think "toy server" is fairly accurate, I can't see anyone using this in production but I can't see people installing nginx on their laptops either.

> I can't see people installing nginx on their laptops either.

OS X comes with apache preinstalled though

The only problem it really solves is if you've got non-relative paths in your HTML/CSS. I've used this a couple of times in those situations.

Just because that's the only problem you use it to solve doesn't mean that's the only problem it solves.

Sorry, wasn't trying to belittle anything (I've actually written a Mac menu bar app that does this exact thing which a couple of designer friends use).

Our build process automatically generates a directory tree of HTML-formatted unit test coverage reports. Sometimes it's nice to be able to share links to those reports in a code review. I use python SimpleHTTPServer for that.

Depends on what you're developing. If you're doing single page apps that get their data from an external service then this is incredibly useful.

Or for Python3: python -m http.server .

Or Ruby: ruby -run -e httpd .

Mind blown. Thanks!

A new one for me I accidentally found the other day..

If you use Spotlight to find something and then want to see the file in Finder, Cmd+click the item in the Spotlight dropdown.

Edited from Cmd+shift+click due to note in child comment :-)

isn't it just Cmd+click ?

In Mavricks (only one I can be sure of) when you hover over spotlight results and hold Cmd, you get a (quite nice) file preview/info.

Oh hey, so it is, even better! :)


Cmd + R is universally "Reveal in Finder".

First thing I install on a Mac is Alfred. Check it out. `space` followed by name searches directories and files.

You can also use Cmd + Return.

Under Konsole/Yakuake (KDE) its: Contextmenu -> Open Link

oo! As long as we're sharing our favourite terminal tips, here's mine: In your .bash_profile, add this line:

alias imgsz='sips -g pixelWidth -g pixelHeight'

sips stands for "scriptable image processing system"[1], and provides terminal users with a toolset for inspecting and manipulating images. The alias above is really useful for web developers who need a quick look at how big a given image is:

    $ imgsz logo.png
    pixelWidth: 500
    pixelHeight: 120
[1] https://developer.apple.com/library/mac/documentation/Darwin...

thank you!

happy to help!

Lovely, thanks. Also, is it common knowledge that CMD+click on a URL opens that URL in your default browser? Useful for the "Running on" messages.

Nice tip, thanks. However, it only works with double-click for me.

That's in iTerm, I think. In Terminal.app, it's CMD+double-click.

The first thing I do when setting up a new Mac is make the Caps Lock key into another Control key.

System Preferences > Keyboard > Modifier Keys

Saves lots of awkward pinky-bending.

I go one step further and bind it to Hyper (ctrl+alt+cmd), and use hyper for tiling window management, like "snap window top left of screen grid", etc.


Just the fact that you can disable Caps Lock is a sanity-saver: thank you!

Is it me or do Mac Caps Lock keys require you to hold them down for close to a second for them to activate? There appears to be some kind of hardware timer in them to work...?

I noticed this coming from Windows and Linux on other keyboards where tapping Caps Lock works but on Mac OSX with an Apple keyboard or on a Macbook you have to make a real deliberate effort to keep the key down longer than a nanosecond for it to register.

Is it just me who has noticed this?

I noticed this on the lock screen. Often you'd have to tap multiple times on caps lock before it even turns on. I assume it's to prevent accidental caps locking, but it can be rather irritating

It's not just you. I think it is to prevent accidentally toggling it when going for tab.

I did this on my Mac a few years back and do it on Windows machine at work. I also use Hotkeys to swap alt and ctl to match my Mac.

I have tried to use Terminal, but I just can't. The ability to highlight and automatically have the text in clipboard is such a crucial feature in my workflow that not having it even as an option is a deal breaker.

Once I started with iTerm and built a config/flow around it, I can't go back.

Thanks for the tip though! I didn't realize this worked in Terminal too. I'll keep it in mind the next time I'm forced to use it.

Check out TotalTerminal. It's a plugin for Terminal that has that feature among others. http://totalterminal.binaryage.com

Same here. Switched to iTerm for proper mouse support in Vim, and you need only click (no option key) to move your cursor in Vim if you have `mouse=a` in your vimrc.

I used to be a die-hard Terminal.app user but with Mavericks it felt incredibly sluggish doing everything from opening to listing files to editing things and this is another reason I moved to iTerm.

Be warned, though, that if you're using Vim with Solarized you and you're trapped in low color mode you want to be sure you're declared as a 256 color term and update your `vimrc` to remove the following for the colorscheme to work properly:


* let g:solarized_termcolors = 256

* let g:solarized_termtrans = 1

* let g:solarized_contrast = "normal"

* let g:solarized_visibility = "normal"

I added mouse support to Terminal via MouseTerm: https://bitheap.org/mouseterm/. Works like a charm with Vim.

Command-shift-v pastes the current selection into Terminal (and anywhere else in OSX).

This works if whatever is currently running in your terminal has support for the XTerm mouse escape sequences.

Option-click is the shortcut to tell the terminal to forward the click to the application running in the terminal. That's usually your shell or some editor.

I seem to faintly remember that at some point this was actually configurable and you could configure the terminal to forward non-option-clicks and only enable selection mode on option clicks. I didn't find this option in current iTerm or Terminal.app versions though - I might just be imagining this.

I can confirm that this works with VIM and nano

Nother related tip: command + click on a file in iTerm opens it up. Test it out by doing ls -al then cmd+click on file name.

Osx terminal uses almost all of the emacs movement keys by default. Ctrl-a and ctrl-e are useful but I find the meta movement keys to be the most helpful. (usually alt or ESC)

Meta-f jump forward a word

Meta-b jump backwards a word

It's not emacs, it's GNU Readline (or likely some BSD readline given apple and the GPL) http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html.

The shortcuts also work in every text field in the OS.

Terminal may be using some kind of Readline, I dunno. But text objects in other OS X applications use emacs keybindings because NeXTSTEP has had them since time immemorial. Like 1990 or so. Doesn't have anything to do with GNU Readline so far as I know.

> Terminal may be using some kind of Readline

Terminal.app passes the key sequences to the application running inside of the terminal. The default shell (bash) uses GNU readline, which has an emacs-mode and a vi-mode (emacs is the default).

Terminal.app does not use any Cocoa text fields, so has nothing to do with the Emacs keybindings inherited from NeXTSTEP.

It's not Terminal that uses it; it's bash, and most shells that imitate bash.

IIRC, someone mentioned to me once that bash doesn't link against libreadline, but uses libreadline (the source is directly in the Bash repo), so it's possible that it's using GNU readline, while Apple's libreadline is a BSD flavour.

It at least used to be the case that GNU Readline was GPL-licensed, instead of LGPL, as to make readline a "carrot" to encourage GPL adoption. That shouldn't be an issue for bash, which is also GPL licensed.

I'm not sure what you're suggesting here.

It's up to the process running in Terminal.app to support the key sequences sent to it. I doubt that M-f would work if your shell (bash, zsh, etc) were in Vi-mode rather than the default of Emacs-mode.

That's bash. Works on all platforms, all terminals, as long as bash has been compiled with readline.

Two more (for Bash) -

Ctrl-x, Ctrl-e will pop open your EDITOR so you can edit the command. Saving and closing the editor brings the command back in your terminal and automatically executes it.

fc will bring up your EDITOR with the last typed command. (You can use fc -l to see a list of commands)

damn.. thats the real #yearslost for me. I should have focused on learning that instead of the wordback/forward commands.

Whoa! I actually like this better than setting vi mode on terminal.

Genius! That's going to save me so much time. :-) #yearslost

Also useful is Apple's support doc listing of keyboard shortcuts. http://support.apple.com/kb/HT1343

Two more tips:

* Ctrl-a to go to beginning of line

* Ctrl-e to go to end of line

I love how osx supports emacs key-bindings by default for any text field.

I miss this feature a lot when I switch back to windows. I find myself pressing ctrl-n in my browser's address bar, expecting to view my URL history, and instead I get a new windows.

If anyone knows of a way to get similar functionality in windows, I would love to hear about it!

Cltr + D to focus on address bar. Alt + down arrow to view history.

A couple more:

* ⌘ + ` (tilde key) to switch between different windows of your current application

* ⌘ + l (lowercase L) in most web browsers to highlight the address bar

I'm always telling people about ⌘ + `, it makes navigating windows on OSX so easy.

The former is the one thing I missed the most from my OSX days...until I got a tiling WW setup (i3).

Woohoo, love me some Linux, let choice reign ;-)

to piggyback off of this... (not sure if this is in the thread already)

⌘ + ` to switch between different windows of current application

⌘ + SHIFT + ` to switch between different windows of current application (reverse order)

same for the general application switcher:

⌘ + TAB to switch between different windows of current application

⌘ + SHIFT + TAB to switch between different windows of current application (reverse order)

A lot of the Emacs shortcuts work in OS X (most of the system) as well as on Linux (bash and other users of readline).

The basic Emacs key-bindings should work in all Cocoa apps. For instance, the URL bar of your web browser, while text editing in just about any editor (maybe even in Office, but I have not tired in a while), etc. Basically, anywhere you have a cursor, the basic line-editing key bindings should work.

So, in practical terms, this means you have 1 + n clipboards[1]. The main global GUI clipboard (using the command key), and then an app-specific clipboard (using the control key with Emacs bindings). As a developer, it is extremely helpful to have two clipboards in TextMate, for instance.

[1] Technically, the clipboard in OS X maintains a history (not sure what the limit is), but the OS X GUI only exposes the last cut/copied item.

defaults write -g NSTextKillRingSize -string 4

Can you shed some light on how to access those other three from the GUI (whether using the command key or some other means)?

Sorry forgot some steps...You also have to rebind C-y to 'yankAndSelect:' (https://developer.apple.com/library/mac/documentation/Cocoa/...)

For the most in depth info on the Cocoa Text System: http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html

I use Vim and was unaware that this shortcut existed. Are there any other Emacs shortcuts which are useful in OSX?

If you do "set -o vi" you can also use vi shortcuts, such as ESC-j,k to go up/down the history, 0 to go to the beginning of the line, etc.

You cannot use 'set -o vi' to turn Cocoa text fields into vi-mode.

Ctrl-K kill to end of line,

so Ctrl-A Ctrl-K will clear a given field

And you can Ctrl-Y to paste the line you killed. This is a separate copy/paste buffer from the normal Cmd-C one, which can be nice.

Because crappy Macs have no Home/End keys (or they don't work as such).

On most macs, Fn + left/right arrow are home/end. Fn + up/down are pageup/pagedown.

Not sure if I have it set up differently but mine is Cmd-Left or Cmd-Right to move to the beginning of a line...? Easier to reach than fn (I'm using a real wired BIG Apple keyboard, the RSI inducing one...)

Fn... urgh. I hate these crippled laptop keyboards (and tiny neck pain inducing laptop monitors).

Well, you don't have to follow that glossy mainstream. Just get yourself a new linux desktop with lots of RAM, couple of nice matte monitors, mouse and a good full size keyboard.

That's what I always do. My new PC should be delivered any minute, actually (16 GB RAM; at one intensive work session my current 8 GB where almost a bit scantly - is that the right English word?).

ctrl-arrow (which breaks with Lion's Spaces default keys), or shift Home/End in Terminal.

It's not that Macs are crappy, they just have different key bindings. I regularly work with Macs, Windows, and Linux for development and I've just learned to use the different key mappings.

I don't think I'm quite as proficient in any one system because of that, though. For example, I have avoided learning the Emacs key bindings for use in Mac/Terminal. (I don't want to try to remember TWO bindings for Mac, plus I learned vim first so usually avoid Emacs.)

ctrl-arrow jumps to the next word boundary under Linux.

Yes, other systems have other key bindings, but why do common things like jumping to the begin/end of a line need a key combination? And why aren't the characters written onto the keys? Every time I have to type some code on a Mac I have to press all the keys in order to find { } [ ] etc. At leas I learned not to quit the terminal when I want to enter a @ by now. Whose brilliant idea was that?

{ } [ ] are just above the return key...?

Not on a German keyboard (forgot to mention that, sorry). Where are all the keys a programmer needs here?: http://upload.wikimedia.org/wikipedia/commons/1/11/Apple-Wir...

In contrast a German PC keyboard: http://www.buypcsupplies.com/images/cat/38568_xlargenss_ndo4...

However, I prefer a Microsoft Comfort Curve keyboard, but I can't find an image of the German version right now.

This was life changing when a co-worker showed me this last year.

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