I'm trying to use "read -e" to implement a user prompt with custom commands. For this I must disable the default command+filename completion. I tried this: complete -W 'cmd1 cmd2 cmd3' -D and indeed pressing tab once on an empty prompt started with "c", but pressing it twice did not present cmd1 cmd2 cmd3, instead the usual bash aliases/OS programs in the PATH starting with "c". Any tips on how to do what I want? It seems there's "set disable-completion on" , but no "set disable-os-command-completion" or something similar. Thanks.

I was looking at this answer , and it lists a "keysym": \e[11~ to define pressing F1. What are keysyms and where can I get a list of them as \e[11~ doesn't seem to correlate with anything I'm aware of in the Terminal; and I'm using SSH to test this out, so X11 or Windows Managers don't really come into play here.

I recently added the following lines to my .inputrc:

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

However, I noticed when using this that my cursor does not jump to the end of the line. For example, if I type ls then hit up, my terminal will look like this (| being the cursors):

ls |verylongdir

What I want is:

ls verylongdir|

I believe zsh behaves this way with the same command. Is there any way to do this in bash?

For example:

"\e[1;5C"
"\e[Z"
"\e-1\C-i"

I only know bits and pieces, like \e stands for escape and C- for Ctrl, but what are these numbers (1) and letters (Z)? What are the ;, [ and - signs for? Is there only trial and error, or is there a complete list of bash key codes and an explanation of their syntax?

stty -a shows cchars: stop = ^S, reprint = ^R. Ctrl-r is shadowed by readline's reverse-search-history, so when I press it I get the readline function Ctrl-s is not shadowed by readline's forward-search-history, so when I press it I stop the running process (eg. sleep 5 ) So why are some cchars shadowed by readline, and some not. How can I make sure all cchars are respected, and still have readline features available (i.e. using bash --noediting is not an option, though it does allow reprint to work).

I use Ctrl+R all the time, but I often end up going past the command I'm after as I'm pressing it so quickly. To forward search, Ctrl+S can be used provided it's not used the terminal first (konsole in my case, in which stty -ixon in ~/.bashrc fixes it). However, I have to press it twice: once it seems to enter i-search after being in reverse-i-search mode and a second time to actually step backwards. Is there a way to remove the need for pressing the shortcut twice?

I sourced the /usr/share/doc/fzf/examples/key-bindings.bash file so fzf works in Bash; but how do you get that to work with the rlwrap ed approach?

In bash, when binding TAB with menu-complete, I can cycle through the current files in the lexicographical or alphabetic order. - What if the file that I want is the last file in the order? How can I get it quicker? It doesn't work by TAB while pressing SHIFT. - What if the file that I want can be got more quickly by some other order, for example, some of those available to ls: modification time, file size, etc.

Why bother? Clearing scrollback buffer is handy in many ways, for example, when I wish to run some command with long output, and want to quickly scroll to start of this output. When scrollback buffer is cleared, I can just scroll to top, and will be done. Some considerations: There is clear command, according to man, > **clear** clears your screen if this is possible, including its scrollback buffer (if the extended "E3" capability is defined). In gnome-terminal clear does *not* clear scrollback buffer. (What is "E3" capability, though?) There is also reset, which clears, but it does a little bit more than that, and it is really slow (on my system it takes more than a second, which is significant delay for humans to be noticed). And there is echo -ne '\ec' or echo -ne '\033c', which does the job. And indeed it is much faster than reset. The question is, what is \ec sequence, how it differs from what clear and reset does, and why there is no separate command for it? There is also readline's C-l key sequence, which by default bound to clear-screen command (I mean, readline command, not shell command). What is this command? Which escape sequence it emits? How does it actually work? Does it run shell command? Or what? Again, in gnome-terminal, it seems like it works just by spiting out blank lines until prompt appear in top line of terminal. Not sure about other terminal emulators. This is very cumbersome behavior. It pollutes scrollback with chunks of emptiness, so you must scroll up more, and more. It is like a hack, rather than clean solution. Another question is, is there a readline command for mentioned \ec sequence? I want to bound it to C-l instead because I _always_ want to clear scrollback buffer when I clear the screen. And another question is how to _just type_ such escape sequence into terminal, to perform desired action? Then do not have to think about binding C-l to another readline command (if such command exists). I tried typing Esc, then c but this does not work. **UPDATE** This question answered mostly here: https://unix.stackexchange.com/a/375784/257159 . It is very good answer which explains almost all questions asked here.

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?

On my macOS and Linux systems, I run ed with alias ed='rlwrap ed'. On macOS with rlwrap 0.46.1 (2022) I can freely create files with tabs like:

$ ed
a
foobar

but on my Linux systems with rlwrap 0.43 (2016) I can't use tabs unless I escape like this:

$ ed
a
foobar

I know I should get around to upgrading my Linux servers; but rlwrap is currently at the latest according to apt. Is there some rlwrap option that will give me back my tabs? I tried searching through the rlwrap manpage for "tab"; but didn't find anything.

I'm trying to create readline macros and bindings, but struggling to find codes for some key sequences. How to find codes for key combinations, like "\e[1;2A" for Shift-Up, etc? By the way, I have enabled convert-meta option.

I am using Arch, bash and gnome terminal. All are up to date with the very latest software versions. I wish to bind ctrl+c to yank the current line on the command line to the global clipboard, which may not yet be in the history file. So far I have had no success. Parsing the history file is problematic becasue the line on the command line may be yanked before the command has been run, in which case it won't be in the history file, so parsing this is not a viable option. .bashrc has vi bindings enabled as follows # set editing-mode vi set -o vi I am being careful to re-source each time as necessary with source ~/.bashrc. I have tried adding the below various options to .inputrc, re-initialising each time with bind -f ~/.inputrc, none have worked. **.inputrc tests:** $if mode=vi "\C-y": " \C-e\C-u\C-k\C-y\C-l\C-y\C-e\C-y\n" $endif and this $if mode=vi "\C-c": "\e0\C-k\C-u\C-y\n" $endif and these "\"+y": yank-to-clipboard "\Cc": copy-line # ctrl+c "\^C": copy-line # ctrl+c "\006": copy-line # ctrl+c **.bashrc tests:** I have also tried adding the following to .bashrc bind -m vi-command '"\C-y": "fc -ln -0 | tr -d \"\\n\" | xclip -selection clipboard\n"' then copy_current_command() { local cmd cmd=$(fc -ln -0) echo -n "$cmd" | xclip -selection clipboard } bind -m vi-command '"\C-c": "copy_current_command\n"' The below does not work either This is .inputrc "\e[1;6C": yank-to-clipboard # ctrl+shift+c "\^C": yank-to-clipboard # ctrl+c and this in .bashrc yank-to-clipboard() { local line=$(readline) # get the current line echo "$line" | xclip -in -selection clipboard }

I am having trouble with gdb. When I start pushing the Up Arrow key, it iterates backwards through the history. However, if I start typing a command, like b, instead of iterating only through history entries beginning with b, gdb still iterates backwards through all the history. The regular terminal (zsh) is fine. How do I make gdb iterate only through the history with the relevant commands?

Suppose I have filenames as follows on my Linux system:

$ ls -1
file-index-00012.txt
file-index-00345.txt
question.txt

I start typing, where "|" represents the cursor:

$ cat fil|

If I press tab once, Bash partially completes filenames:

$ cat file-index-00|

If I press tab twice more, it shows candidate filenames:

$ cat file-index-00
file-index-00012.txt  file-index-00345.txt
$ cat file-index-00|

The problem with this is that I have to check how many digits have been partially completed, before entering the remaining ones. For example, the first time I get a "file-index-01000.txt" in this directory, I have to enter an additional digit:

$ cat file-index-0
file-index-00012.txt  file-index-00345.txt  file-index-01000.txt  
$ cat file-index-0|

Is it possible to make Bash stop completing at the start of the word (separated by hyphen, underscore or whitespace) like this:

$ cat file-index-
file-index-00012.txt  file-index-00345.txt
$ cat file-index-|

The TTY terminal driver uses a line discipline to provide features like: line buffering of input, echoing of input to the terminal display, control character translation, etc. The bash shell uses the readline function for its input, and my understanding is that readline puts the terminal in raw mode, which disables the line discipline. So, does readline take over the line discipline's role in providing the features above, and is it fair to say that it's a user mode line discipline?

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

How can I make the builtin read command support history, by pressing the up/down key to cycle through them? I've tried catching when you press the up key, however it doesn't seem to work with read: read -p '> ' -n 3 foo echo echo -n "$foo" | hexdump Pressing the arrow keys seems to work and I can detect it using this, however if I press aa↑, it will fail as it will only read the first character of the identifier of the up-arrow, while the third is needed to distinguish the different arrow keys.

I just discovered vi mode in bash that I enable with set -o vi in my .bashrc. Now I was quite excited to remap the "normal mode" equivalents to some handy functionality. First and foremost I wanted to remap the dash-key to change directory one up from the current. I tried this:

# Remap "-" key to "cd .." in vi normal mode
bind -m vi-command '"-": "cd ..\n"'

but it doesn't seem to be working. Where did I go wrong and how to accomplish that?

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?