Live data from Hacker News

Keyboard shortcuts for GNU Readline

masteringemacs.org

151–160 of 174 posts

Re: Keyboard shortcuts for GNU Readline

#151
post #41
post #20

After getting very used to C-w (delete back work) and C-h (delete character backward) on readline, it really bugged me that these aren't default on emacs, even though readline is often advertised as giving emacs muscle memory. I ended up globally remapping C-w and moving the help prefix, C-h to C-x h and making C-h backspace, because i was pressing it incorrectly that often.

So, to be fair , C-h isn't some crazy invention of readline (and thereby a failure of what it was "advertising") that you got used to: it is the standard key code for backspace. Just like a horizontal tab is ASCII 9 and a carriage return is ASCII 13, ASCII 8--and I realize this might make less sense as this in some sense "undoes" a thing and maybe you would never expect it to be in a file--is backspace. Meanwhile, al…

> C-h isn't some crazy invention of readline (...) that you got used to: it is the standard key code for backspace.

> C-H is equivalent to pressing Backspace!! Now, there is also a DEL, for the Delete key, which is which is 127

Not anymore on Linux terminals. People wanted to distinguish backspace and C-h, so in some time in 1990s there was great DEL-BS shift, where convention changed to use 127 for BS and some escape sequence for DEL (in direction from terminal to program, in the opposite direction the original convention is still used). That is why there are these sections in Emacs manual (and similar options on other tools) - to handle situations where terminal behavior and information about terminal are mismatched.

Re: Keyboard shortcuts for GNU Readline

#152
post #15

"Shame, then, that even serious command line hackers never bother learning about its capabilities, as they can supercharge your command line productivity." Because it is really confusing if you are not an emacs user.

Add `set editing-mode vi` to your ~/.inputrc and readline's keybindings resemble vi instead of emacs. You can also define your own keybidings as you like, like `Meta-Control-h: backward-kill-word` as seen in the example file in `info readline -n 'Sample Init File'`. Works with bash and whatever else that's using readline, like the python console, postgresql client, etc.

Re: Keyboard shortcuts for GNU Readline

#153
post #93
post #3

Just enable vim mode (`set -o vi`) and call it a day.

This is actually encouraged by POSIX. set -o vi: "Allow shell command line editing using the built-in vi editor. Enabling vi mode shall disable any other command line editing mode provided as an implementation extension." No other mode, specifically emacs mode, is included in the POSIX standard. Take from this what you will. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Not surprising.

Back in the heyday of POSIX standardization, the Emacs camp and the POSIX camp were both very opinionated and not entirely aligned. One example is the standard disk block size used in command line utilities such as du and df. RMS made GNU use 1kb instead of the POSIX standard 512 byte size, but this could be overriden by setting the environment variable POSIX_ME_HARDER.

Re: Keyboard shortcuts for GNU Readline

#154
post #146

Earlier quoted context omitted.

I'm a vim guy, and I don't find the readline commands confusing. I just think of it as "Insert" mode in Vim (many of the readline commands work there too!!) and it feels pretty natural.

Have you tried vi mode in bash? "set -o vi" I think. Then you can use vi(m) commands, modal editing, even press v to drop into a full vim instance for doing more advanced editing of a command line. It's amazing.

TIL `set -o vi` is a shortcut for setting `set editing-mode vi` in .inputrc for bash only - except it seems like the .inputrc version would apply to anything that uses readline (gdb, etc)

https://unix.stackexchange.com/questions/485818/bashs-set-o-...

Re: Keyboard shortcuts for GNU Readline

#155

Two issues with readline: it's GPL and it's big. For embedded systems intended to become products you really need something else. My tiny variant is this, but for sure there are many others: https://github.com/nklabs/libnklabs ("nkreadline" has editing, tab-completion (for embedded "nkcli" commands) and history)

For me as a customer, the GPL is a feature, not an "issue." Of course, if you ship software for your hardware and want to lock your customers out of their own hardware, then I can see why you'd not choose it.

I don't disagree with you (I've written plenty of GPL-licensed software), but as someone who gets paid to develop products for other companies, it's an issue. Few of my customers are interested in making the embedded software for their product open source.

Actually the MIT open source license (and other similar ones) solves a completely different problem for me. It allows me to reuse this software for many different customers. It's slightly easier to do this when I tell them that I'm going to use "this open source library" vs. "my personal library that I'm granting you a license for this product, but I retain the right to use it for other customers".

Re: Keyboard shortcuts for GNU Readline

#156

Earlier quoted context omitted.

Very cool! What keys do ~ and ^ represent? { "^w" = "deleteWordBackward:"; "~f" = "moveWordForward:"; "~b" = "moveWordBackward:"; "~d" = "deleteWordForward:"; "~ " = "moveToEndOfDocument:"; "~w" = "copy:"; "^y" = "yank:"; "^t" = "transpose:"; "^p" = "moveUp:"; "^n" = "moveDown:"; "^u" = "deleteToBeginningOfLine:"; }

In this file `~` is meta (option key on macs). Not sure why it's not escape like it is in emacs.

Because on a particular three/four-decade-old physical terminal[0], Alt-$KEY was transmitted as "1B [sequence for $KEY]". Eg, Alt-X was "1B 58"[1]. The escape key happened to also transmit "1B" on its own. Consequently, "Alt-$KEY" and "Esc, $KEY" were indistinguishable unless you went out of your way to engineer a race condition. This has never really been fixed, despite intermittent attempts.

0: I think VT100, but don't quote me on that

1: or possibly "1B 78", depending on how it handled shift; I don't remember exactly.

Re: Keyboard shortcuts for GNU Readline

#157
post #150
post #121

Earlier quoted context omitted.

> but it can be useful when you're outputting a lot of text (for example tailing a logfile). Use "tail +F" and press ^C when you need to pause at some line. Press F to resume tailing.

less(1) provides similar follow/stop-following functionality.

I think I was thinking of less, haha.

Re: Keyboard shortcuts for GNU Readline

#158
post #10
post #6

I'm using bash (and thus GNU readline) all day every day at work, and by far the most useful shortcut for me is Ctrl-r (reverse history search). I also sometimes use Ctrl-a (start of line, if the keyboard doesn't have a convenient Home key) and Ctrl-e (end of line, in lieu of End key). Btw the post disses Ctrl-s / Ctrl-q for pausing/resuming terminal output, but it can be useful when you're outputting a lot of text (…

>by far the most useful shortcut for me is Ctrl-r I rarely ever use Ctrl-r since I usually know the starting part of the command I want. So, I type those starting characters and use up/down arrow keys, courtesy these lines in `~/.inputrc` "\e[A": history-search-backward "\e[B": history-search-forward

Many of my commands start identically but continue and end differently. Here C-r (or ^R if you prefer) is the most convenient.

Sending a looong command to your editor for modification via C-x C-e is also convenient sometimes.

Re: Keyboard shortcuts for GNU Readline

#159
IDK if it's obvious, but GNU readline has a full-blown vi mode, with ESC, insert / command modes, all the ergonomic motions, etc.

The default is Emacs mode, and the author of the post is a Emacs user, but that mode is not the only one supported.

Re: Keyboard shortcuts for GNU Readline

#160
post #158
post #10

Earlier quoted context omitted.

>by far the most useful shortcut for me is Ctrl-r I rarely ever use Ctrl-r since I usually know the starting part of the command I want. So, I type those starting characters and use up/down arrow keys, courtesy these lines in `~/.inputrc` "\e[A": history-search-backward "\e[B": history-search-forward

Many of my commands start identically but continue and end differently. Here C-r (or ^R if you prefer) is the most convenient. Sending a looong command to your editor for modification via C-x C-e is also convenient sometimes.

>Many of my commands start identically but continue and end differently. Here C-r (or ^R if you prefer) is the most convenient.

Not sure if I understood this correctly. You can use up/down arrow multiple times, just like Ctrl-r/s - so it is a huge improvement for me.

Post reply on HN