In vim, to find a character you can use 'f' to find the next matching character in the line that your cursor is on, and 'F' to find the previous matching character in the line that your cursor is on.
Is there a way to move around like that on the bash command line?
I know that you can set bash to be in vim mode, by saying set -o vim, and this works great for my local machine, but I administer a lot of machines where I can't change that setting.
Ignoring for a moment the security issues associated with everybody in your office sharing the same user, you could add a key binding to the readline command character-search:
# ~/.inputrc
C-]: character-search
To use the search, type Ctrl-] followed by the character you want to search for. You can bind the command to any key sequence, not just Ctrl-], but for obvious reasons you probably don't want to emulate vi mode by binding it to the letter f.
This would be less invasive than turning on vi mode so most users would probably not even notice the change. However, somebody could easily stumble upon your key sequence by accident and become very confused. You would also have to use three keystrokes instead of the two you're accustomed to with vi.
Related
When I'm in insert mode in vim and I use the arrow keys, it sends what seems like a letter and a carriage return. For example, pressing ↑ it sends:
A
It looks like A\n but I'm not sure exactly what characters/codes it's sending. Why does this occur, and is there a way to disable this?
The usual sequence sent by a terminal for the Up arrow is <Esc>OA or ^[OA (the ^[ sequence represents the <Esc> key, also equivalent to Ctrl+[.)
If your Vim fails to recognize this sequence as the Up arrow, it will end up executing this sequence: <Esc> which will leave Insert mode and go to Normal mode, then O to insert a new line above the current one and go to Insert mode, then insert a literal A since you'd be in Insert mode again.
You can confirm that this is indeed the sequence your terminal is sending Vim by typing Ctrl+V followed by the Up arrow in Insert mode. (Ctrl+V in Insert mode inserts the next character literally.) I'd expect you'd see the ^[OA sequence inserted.
Then you can check what your Vim thinks the sequence for the Up arrow is with the :set <Up> command. I'd expect you'd see something like:
t_ku <Up> ^[OA
(t_ku is the internal name for the setting corresponding to this Up arrow key. You can also use :set termcap to see all Vim settings related to the terminal, including the special key codes.)
If either of these don't match the expectations, that would explain why your Vim is not recognizing the Up arrow key. (One alternative explanation is that 'ttimeoutlen' is set too short, but I'd say that's highly unlikely.)
These settings are usually managed by the 'term' setting. By default, it's set based on whatever you have for $TERM on your shell outside of Vim.
You can start by looking at what Vim thinks 'term' is, and where it's set from:
:verbose set term?
term=screen-256color
Last set from ~/.vimrc line 100
The :verbose part asks Vim to tell you where it's set from, so you'll see if your vimrc or one of your plug-ins is overwriting it. If Vim shows none of that, it means it's coming from the $TERM variable in your shell.
So look at what $TERM is set to outside of Vim and see if that seems to be correct or not. Are you setting that explicitly somewhere? Be it one of the shell's initialization files or perhaps from your terminal emulator itself?
Also possibly relevant whether you're using tmux or screen, in which case you should double check that $TERM is also set correctly both inside tmux or screen, but also outside it.
Hopefully all these hints should lead you in the right direction fixing this. If you can't figure out, post your findings as comments on this answer and I'll update it with more specific fixes you can try.
You're probably in vi compatibility mode. try :set nocompatible
If that makes it function as you would like, put set nocompatible at the top of your vimrc file to get it to default to this behavior.
When using Mac OS X including iTerm, I can simply press
Shift+$ and the line in bash that I am currently tiping will get a # added to the beginning and the line returns. I like this very much as it prevents from actually executing that command while still editing it and I don't have to jump to the beginning of the line to insert that # character there.
However, when I log onto our cluster, this functionality is lost. I tried to search for this feature but only found posts about using sed etc. so suggestions which are not for the interactive kind of using bash that I am referring to.
Could somebody please point me to a resource where this functionality is explained (bash-guide?) so I could look up how to make it work when logging in to other machines? Or is this something Mac/iTerm-specific? But then, I would expect it to work also on our cluster, as long as I use my machine of course.
This might work for you
See insert-comment (M-#)
Open up irb and
type gets. It should work fine.
Then try system("choice /c YN") It should work as expected.
Now try gets again, it behaves oddly.
Can someone tell me why this is?
EDIT: For some clarification on the "odd" behavior, it allows me to type for gets, but doesn't show me the characters and I have to press the enter key twice.
Terminal input-output handling is dark and mysterious art. Anyone trying to make colorized output of bash work in windows PowerShell via ssh knows that. (And various shortcutting habits like Ctrl+Backspace only make things worse.)
One of the possible reasons for your problem is special characters handling. Every terminal out there can type characters in number of different modes, and it parses its own output in search for certain character sequences in order to toggle states.
F.e. here one can find ANSI escape code sequences, one of possible supported standards among different kind of terminals.
See there Esc[5;45m? That will make all the following output to blink on magenta background. And there is significantly more stuff like that out there.
So, the answer to your question taken literally is — your choice command messes something with output modes using special escape sequences, and ruby's gets breaks in that quirk special mode of terminal operation.
But more useful will be the link to HighLine gem documentation. Why one might want to implement platform-specific and obtrusive behavior when it is possible to implement the same with about 12 LOC? All the respect for the Gist goes to botimer, I've only stumbled into his code using search.
Lots of times I'll use Ctrl-R for reverse search and mistype some letter. Bash jumps up hundreds of lines and I'm in the middle of commands I was using a week ago.
Is there a shortcut for jumping back down to the lastest commands I had typed?
Edit: after testing it out on a CentOS server and Mac OS X, it looks like this only happening on OS X.
I've struggled with this same issue.
You can solve this by aborting with ctrl-c. Whether you're in the middle of a reverse search or scrolling through history with the arrows, aborting returns you to a prompt with the history scroll just after the last command.
UPDATE
Here's a nice trick I just learned. Bash and many other programs use Readline under the hood for command-line interpretation. Key bindings for Readline can be configured in a .inputrc file or with the bind command. The bindings can make use of a few functions provided by Readline. For example, I use Bash in vi mode but I still like to use Emacs-style ctrl-A so I have this line in my .bashrc file:
bind '\C-a:beginning-of-line'
To list all the available Readline functions:
bind -l
Among the functions is end-of-history. The function does like its name suggests. The difference between this approach and just using the abort command is that this keeps you on the same prompt.
If using libreadline, Alt-> (or Meta->). More info on Readline shortcuts or search for Commands for Manipulating the History in the man page.
On Mac, try command + .
It works for me.
I was trying alt+. and alt+shift+. , neither works for me. And then found command + . actually works
Maybe not exactly what you want, but you can fix your mistyped character(s) by using backspace when you're in the CTRL-r (reverse-i-search) mode.
You may wan to try "suggest box"-like history HSTR. It reads the bash history and allows quick navigation and filtering - you can see the context of similar history entries. Once you select a history entry it can be edited on the command line.
In Zsh with emacs binding set the actual default key sequence is ^[> binded to end-of-buffer-or-history command rather than command-. suggested above (or end-of-history depending on effect you want to achieve)
Cmd-. produces in Apple Terminal the similar or the same key sequence as Ctrl-C, which can be confirmed by running something useless and long, e.g. find . >/dev/null 2>&1 and pressing one and then other keys on keyboard.
Ctrl-C forces input to be ended and reset. and history scroll is just a side effect for it.
I'm trying out the coffee script repl inside Emacs (under ArchLinux) and I'm seeing these escape characters surrounding the prompt:
[1Gcoffee> [0K[9G
These shouldn't be colors as I already enabled the ansi-color-for-comint-mode. So does anyone recognize these?
P.S.: Funny thing is I don't have this issue under my Emacs+Cygwin setup!
I don't know where they're coming from (something to do with your shell prompt, obviously, but it's hard to say more than that).
I read them as:
ESC[1G - Move to column 1 (Cursor Character Absolute)
ESC[0K - Erase to right
ESC[9G - Move to column 9
It looks like an attempt by the shell to ensure that the prompt is at the far left of an empty line. Not sure what shell you have, but zsh does something similar when the PROMPT_SP option is enabled. I don't think it uses the above sequences, though.
Many, many, control sequences can be found here. Note that the sequence "ESC[" is interpreted as a "Control Sequence Introducer" (CSI) and is shown as that on that page.
I had the same problem and was able to solve it by adding
export NODE_NO_READLINE=1
to my .bashrc file.
So, the characters appear to have come from the CoffeeScript REPL's use of Readline. Perhaps the reason you didn't have the issue in Cygwin was because Readline wasn't available there.