When I first created my .inputrc (it didn't exist by default), I set vi-ins-mode-string to "+" and vi-cmd-mode-string to ":" to differentiate between modes. I didn't have "(cmd)" or "(ins)" prepended to my prompt by default, but later decided I did want those to show up instead, so I changed those options in my .inputrc. However, the "+" and ":" continue to be prepended to my bash prompt and I don't know why. I've tried sourcing .inputrc with source and bind, I've exited all instances of my terminal, but nothing works. Is there something I'm doing wrong here? My .inputrc is currently: set show-mode-in-prompt on set vi-ins-mode-string "(ins)" set vi-cmd-mode-string "(cmd)" **Edit:** when starting python's interactive cli from inside a virtual environment (created with conda, if that's important), the (ins) and (cmd) get appended appropriately. It's only on my regular bash commandline that the "+" and ":" continue to show up.

I was reading about key-bindings in Bash. They seem to be based on Emacs but offer the ability to switch to vi based ones. You can do set -o vi in your .bashrc to effect Bash, but I saw there was also an option to edit a file called .inputrc by adding the following line: set editing-mode vi By editing .inputrc instead of .bashrc all programs which use the GNU Readline Library will switch to vi keybindings. I probably won't switch the bindings as I'm use to the Emacs ones now and I like using defaults, but this fact has gotten me curious about GNU Readline and .inputrc. What popular utilities and programs make use of this library?

I want disable autocomplete (pressing to Tab to complete my command automatically) on my Bash on Linux, but keep the double-Tab shortcut for showing suggestions, so that I can type the rest of the command myself.

As inputrc only has "if", "else" and "endif" and does not have an "else if" conditional statment, are nested conditionals permitted, viz a second "if" within an "else" block? For example

$if term=lxterm
 ...
$else
$if term=rxvt
...
$else
$if term=xterm
...
$endif
$endif
$endif

I'm using bind -x in vi-command mode to remap a keyboard character to a direct bash command, which in my case alters the current line (cd ..). Is there a way to at the same time map with -x AND execute the inbuilt redraw-current-line command? So this is what I have:

bind -m vi-command -x '"-": "cd .."'

This works halfway, then I tried this:

bind -m vi-command -x '"-": "cd .."'` "-":redraw-current-line

But this doesn't work, I think the whole command is now flawed and readline goes back to the custom shortkey for - which is to scroll history. Is there a workaround for this?

I've got in my .inputrc something like "\C-v": "script.sh " I use a link from my clipboard as a parameter for the script, so I type ctrl-v and then paste the link, and then hit enter. So I've seen that you can use "paste-from-clipboard" to actually paste something. Is there a way to get this done alltogether by .inputrc? Something like "\C-v": "script.sh ", paste-from-clipboard, "\n"

I'm tweaking with GNU Readline's key bindings in Bash. Specifically, I wish to achieve the following mapping effect: Control' ==> 'I' ControlShift' ==> "I" Control\ ==> I ` Control[ ==> [I] ControlShift[ ==> {I} where I indicates the cursor position after expansion. I have tried the following configuration in my ~/.inputrc. However, only the ```` mapping works as expected: $include /etc/inputrc $if mode=emacs "\C-\'": "\'\'\C-b" "\C-": "`\C-b" "\C-\"": "\"\"\C-b" "\C-{": "{}\C-b" "\C-[": "[]\C-b" $endif I'm wondering what is wrong with my configuration and how to make these mappings correctly (if possible)?

The title says it all. I have set -o vi set for readline, but whenever I hit enter and execute a command, the new line will start in insert mode and I'll have to manually exit. Is there are an option or workaround to always start each new line in vi command mode?

I am trying to get bash tab completion to work as I would like, but the options do not seem produce the results I would expect. I am using bash 4.2.46 [4.2.46(2)-release (x86_64-redhat-linux-gnu)], which I cannot change or update due to my organization's restrictions on the system I am using. The contents of my inputrc are as follows:

# Tab Completion
set show-all-if-ambiguous on
#set show-all-if-unmodified off
set menu-complete-display-prefix on
TAB: menu-complete
"\e[z": menu-complete-backward
set mark-directories on
#set mark-simlinked-directories on
set completion-query-items 40
set completion-ignore-case off
set skip-completed-text on

# Current Line Navigation/Editing
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[1;3~": kill-word

# History
"\e[A": history-search-backward
"\e[B": history-search-forward

# Other Settings
set bell-style visible

--- Let's say I have 3 directories in the current working directory, test1, test2, and tes1. With the inputrc provided above, if I type cd t I would expect: - First TAB: complete to cd tes (per menu-complete-display-prefix); display the possible matches, because they are ambiguous. - Second TAB: begin cycling through the options per menu-complete What happens: - First TAB: Shows all possible matches, begins cycling through per menu complete (completes to cd tes1/) - Second TAB: cylces through to cd test1/ - Third TAB: cycles through to cd test2/ - Fourth TAB: cycles through to prefix cd tes --- If I comment out set show-all-if-ambiguous to off and uncomment #set show-all-if-unmodified on, I would expect: - First TAB: complete to cd tes - Second TAB: Begin cycling through per menu-complete; display all possible matches (not sure on this one, but I think that's what it's supposed to do based on the descriptions in man bash) What happens: - First TAB: completes to cd tes - Second TAB: begins cycling through per menu-complete (completes to cd tes1/); does NOT display all possible matches - Third TAB: cylces through to cd test1/; does NOT display all possible matches - Fourth TAB: cycles through to cd test2/; does NOT display all possible matches Does anyone know what might be causing this? Is it incorrect behavior in my bash version? Is it related to my other inputrc settings? Note: I also have a windows machine where I am running git bash with bash version 5.2.26(1)-release (x86_64-pc-msys) and the show-all-if-ambiguous setting works exactly as I expect. The show-all-if-unmodified setting doesn't work quite as I expected, but that may be because I am not properly understanding how it is supposed to work. --- As a side note, the result I am shooting for is: - First TAB: completes to cd tes - Second TAB: starts cycling through per menu complete; displays all possible matches

Im trying to customize my prompt as well as with the editing mode at the prompt. But i'm having some troubles with the non-printing characters in the variable vi-cmd-mode-string and vi-ins-mode-string. > ~/.inputrc: >

>set show-all-if-ambiguous on
>set completion-ignore-case on
>set print-completions-horizontally on
>set horizontal-scroll-mode on
>set colored-stats on
># vi style keystrokes
>set editing-mode vi
>set show-mode-in-prompt on
>set vi-cmd-mode-string \1\e[42;30m\2cmd\1\e[0m\2
>set vi-ins-mode-string \1\e[43;30m\2ins\1\e[0m\2
>
>"\C-n": menu-complete
>"\C-p": menu-complete-backward
>TAB: menu-complete
>

When i enter Bash it starts in insert mode, when i press Escape the place of the mode it just *prints some of the characters literaly* from the variables. They are enclosed between \1 and \2 so what did do wrong? What did i misinterpret from the manual? Here is an demonstration of the issue: This just happens when I use the \1*non-printable_sequence*\2. I've already enclosed all the string in quotes (") and nothing. - Bash version: 5.2 - Terminal emulators: Tilix v1.9.4 and Windows Terminal v1.20.11781.0 Both showed the same thing. Don't think they have something to do with it. - OS: Ubuntu 22.04 **P.S.**: resizing the emulator window it works again.

I was just reading the readline man-page and discovered a bunch of great commands I didn't know about. However, several don't have default key bindings. Is there a way to execute the unbound commands from the shell? I'm not asking how to bind the command in ~/.inputrc, but instead how to execute it as a "one off" from the shell or in a bash script. For example, the "dump-variables" command. Is there some command I can feed "dump-variables" to as an argument to have it executed?

I use Colemak + Bash Vi mode, and have remapped h j k l to h n e i in .inputrc. The original N n keys for repeating search seem to be bound to the same command:

$ # Run in command mode
$ bind -p | grep vi-search-again
"N": vi-search-again
"n": vi-search-again

So I tried remapping this command to K k:

set keymap vi-command
    "n": history-search-forward
    "N": ""
    "K": vi-search-again                                                     
    "k": vi-search-again

After restarting Bash, vi-search-again has been remapped:

$ # Run in command mode
$ bind -p | grep vi-search-again
"K": vi-search-again
"k": vi-search-again

But pressing K k during a "\/" search produces no response. What is the correct way to remap this command?

Im writing the ~/.bashrc file.
I want to bind, Alt-c to Ctrl-u.
So that when I press Alt-c. The functionality of Ctrl-u should happen.
Ctrl-u clears the text on the terminal. So Alt-c should now do that. I have the following text: # Avoids default mapping. # set bind-tty-special-chars off # Solves error: 'bind editing not enabled.' # But prevented me from using Control-p/n. set -o vi; # Up Directory (Alt-j) bind '"\ej": "cd ..;\r"'; Which successfully binds alt-j to the code "cd ..;"
But I don't know how to map alt to a Ctrl mapping. It probably has something to do with the "set -o vi". But I can't remove it without getting the bind error. Also, unsetting "set -o vi" causes side effects such that i cannot press tab in the terminal anymore. They also say that its just a choice between emacs and vi, so I think for my future its best if I could simply have set -o vi on, for im completely in Vim. I have also tried having the following before the set -o vi, it doesn't work. # Clear Text (Alt-c) bind '"\ec": "Control-u:"'; But anyways.
How do I map Alt-c to Ctrl-u?

Is there a way to make zsh use readline reading /etc/inputrc and ~/.inputrc instead of zle module? I keep my command-line key bindings in inputrc to be applied globally to all other "shells" who use it like those of sqlite, mysql etc. I think zsh should be compatible with bash and offer such an option.

It seems that clear and bash Ctrl-L are quite different; clear completely removes all previous terminal information (so you cannot scroll up) while Ctrl-L just scrolls the screen so that the cursor is at the top of the page so that you can still scroll up and see previous information. I much prefer the Ctrl-L system. Is there a way to override clear so that it does a Ctrl-L instead of wiping all previous terminal information? This is not a huge issue, but I'm just wondering out of curiosity if there is a way to alias clear to point at my preferred Ctrl-L functionality. As a side note, I just noticed that PowerShell also has a binding for Ctrl-L and it performs the same way as Ctrl-L on bash; it seems that the PowerShell designers there took a lot from bash, while cmd.exe consoles do not have this functionality.

I would like to be able to copy and paste text in the command line in Bash using the same keyboard bindings that Emacs uses by default (i.e. using C-space for set-mark, M-w to copy text, C-y, M-y to paste it, etc.). The GNU Bash documentation says that Bash comes with some of these key bindings set up by default. For example, yanking (C-y) works by default on my terminal. However, I can't get the set-mark and copy commands to work, and they don't seem to be bound to any keys by default. Usually, the way a user can define her own key bindings is to add them to .inputrc. So I looked and found the following bash functions in the documentation that I presume can help me define the Emacs-like behavior that I want (i.e. set-mark with C-space and copy with M-w). copy-region-as-kill () > Copy the text in the region to the > kill buffer, so it can be yanked right > away. By default, this command is > unbound. and set-mark (C-@) > Set the mark to the point. If a > numeric argument is supplied, the mark > is set to that position. If I understand correctly, the above means that copy-region-as-kill is not bound to any keyboard sequence by default, while set-mark is bound to C-@ by default. I tried C-@ on my terminal, but I don't think it runs set-mark because I don't see any text highlighted when I move my cursor. In any case, I tried adding keyboard bindings (M-w and C- ) to the functions copy-region-as-kill and set-mark above in my .inputrc and then reloading it with C-x C-r, but this didn't work. I know that my other entries in .inputrc work because I have other user-defined keybindings defined in it. Is there anything I am doing wrong? Am I missing anything?

I cannot make tmux recognize Ctrl-Left-arrow sequence differently from just a left arrow, and the same for the right arrow too. In my ~/.inputrc, I have mapped these sequences (as issued by 2 different terminal emulators, namely putty and mobaxterm) to jump over words in command line: "\eOD": backward-word "\e1;5D": backward-word This works in an ssh session just fine, but both screen and tmux do not distinguish between arrows and control-arrows. Naturally, [the recommended solution is to enable the option xterm-keys in tmux by adding the global option into ~/.tmux.conf, and there is direct evidence (besides the "thanks" comments to the above solution) that this works for other people. But for me, Ctrl-Left-arrow sends the same code, ESC D, as does Left-arrow. I have confirmed that the option is indeed set by checking tmux options with :show-window-options -g and even set it just in case for the current window manually with :set-window-option xterm-keys on but all this to no avail. tmux reports version number 1.8 with tmux -V. What else may I check to troubleshoot this problem?

I want to set the backspace key to the usual backward-delete-char in vi-command mode. In bash, ctrl-v + outputs ^?. I've tried the following in my ~/.inputrc file but find that `` has not been remapped.

set editing-mode vi
set keymap vi-command
control-?: backward-delete-char
"^?": backward-delete-char
backspace: backward-delete-char

I'm learning BASH scripting, and I upgraded my BASH to version 5.1 using Homebrew. When I try typing "y", I just get a sound. When I run a script with a letter "y" in it, I get the message “y: no key sequence terminator”. My research suggests that it has to do with the .inputrc file. That file contains only 4 lines:

set completion-ignore-case on
set show-all-if-ambiguous on
TAB: menu-complete
y

I've tried using nano to delete the "y" as the last line, but I can't write the file back to the directory. Am I correct that the last "y" is the problem and should be deleted? If so, how? If not, what else could I try? Any help would be appreciated. Thanks! PS: I don't have this problem when using the zsh shell. I get the message " [ Cannot open file for writing: Permission denied ]" when I try to save the nano back to .inputrc. I'm not sure what the second comment means - sed --in-place....? SOLVED MY OWN PROBLEM! I used ‘sudo’ to get permission to write to .inputrc. I deleted the letter ‘y’ from the file, and then I could use the letter ‘y’ in the BASH command line.

Starting with libreadline version 8.1, the default is to give special treatment to "bracketed paste" operations. This breaks parsing for my program, so I want to disable it. I know that it can be globally disabled by adding this line to /etc/inputrc set enable-bracketed-paste off I know that it can by disabled per-user by adding the same line to ~/.inputrc I know that the command can be made program specific by modifying it to $if Progname set enable-bracketed-paste off $endif However those options require action by the sys admin or user. I want to have the program itself disable this mode on entry. The readline docs say rl_startup_hook is the address of a function to call just before readline prints the first prompt. I take this to mean that the following code should do what I want. int my_readline_init(void) { char *command = strdup("set enable-bracketed-paste off"); rl_parse_and_bind(command); free(command); } rl_startup_hook = my_readline_init; If I add a debug line or trace point to my init routine I can see that indeed it is being called. But (1) it is called on every input line, not just the first time, and (2) it does not have the desired effect. I.e. it does not turn off the bracketed paste handling. What am I doing wrong?