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.

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