The shell's "delete word" shortcut deletes too many characters

Question

Under Bash some behavior of Alt+d has been driving me crazy since years and I figured out that maybe it could be fixed with a setting.

If I'm at a terminal and issue a command like this:

...$   cat >> ~/notesSuperLongFilename.txt

and then if I want, say, to issue :

...$ scp ~/notesSuperLongFilename.txt

I'd like to get back the "cat >> ~/notesSuperLongFilename.txt" using Ctrl+p (previous line) and then do Ctrl+a and then Alt+d and Alt+d again so I'd have:

...$  ~/notesSuperLongFilename.txt

and then I'd be able to simply enter "scp" and then do a Ctrl+m (or hit Enter / Return).

However it doesn't work because after the first Alt+d I get:

...$ >> ~/notesSuperLongFilename.txt

(so far so good)

but after the second Alt+d I get:

...$ .txt

So for some reason Alt+d deletes ">> ~/notesSuperLongFilename" at once instead of just deleting ">> ".

This has to be the single biggest time-waster that is driving me crazy with Linux / Bash since literally years.

So how can I fix this (arguably broken) behavior of Alt+d?

P.S: I don't know who's "responsible" for that Alt+d behavior: I don't know if it's the terminal or if it's the shell (Bash in my case).

Answer 1

I don't know who's "responsible" for that Alt+d behavior: I don't know if it's the terminal or if it's the shell (Bash in my case).

It's bash, specifically the default command-line editing setup. Here is a nice page on what commands can be bound, and how to change the default bindings.

The default binding for Alt-d is kill-word which is supposed to work like the command of the same name in Emacs. As you've observed, though, it doesn't—Emacs would consider the space between >> and the tilde in your example to be a word break. That bash does not, I would consider a bug. Short of getting the source for bash, changing it, and recompiling it, I don't know what you can do.