bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The backspace key can only move forward and cannot delete characters


From: G. Branden Robinson
Subject: Re: The backspace key can only move forward and cannot delete characters
Date: Wed, 20 Mar 2024 10:54:50 -0500

At 2024-03-20T09:12:20-0400, Chet Ramey wrote:
> On 3/19/24 9:38 PM, 高剑平 wrote:
> > May I ask how to bound to `delete-char' instead of
> > `backward-delete-char'.
> 
> This is backward; it sounds like you want to bind it to
> backward-delete-char.
> 
> 1. Find out what key sequence your backspace key emits. This is
>    terminal- specific, but you might be able to find it in your
>    terminal app's settings. Let's say it's \033[3~

(I'll speak of Bash rather than readline in this message; that is
because the readline library is bundled with Bash and Chet maintains
them together.  Formally, Bash is merely a readline application.)

I would add that there are a couple of approaches you can take to this.

One is to ask the shell to quote the next keystroke.  So type Control+V
and then the backspace key.

At the bash prompt on my terminal, I get this:

## bash-5.1$ ^?

Another is to ask the terminfo library what your terminal's backspace
key produces.[1]  The infocmp(1) command, without arguments, dumps the
terminfo database description of the terminal type you're using (from
the environment variable TERM, visible as the shell variable $TERM).

Terminals have a lot of capabilities, many of them for what terminfo
calls "function" keys, so it is convenient to grep(1) for just the
one(s) of interest.  The terminfo capability code for the backspace key
is "kbs"--you can find a list in the terminfo(5) man page--and so I can
obtain its definition like this.

## bash-5.1$ infocmp | grep kbs
        ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs,

For Bash to accurately bind the "backward-delete-char" action to the
byte sequence produced by your terminal's backspace key, the terminfo
entry for your terminal type $TERM must be correct.  Consult your
terminal's configuration (if any) and documentation (if any) to
determine what this might be.  If the terminfo database is incorrect and
needs correction, please report your findings in detail to
bug-ncurses@gnu.org mailing list.

> 2. Bind that sequence to the desired command in ~/.inputrc
> 
> "\033[3~":backward-delete-char

Regards,
Branden

[1] As I understand it, Bash has for a long time shipped its own
    "vendored" version of the GNU termcap library (which has been
    unmaintained for about 30 years), but it supports using the termcap
    API of the system's curses library if it offers one (ncurses does).

    (This probably can't be taken for granted; the X/Open Curses
    standard withdrew the termcap API in Issue 7--2009--but I reckon
    System V Unix vendors lazily kept right on doing whatever they'd
    been doing for years, offering the termcap API or not.  Chet likely
    has more insight into what deployments look like thanks to Bash
    configuration/bug reports from relevant OSes.)

    Looking now, I see that Bash's configure script uses an Autoconf
    macro named "BASH_CHECK_LIB_TERMCAP", which searches aggressively
    for the termcap function tgetent(3) in 5 different libraries.  So
    possibly many people who build Bash never get a clear idea of which
    termcap implementation they're using.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]