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
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?
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.
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:
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:
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.
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.
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
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.
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.
!$ 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.)
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
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.
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".
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.
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.
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.
Edit:
> 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.
> 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.)
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.
> "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.
> 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.
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"
activate
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.
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.
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.
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.
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 :-)
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.
- 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).
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.
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.
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.
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.
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.
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 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.
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.
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.
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)
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.
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.
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.
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)
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.
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.
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.
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:
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 http://127.0.0.1:5000/" messages.
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.
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.
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
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.
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:
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.
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)
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.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.
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.
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.
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)
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!
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.
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...)
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?
Increase or decrease volume by small increments: alt + shift + volume up / volume down or brightness up / brightness down.
Also Alfred and Shortcat app.
OSX also features a lot of neat trackpad multitouch commands that some might not be aware of (my Windows trackpad doesn't understand multitouch.)
Two fingers: up/down: scroll up/down, left/right: forward/back in some browsers (such as Chrome)
Three fingers: up/down: show/hide a list of applications/desktops; left/right: switch desktops one at a time.
Five fingers together/apart: show/hide desktop
Before I discovered these, I was confused why I would occasionally see the forward/back arrow in the browser for a short period of time, not realizing that it showed because I happened to use a couple of fingers to move the mouse cursor.
The OP tip is nice to have built-in now. If I recall correctly, this was an option that had to be turned on in Terminal Preferences in earlier releases.
Another fave of mine: Ctrl-w for deleting whole "words" at a time. Better than holding that delete key down.
The default shell for OS X appears to be bash (my favorite shell as a Linux user as well).
Great link, I spent a good while digging through there when I first found it. My favorite is using mdfind to leverage Spotlight for file search. Results come up instantly.
You can also CMD+click and drag (or double click as long as it's not a URL, which will open) to add to the text selection (like multiple cursors in Sublime Text 2).
Also, Option+click and drag gives you column selection mode.
If you'd rather not use the mouse, the fc command will open the last-executed command on vim (this is configurable, I suppose), saving and exiting the file executes the command!
So I see a lot of comments in this thread about OSX has a much cleaner interpretation of Command-C vs Ctrl-C in Linux. Actually, the problem is that you should NOT be using ctrl-c to copy in linux.
the global copy command in Linux obeys the CUA [1] standard. Copy is defined to be "Ctrl-Insert" and paste is defined as "Shift-Insert". This will work on all kinds of user interfaces on Linux - including the cmdline, the browser, etc.
However this is an issue which I dont know is a bug or something (I'm on Ubuntu 12.04) - if you open "System Settings" in Ubuntu and copy text from there, I'm not able to paste it on the browser, but am able to paste it everywhere else using the command sequence described above.
I wish there was a way to make the mouse cursor stand out more when (and only when) it's over the terminal. Maybe it's because I use a dark terminal background, I can hardly ever see the thing.
There's a system wide setting to make the cursor huge, but I don't want a huge cursor everywhere. And there's a terminal preference to make the insertion cursor different, but that's a different cursor, not the mouse cursor.
When do I want to see the mouse cursor? It's useful for things like highlighting a git hash or a few lines of text for copy/paste.
in windows theres something where you can press controll and it will shoot circles out from your mouse which is pretty useful, not sure if there is anything like that in osx
There's a free app called Go2Shell that adds a button to finder to open the current directory in Terminal/iTerm. Also works great in conjunction with "open ."
I'm a bit late, but it's useful to know that while dragging, keystrokes are handled normally. Using the parent comment's operation as an example, you can start dragging a folder in the Finder, then Command-Tab to the terminal (or hover over the Dock icon and then hover over the proxy window), Command-` to a particular terminal window, or Command-N to open a new one, and then type "cd " before finally dropping the file. ("cd " is nicely left-handed for those using the right hand for the pointing device.)
Off-topic, but related: does anyone know a way to bind a key, and F-key for example, to a particular application in OSX? The behavior I'm looking for is almost achievable with Spaces - but it's basically when you hit the combo from anywhere, the target application comes to the foreground, or if it's not running, it launches.
Command-Tab is fine and dandy, but I want more stability in my application switching. And if it doesn't exist, I may have to dust off XCode like I've been threatening to do for a while now.
These two commands replace 'cd' and work with a directory stack of different paths.
$ pushd tmp # cd to tmp and remember current path /
/tmp /
$ pwd
/tmp
$ cd /usr # normal cd to wherever you want...
$ pwd
/usr
$ popd # pop the stck and get back to the previous path
/
$ pwd
/
Subsequent pushd will stack multiple paths.
It's a built-in of bash and other shells. It works even with Windows' cmd.exe
Regarding OSX Terminal, I'm an heavy user since Leopard but it's a shame that after upgrading to Mountain Lion (an now Mavericks) I discovered that they broke VIM vertical selection since control-shift does not generate a keycode anymore [1].
Anyone with the same problem? I tried iTerm recently and I don't like it! :-(
Another useful fyi that I haven't seen anybody else mention is the Bash framework bash-it [https://github.com/revans/bash-it/]. It has tons of fantastic plugins, aliases and themes out of the box.
I've only tried it on iTerm2, but as it only replaces your .bash_profile file it should work fine on Terminal.
set -o vi does the trick for vim. Most vi commands work, but when you type <ESC>v this will open vi to edit your command line, in case you feel any command is missing.
I've b een using vi-mode in the shell for a while,but haven't been able to get the <ESC>v behavior you described. Did you have to do anything to make that behave?
bash uses GNU readline, while ZSH has it's own readline. IIRC the Emacs-/Vi-modes in bash are support from readline. (this is also why you configure some of these things via .inputrc for Bash rather than .bashrc).
Doesn't work on iTerm2, which y'all should be using anyways. Besides being infinitely more configurable, and getting tabs right, it's also much faster when you are printing a bunch of text. No idea why OS X Terminal is so slow when it comes to this, but it's actually painful to `cat` a file of more than a thousand lines.
I don't cat files too often in my workflow so I guess I don't have that pain point, but I find find iTerm2 has this minor annoying latency (kind of like typing on a wireless keyboard on low battery) that ultimately drove me away from it.
Odd. I have never experienced that problem. I don't cat files, but I list git diff output, view log files, etc. Even a large-ish git blame introduces a noticeable lag.
In MacTerm, command+option+click will move the terminal cursor in the same way by simulating keys. It also moves “up” or “down”, for applications such as text editors that understand vertical arrows. There is even a preference setting that attempts to move the cursor automatically to wherever you drag and drop text with the mouse.
If you want to invoke a command in the menubar quickly - such as applying filters in Photoshop - hit Cmd + Shift + ?. Thill will bring up the Help Search menu and you can type the name of the menu item you want to invoke. Then just hit Enter and it’s done!
I like checking the box in preferences to use Option as Meta, and then option + left/right will jump a word at a time, and option + backspace will delete the previous word, just like in most Cocoa apps.
Go to Keyboard Shortcuts in System Preferences and remap "Send reset" to cmd+ctrl+R or something, because it saves sanity when going back and forth between vi in a term and a browser.
I've found that maxing out the key repeat rate makes life better.
System Preferences > Keyboard. Select the keyboard tab then move the Key Repeat slider all the way to the right.
Or you could set up your .inputrc to make arrow keys (eg., ctrl+arrow to jump between words) work properly. It also helps to learn the other Readline shortcuts (ctrl-A for home, etc.).
another one, you can drag files and folders onto the terminal and it will paste the path in at the cursor position... very useful to cd to some path you have open in Finder
I never understood the rationale of this behavior (not being able to just click anywhere to set the curser position). At least in not-yet-executed input.
Terminal.app wasn't very good back in the day; I think a lot of people ended up on it because of that and never went back. Also, CMD-click is far nicer for opening links than CMD-doubleclick :)
in .inputrc, I enable vi mode, and borrow some handful emacs keybindings(c-a beginning-of-line, c-e end-of-line, c-k kill-line etc) under vi insert mode, so I can get benefits from both worlds, just like what I did under vim :)
Perhaps it's simply personal preference, but I do find that limiting my mouse usage has resulted in real, tangible gains. I don't know how feasible that is in GUI-first operating systems like OS X, though.
Doesn't work in mine either (Build 1.0.0.20130319). So it appears that we just need to upgrade, as others report that it works in more recent versions.
Terminal does the same (for me). It's because opt-clicking above the line sends some up arrow keystrokes, which the shell interprets as moving back in history. In iTerm2 nightly builds (which are less stable than the betas) you can disable opt-click to move the cursor in prefs>profiles>pointer.
What's more interesting is the possibility of using the new shell integration features (https://code.google.com/p/iterm2/wiki/ShellIntegration) to turn off this feature just at the shell prompt. I'll open a feature request for that :)
I saw this too... It looks like when you opt-click above the current line, it jumps back in your history by... the same number of lines as your cursor is above the current line? Sort of an unusual feature. Nevertheless, when I'm careful to actually click on the current line, it works as described.
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.