Reverse search using pgUp and pgDn - bash

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

Related

Why can't I set \C-e in inputrc to be end-of-line for vi-command keymap?

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.

"set completion-ignore-case on " ignored in ~/.inputrc

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.

Using vi mode in readline/bash appears to break history-search

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'

map jj to Esc in inputrc (readline)

How can I map jj to Esc in inputrc so it gets picked up by apps using GNU Readline (python, mongoshell, ...)
all works fine on zsh using:
bindkey -M viins 'jj' vi-cmd-mode
this is my current inputrc:
set editing-mode vi
set keymap vi
# turn off the stupid bell
set bell-style none
$if mode=vi
set keymap vi-command
"gg": beginning-of-history
"G": end-of-history
#"jj": vi-movement-mode
set keymap vi-insert
"\C-w": backward-kill-word
"\C-p": history-search-backward
$endif
You should rearrange the inputrc so the commented line comes after set keymap vi-insert.
Like this:
set bell-style none
$if mode=vi
set keymap vi-command
"gg": beginning-of-history
"G": end-of-history
set keymap vi-insert #notice how the "jj" movement is
"jj": vi-movement-mode #after 'set keymap vi-insert'?
"\C-w": backward-kill-word
"\C-p": history-search-backward
$endif

How to map Delete and End keys on tcsh shell?

I use tcsh , and when Delete/End is pressed on cmd line, it simply shows up as ~ ; I have to press <Ctrl><e> to go to end of line. Can anyone help me to be able to use Delete/End keys as their name suggests ?
Those keys already worked on my Debian system. I found these commands in the /etc/csh.cshrc file:
if ($?tcsh && $?prompt) then
bindkey "\e[1~" beginning-of-line # Home
bindkey "\e[7~" beginning-of-line # Home rxvt
bindkey "\e[2~" overwrite-mode # Ins
bindkey "\e[3~" delete-char # Delete
bindkey "\e[4~" end-of-line # End
bindkey "\e[8~" end-of-line # End rxvt
endif
You need to use the bindkey builtin. See the tcsh man page discussion for details (search for 'bindkey'), but you want to add a line like
bindkey [end] end-of-line
to your .cshrc or .tcshrc file, replacing '[end]' with the actual end keypress. See this page for the list of binding names and helpful examples.
There's a great resource on fixing inconsistencies with delete/backspace here. The document also addresses mapping home/end, though that's not the focus.

Resources