I'm attempting to set completion-ignore-case on in my ~/.inputrc, but the option seems to be ignored. When I hit tab, only case-sensitive matches are shown.
Here's my ~/.inputrc:
# Bash input configuration
set completion-ignore-case on #Enable case-insensitive tab-complete
"\e[A": history-search-backward #Press up or down arrow to search through shell history on what you've already typed
"\e[B": history-search-forward
#"\e[1;9C": forward-word #alt-left/right to move the cursor by words
#"\e[1;9D": backward-word #I prefer to enable this in iTerm settings so it works no matter where I'm ssh'd to.
Oddly enough, the history-search-backward and -forward settings do work, so ~/.inputrc is getting read, but completion-ignore-case is getting ignored somehow.
Running bind "set completion-ignore-case on" yields the expected behavior. I also tried set-ing other variables in ~/.inputrc and they also worked fine.
I'm running MacOS 10.12.4 and bash 4.4.12(1)-release (installed via homebrew).
Try to remove the comment. This seems to make it work for me.
# Bash input configuration
set completion-ignore-case on
"\e[A": history-search-backward #Press up or down arrow to search through shell history on what you've already typed
"\e[B": history-search-forward
#"\e[1;9C": forward-word #alt-left/right to move the cursor by words
#"\e[1;9D": backward-word #I prefer to enable this in iTerm settings so it works no matter where I'm ssh'd to.
Related
I have this in my .inputrc, but Control-e doesn't move to end of line in command mode. All other bindings work.
$if mode=vi
set show-mode-in-prompt on
set keymap vi-insert
"\C-e": end-of-line
"\C-a": beginning-of-line
set keymap vi-command
"\C-e": end-of-line
"\C-a": beginning-of-line
$endif
I can see it's taking:
$ bind -p | grep 'end-of-line'
"\C-e": end-of-line
"\eOF": end-of-line
"\e[F": end-of-line
And I can see nothing else is bound to \C-e:
$ bind -p | grep 'C-e'
"\C-e": end-of-line
"\C-x\C-e": shell-expand-line
If I set it to \C-l, it works. So, what's special about \C-e in readline's vi mode that I'm not able to override?
Only other clue is \C-e causes a terminal beep.
Nothing else is in my .inputrc
I just tried and it also does not work for me. But the bind command works fine:
bind -m vi-command ' "\C-e": end-of-line '
Seems like there's something weird in readline loading .inputrc. So as a workaround you can put the bind command in your bashrc files.
According to Chet Ramey via the bug-bash#gnu.org mailing list,
This has been there forever. The default readline
vi command-mode keymap has ^E bound to switch to emacs editing mode. Since
bash uses `set -o emacs' for that, the bash readline initialization code
unbinds the key sequence. It needs to make sure that the function it's
bound to is still rl_emacs_editing_mode.
He provides a patch, which is probably beyond the scope of a SO answer here, so I'll just link to it: http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00217.html
#pynex's workaround works fine.
I'm very fond of using readline's history-search-forward and history-search-backward with bash. I have the following in my .inpurc:
# Scroll through matching history with up and down keys
"\e[A":history-search-backward
"\e[B":history-search-forward
and use the up and down keys to scroll through matching commands in my history.
However, when I enable vi-mode, it seems to stop the history search working. I have vi-mode configured thusly (also in .inputrc):
# Enable vi mode
set editing-mode vi
set keymap vi-command
# insert/command mode indicator:
set show-mode-in-prompt on
# Indicator formatting in prompt:
set vi-cmd-mode-string "\1\e[0;34m\2[\1\e[0m\2C\1\e[0;34m\2]\1\e[0m\2 "
set vi-ins-mode-string "\1\e[0;34m\2[\1\e[0m\2I\1\e[0;34m\2]\1\e[0m\2 "
When I remove the vi-mode related lines from my .inputrc, history search works fine. When I put them back, it breaks.
Is there a way to enable both features simultaneously?
I'm using GNU Bash 4.4.12 installed through homebrew on OSX Sierra.
Works for me in vi-insert mode:
set editing-mode vi
set keymap vi-insert
"\e[A":history-search-backward
"\e[B":history-search-forward
Or you can write this in the bashrc:
set -o vi
bind -m vi-insert '"\e[A":history-search-backward'
bind -m vi-insert '"\e[B":history-search-forward'
I'm having a strange issue using pgUp and pgDn to auto-complete searches from history.
I'm using bash in gnome-terminal.
type:
vim fil<pgUp>
expected output:
vim filename
Actual output:
vim fil~
Both pgUp and pgDn are printing a ~ character on the terminal instead of searching through history.
I think I have the relevant lines in my /etc/inputrc but they don't seem to be helping. Can someone tell me what I'm doing wrong here?
Here's my inputrc should anyone need it:
# do not bell on tab-completion
#set bell-style none
set meta-flag on
set input-meta on
set convert-meta off
set output-meta on
# Completed names which are symbolic links to
# directories have a slash appended.
set mark-symlinked-directories on
$if mode=emacs
# for linux console and RH/Debian xterm
"\e[1~": beginning-of-line
"\e[4~": end-of-line
# commented out keymappings for pgup/pgdown to reach begin/end of history
#"\e[5~": beginning-of-history
#"\e[6~": end-of-history
"\e[5~": history-search-backward
"\e[6~": history-search-forward
#"^[[5~": history-search-backward #these are the values read gives for pgUp, pgDn. They don't work either.
#"^[[6~": history-search-forward
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-word
"\e[5D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word
# for rxvt
"\e[8~": end-of-line
"\eOc": forward-word
"\eOd": backward-word
# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line
# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line
$endif
And my ~/.inputrc if it's relevant.
set show-all-if-ambiguous off
set show-all-if-unmodified on
set completion-ignore-case on
cat >> ~/.inputrc
"\e[5~": history-search-backward
"\e[6~": history-search-forward
I wanted vim-like navigation for my terminal, so I added:
set editing-mode vi
set keymap vi
To my .inputrc file based on this. editing-mode vi adds vi navigation. What does keymap vi do, and why do I need it?
TL;DR
If you don't want to change/add bindings in the default keymaps, you don't need the line keymap vi.
What keymap vi does is state that any bindings listed after that point apply to that keymap (which is exactly the same keymap as vi-command and vi-move).
If you want to change the insertion keymap (eg to add a Ctrl-A binding to go the beginning of the line while you're typing), you'll need to do this below a keymap vi-insert line.
If you want further info on the vi mode and maps, skip to the heading editing-mode vi (the last one).
But wait! There's a fair bit of background info that may be needed though: eg, the difference between an editing-mode and a keymap.
Particularly useful is the concept of a hybrid emacs keymap for inserting text and while still easily getting to vi-command for making changes.
What is the difference between an editing-mode and a keymap?
There are only two editing-modes: emacs (the default) and vi.
The GNU Readline Library documentation says:
editing-mode
The editing-mode variable controls which default set of key bindings is
used. By default, Readline starts up in Emacs editing mode, where the
keystrokes are most similar to Emacs. This variable can be set to either
`emacs' or `vi'.
Note the difference between editing-mode and keymap: In editing-mode vi the two (yes there's only two, read on) keymaps are swapped in and out to emulate the different modes of the vi editor. ALL the emacs ones operate at the same time in editing-mode emacs (explained later).
So what does editing-mode actually do? It just sets the active keymap upon shell startup to either emacs or vi-insert.
What are the unique keymaps?
Acceptable keymap names are emacs, emacs-standard, emacs-meta, emacs-ctlx,
vi, vi-move, vi-command, and vi-insert.
vi is equivalent to vi-command; emacs is equivalent to emacs-standard.
While not documented, vi/vi-command and vi-move keymaps are also equivalent:
+ravi#boxy:~$ diff <(bind -pm vi) <(bind -pm vi-move)
+ravi#boxy:~$
This leaves us with: emacs, emacs-meta, emacs-ctlx, vi, and vi-insert as unique keymaps to explain. Differentiating the keymaps is probably best done by inspecting them...
What are the keymaps default bindings?
To view the default keybindings for (example) emacs (the default), use:
INPUTRC=~/dev/null bash -c 'bind -pm emacs' | grep -v '^#
You can replace emacs with any other keymap name in the example above.
There are many lines saying self-insert or do-lowercase-version which aren't very useful, so to remove them:
INPUTRC=~/dev/null bash -c 'bind -pm emacs' | grep -vE '^#|: (do-lowercase-version|self-insert)$' | sort
What is the difference between the various emacs keymaps?
TL;DR: They are different views on a single set of mappings applied to editing-mode emacs.
If you the output of the second command into the files called emacs-standard, emacs-meta, emacs-ctlx, vi-command, and vi-insert for their corresponding keymaps, you can find out that:
There are NO commands mapped in emacs-meta and emacs-ctlx which don't also appear in emacs-standard:
$ comm -13 <(sed -r 's/.*: (\S+)/\1/' emacs-standard|sort) <(sed -r 's/.*: (\S+)/\1/' emacs-ctlx|sort)
$ comm -13 <(sed -r 's/.*: (\S+)/\1/' emacs-standard|sort) <(sed -r 's/.*: (\S+)/\1/' emacs-meta|sort)
$
So emacs/emacs-standard is a behaviourally functional superset of both emacs-ctlx and emacs-meta This means that:
keymap emacs
"\eg": glob-expand-word
"\C-x\C-r": re-read-init-file
Is functionally equivalent to:
keymap emacs-meta
"g": glob-expand-word
keymap emacs-ctlx
"\C-r": re-read-init-file
You might argue that the second form is easier to read.
Inserting text: emacs vs vi-insert
There are 28 commands in emacs-standard not in vi-insert
+ravi#boxy:~/lib/readline$ comm -12 vi-insert emacs-standard |wc -l
28
+ravi#boxy:~/lib/readline$
emacs/emacs-standard is basically a superset of vi-insert. So for typing text, it's best to use the emacs-standard keymap over vi-insert as long as you can easily switch between emacs and vi-command.
The only additional bindings in vi-insert not in emacs-standard are:
+ravi#boxy:~/lib/readline$ comm -23 vi-insert emacs-standard
"\C-d": vi-eof-maybe
"\C-n": menu-complete
"\C-p": menu-complete-backward
"\e": vi-movement-mode
The first 3 of these four conflict with emacs bindings:
"\C-d": delete-char
"\C-n": next-history
"\C-p": previous-history
which I resolved as follows:
set keymap emacs
"\e": "kj" # see https://unix.stackexchange.com/questions/303631/how-can-i-setup-a-hybrid-readline-with-emacs-insert-mode-and-vi-command-mode
"\C-d": delete-char # eof-maybe: ^D does nothing if there is text on the line
"\C-n": menu-complete
"\C-p": menu-complete-backward
"\C-y": previous-history # historY
"\e\C-y": previous-history
editing-mode vi
As we saw above, vi, vi-command and vi-move are one and the same keymap:
+ravi#boxy:~$ diff <(bind -pm vi) <(bind -pm vi-move)
+ravi#boxy:~$
Note that's a total of just two distinct maps which are associated by default with editing-mode vi.
When in editing-mode vi, the keymaps in use are vi/vi-command/vi-move and vi-insert (the starting keymap). Only one of these two maps is active at a time.
editing-mode vi does nothing more than set a default keymap when the shell starts, labelled vi-insert. Again, tthere is only one keymap active at a time. This vi-insert keymap maps most keys to self-insert so when you press the plastic button on your keyboard, the symbol printed on it appears on your screen.
The vi-insert keymap allows itself to be swapped to the text-manipulating keymap called vi-command/vi/vi-move by using vi-movement-mode command, bound to the ESC key by default in the vi-insert keymap.
Actually, even the emacs keymap can set the vi-like text manipulation keymap active by using the vi-movement-mode command, as in the hybrid solution mentioned above.
Or in easier language...
By default, press ESC to change to the vi-command keymap when the vi-insert keymap is active.
The vi-command keymap uses standard, single keypresses like a, b and c to move and interact with text, just like the vi editor's default or command mode. There are generally no Ctrl+key combinations. You can't insert text in this mode; the letter keys are mapped to editing/moving commands. For typing text, you switch to the vi-insert keymap (example: press i for "Insert").
Entering text is done using the the vi-insert keymap, which is active when the shell starts if you have editing-mode vi in your .inputrc file. Swap to the vi-insert keymap by pressing i for "insert" while in vi-command (or in numerous other ways for those initiated into vi).
Unless you know the vi editor, you'll probably find vi-command keys very hard to use at first, but if you get good at it, you can edit text like a long-bearded wizard.
From man readline (my emphasis):
The set of legal keymap names is emacs, emacs-standard, emacs-meta, emacs-ctlx, vi, vi-move, vi-command, and vi-insert. vi is equivalent to vi-command
Thus, in your inputrc you can specify different keybinds for the different modes, so, for example, in command mode you could yank the last argument from the previous command with Altp, but this keybind would have no effect in insert mode (in this simple setup anyway):
set editing-mode vi
set keymap vi-command
# these are for vi-command mode
"\e[A": history-search-backward
"\e[B": history-search-forward
"\ep": yank-last-arg
set keymap vi-insert
# these are for vi-insert mode
"\e[A": history-search-backward
"\e[B": history-search-forward
Control-l: clear-screen
Having recently switched to vi-mode in bash, the one thing I miss is esc . to get the last argument of the last command.
I know about ctrl _, but I always end up hitting ctrl - instead.
Is there another vi-mode equivalent for this?
I believe the closest solution to what you want is this:
In your .bashrc, right after "set -o vi"...
set -o vi
bind -m vi-command ".":insert-last-argument
This tells your bash to invoke the "insert-last-argument" action when '.' is used in vi-command mode. This of course means that you lose the normal "." functionality of VI; but if you are like me, you'll prefer this.
Addendum:
You may also want Ctrl-A, Ctrl-E, Ctrl-W and Ctrl-L to work (those were the ones I was missing the most):
bind -m vi-command ".":insert-last-argument
bind -m vi-insert "\C-l.":clear-screen
bind -m vi-insert "\C-a.":beginning-of-line
bind -m vi-insert "\C-e.":end-of-line
bind -m vi-insert "\C-w.":backward-kill-word
You can also use the following to restore the emacs "escape-dot inserts last argument" behaviour in vi mode:
bindkey -v '\e.' insert-last-word
By altering or adding ~/.inputrc
To restore certain bash goodies in vi-mode, simply alter or add ~/.inputrc like this:
set completion-ignore-case on
set show-all-if-ambiguous on
set show-all-if-unmodified on
set editing-mode vi
set keymap vi-insert
$if mode=vi
"\C-a": beginning-of-line
"\C-e": end-of-line
"\C-l": clear-screen
"\C-n": next-history
"\C-p": previous-history
"\C-w": backward-kill-word
"\e.": yank-last-arg
"\e_": yank-last-arg
$endif
Here are more bindable readline bash commands.
I always used alt . to get the last argument of the last command.
Also, the !$ will give you the last argument of the last command executed. There are a bunch of cool things you can do with the exclamation point, just check out the man page for bash and search for History Expansion.
How about just using $_ bash variable?
I'm pretty sure you can still use the equivalent for vi mode, which should be "ESC + ."