[HN Gopher] Things you didn't know about GNU readline (2019)
___________________________________________________________________
Things you didn't know about GNU readline (2019)
Author : meribold
Score : 127 points
Date : 2024-06-26 16:00 UTC (7 hours ago)
(HTM) web link (twobithistory.org)
(TXT) w3m dump (twobithistory.org)
| sodapopcan wrote:
| This is cool, I didn't actually know you could configure Readline
| so the title is apt for me :D
|
| Much like in the article I'm also a Vim user who excited to try
| Vim mode at the command line and I almost instantly hated it. I
| suppose it's almost required to mention tpope's rsi.vim[0] which
| gives you Readline bindings in insert and command modes. I've
| adopted Readline _everywhere_ in my OS except in Vim normal mode
| which I believe is not too uncommon for many folks.
|
| [0] https://github.com/tpope/vim-rsi
| tux1968 wrote:
| Tpope's naming of those bindings is meant as a bit of a joke,
| maybe? I've always felt that Emacs bindings was leading to
| Repetitive Strain Injury; and really appreciate being able to
| use Vim bindings, even at the shell prompt.
| ramses0 wrote:
| tpope has $DIETY-tier naming skills: `fuGITive`,
| `scriptEASE`, `PATHoGEN`
| sodapopcan wrote:
| Wow, I never put _script_ _ease_ together, I figured he was
| purely being lude, lol. I feel a bit dumb but thanks for
| pointing it out!
| sodapopcan wrote:
| The name is certainly a joke but the plugin is not. There is
| certainly nothing wrong with using Vim bindings on the
| command line if you're into it! 'tis the beauty of
| configuration.
| kstrauser wrote:
| It's a relief seeing readline pulled in as a dependency for some
| command line tool: ahhh, there's going to be at least a
| reasonable amount of command history and editing features
| available.
|
| To remind yourself how much we take for granted, play with `psql
| --no-readline` some time and see how awful it is to lose the
| ability to up-arrow get the last query back, edit it, and send it
| again.
| joezydeco wrote:
| I get a sense of dread when I see readline pulled in as a
| dependency because now I'm GPL3.
| enriquto wrote:
| I don't understand. Are you afraid of being able to see the
| source code of the program you are going to use? You are not
| forced to look at it, if you don't want to.
| cyberax wrote:
| Yeah, you don't.
|
| GPLv3 means that you can't use it with the code you write
| for your job. And there are cases where readline can sneak
| into the codebase through unintended routes.
| tpoacher wrote:
| > It's a relief seeing readline pulled in as a dependency
| for some _command line tool_
|
| (emphasis mine)
| kstrauser wrote:
| GPLv3 means you can't use it with code that you
| distribute outside your organization without complying
| with its license. It's not an issue for internal tooling.
|
| I know you get the distinction, but I hear too often that
| "we can't use GPLv3 software at work" from people who
| aren't clear on it.
| cyberax wrote:
| > GPLv3 means you can't use it with code that you
| distribute outside your organization without complying
| with its license. It's not an issue for internal tooling.
|
| It is. E.g. if you have a contractor working with your
| company, then giving software can be considered
| "distribution". And the contractor can gain the right to
| re-distribute your internal software.
|
| It's OK to use GPL for software that runs in separate
| processes (e.g. GDB), but readline is really sneaky
| because it's a library.
| kstrauser wrote:
| Real talk: if a company's contractor agreements don't
| strictly circumscribe how a contractor can only use the
| company's resources on a limited basis to perform their
| work on the company's behalf, the GPLv3 is far, _far_
| down their list of concerns. Do they also get to keep the
| rest of the company 's code? Their emails? Marketing
| materials? Laptop? The OS on that laptop?
|
| I've never been tempted to think I had any right
| whatsoever to my employers' internal materials. That
| would be a highly unusual, maybe unprecedentedly so,
| situation.
| adrianN wrote:
| What the license allows and what the company rules say
| are often not the same
| enriquto wrote:
| Sounds like a company problem then; not a license
| problem.
| joezydeco wrote:
| I've worked on a number of embedded systems for clients
| that prefer not to allow for user modification of libraries
| or system code. You know, that TiVo-ization stuff. Many of
| them are more than happy to comply with GPL2, but have
| banned GPL3 code from their companies altogether.
|
| My current bane is BlueZ, which used to allow for a
| compile-time removal of readline but no more.
| kstrauser wrote:
| Ah, sure. Yeah, I could see how GPLv3 code would be
| inconvenient for a company that wants to ship it without
| complying with the license. The companies I've worked had
| a different profit model so it never affected me. In my
| case, seeing readline just means that the development
| tool I'm using will be more pleasant to work with.
| tpoacher wrote:
| That's fair enough, though OP was referring to command-
| line tools, not libraries.
|
| He was basically saying that seeing readline pulled as
| one of the dependencies gives him confidence that the
| tool won't suck. He said nothing about _building_ tools
| with readline support (implicit or otherwise).
| 1oooqooq wrote:
| good. also very nice to hear you did write a replacement
| for blueZ and released it as some copy left license.
|
| ... you did write and release a replacement in the
| license you like, right? right?
| qludes wrote:
| Do they actually use features like ARM trustzone and
| encrypt the firmware? I'm trying to get my router to do
| things it should be able to do and it seems like they
| mostly concentrated on making getting serial accesss more
| annoying but the rest is just an ancient BSP linux distro
| with minor changes using none of the actual security
| features of the SoC.
| efdee wrote:
| This is about using readline as a dependency in your own
| software. Because readline is GPL3, your software must also
| be GPL3.
| kstrauser wrote:
| It's super easy not to download it and import it into
| your own code.
| dwheeler wrote:
| No, you can bring GPLv3 code into software with other
| licenes sucg as the MIT license.
| kstrauser wrote:
| I can't think of a scenario where that would bother me, for
| personal stuff or at work. It'd be an issue if I wanted to
| ship a proprietary product using GPLv3 dependencies, but I
| don't, so it doesn't affect me at all.
| tmountain wrote:
| Yeah, that adds a fairly terrible level of inflexibility for
| sure if you're working on a proprietary product. On a non-
| commercial level, it causes friction with anything licensed
| as BSD/MIT/Apache/etc, and that puts a lot of projects out in
| the cold.
| kstrauser wrote:
| I can't imagine too many cases where readline would get
| pulled into my proprietary code as a transitive dependency.
| I mentioned psql above: it's not as though I'd have
| `#include "psql.h"` in my own project.
|
| What's this friction between readline and other licenses in
| other Free Software code? Unless I'm writing some software
| with a non-GPL license and want to include GPLed software
| in my own that I plan to distribute, it doesn't affect me.
| jeffreygoesto wrote:
| Python?
| kstrauser wrote:
| Python optionally uses libedit.
| microtherion wrote:
| Was going to mention that. libedit seems to provide a
| sufficient subset of command line editing functionality
| for most purposes.
| saghm wrote:
| In college I had the misfortune of using the CLI that Oracle
| provides for connecting to their database, which had the worst
| UX of any CLI tool I've used by far. No history, and the only
| way to run a previous command was with a shortcut that ran it
| verbatim without allowing any editing. It didn't correctly
| handle commands I wanted to run that I pasted in, which meant I
| had to type stuff out every time, and there was no ability to
| delete with backspace or move the cursor backwards, which meant
| that making a typo required clearing everything and typing it
| again from scratch.
|
| On the bright side, that experience did cause me to do a little
| research and learn about readline, which I hadn't realized was
| a library I could make use of for my own stuff before then!
| chasil wrote:
| Oracle now ships a Java CLI that has all the expected modern
| features.
|
| https://www.oracle.com/database/sqldeveloper/technologies/sq.
| ..
|
| The sqlplus client continues to have all the problems that
| you have outlined. When sqlplus runs on the Windows command
| line, it does inherit command history.
| WalterGR wrote:
| Old-school MS-DOS was pretty bad. IIRC the only command
| history feature was pressing the right-arrow key, which would
| restore the previous command character-by-character.
| snmx999 wrote:
| There was DOSKEY starting with MS-DOS 5. It could be opened
| with F7 and the commands could be browsed through with
| arrow up and down keys.
| pasc1878 wrote:
| Or better 4dos
| kragen wrote:
| yeah, 4dos was great. it still exists, by the way, and
| they've released the sources, just not under an open-
| source license: https://4dos.info/sources.htm#1
| kragen wrote:
| f3 recalls the whole command, and then you could edit it
| with the arrow keys and insert and delete. i think f2 x
| recalls the whole command up to the first occurrence of the
| letter x. these features existed by ms-dos 3, but i think
| they were in ms-dos 2 as well
|
| in retrospect it's kind of stupid that ms-dos didn't have
| fantastic command-line editing and history facilities,
| since it had guaranteed control over the whole screen, a
| known keyboard layout, guaranteed at least 64k of ram, and
| was running milliseconds away from your fingertips without
| having to timeshare compute resources with other people or
| background compilation tasks (etc.). from today's
| perspective, having a rich command-line history feature
| with search, cut, paste, and movement by words for command-
| line editing seems like a no-brainer in this context. maybe
| it's a harder sell when you have to write it all in 8088
| assembly, or (more likely) when you've never used a system
| like that before
|
| it makes me wonder what kind of obvious improvements on
| today's computer systems we're missing
| lmz wrote:
| Pretty sure sqlplus lets you edit the buffer with "edit".
| Readline still better though.
| makr17 wrote:
| I haven't worked with sqlplus in forever, and I'm much
| happier for it. But back in the day we would wrap sqlplus
| with socat to add readline behaviors.
| dredmorbius wrote:
| Last time I touched Oracle is going on a couple of decades
| ago. But I did discover at the time a readline wrapper which
| provided at least a modicum of functionality. Looks as if
| that's Still A Thing:
|
| <https://oracle-base.com/articles/linux/rlwrap>
| akira2501 wrote:
| > It's a relief seeing readline pulled in as a dependency for
| some command line tool
|
| When it isn't just use 'rlwrap.'
|
| > some time and see how awful it is to lose the ability to up-
| arrow get the last query back, edit it, and send it again.
|
| [A
| singleshot_ wrote:
| Wait a minute -- when I hit arrow keys in vi and get letters
| instead, is that because vi is in no-read line mode? I
| figured this was a termcap thing (for the past twenty nine
| years while I've been a vi user).
|
| Apparently, a pretty incurious one.
| npsimons wrote:
| Forget the up-arrow, C-r is a _life-saver_ for us Emacsers who
| have to go to CLI for whatever reason.
| gray_-_wolf wrote:
| > Also, without some sort of indicator, Vim's modal design is
| awkward here--it's very easy to forget which mode you're in.
|
| That is why I have this in inputrc:
|
| set editing-mode vi
|
| set show-mode-in-prompt on
|
| set vi-ins-mode-string +
|
| set vi-cmd-mode-string :
| sre2 wrote:
| You could easily improve upon that. For example the following
| will change the cursor to a block in emacs mode, an underline
| in vi-command and a line in vi-insert in most terminals.
| set show-mode-in-prompt on set emacs-mode-string \1\e[1
| q\2 set vi-cmd-mode-string \1\e[3 q\2 set vi-
| ins-mode-string \1\e[5 q\2
|
| The worst thing about the bash config of readline is that bash
| disables the key combinations for going from emacs-mode to vi-
| mode (ctrl-alt-j) and back (ctrl-e). They work everywhere else
| (where I've checked anyways) and you can't turn it on again in
| inputrc, you have to bind it in your .bashrc, all that because
| the bash developers think it would be too confusing to have it
| work the same in bash as anywhere else were you have readline
| support.
| tristan957 wrote:
| What's the bind incantation in the bashrc you recommend? Here
| is what I tried: bind -m vi-command
| 'Control-e: emacs-editing-mode' bind -m emacs 'M-C-j:
| vi-editing-mode'
|
| The second keybind does not seem to work. If I just make it
| control-j, it works. For some reason the meta is throwing it
| off.
| meribold wrote:
| To make Less (the pager program) behave a bit more as if it used
| Readline (it doesn't), one can create a `~/.config/lesskey` file
| with these contents: #line-edit ^A home
| ^E end ^F right ^B left ^P up ^N down
| ^D delete ^W word-backspace \ed word-delete \ef
| word-right
|
| I think a relatively recent version of Less is required.
| meribold wrote:
| Some more good ideas for Readline configuration:
| https://www.topbug.net/blog/2017/07/31/inputrc-for-humans/
| strbean wrote:
| This is nostalgic. For a Systems Programming course, I had the
| following assignment:
|
| - Implement readline(3)
|
| - If you have any questions, see the man page.
|
| - Extra credit: implement all GNU extensions.
| 20after4 wrote:
| What a great assignment. I would have loved that class.
| tpoacher wrote:
| Along the same lines, I find this little utility in standard
| linux repos to be amazing. Try it on ed: `rlwrap ed`.
| Package: rlwrap [...] Homepage:
| https://github.com/hanslub42/rlwrap Description-en:
| readline feature command line wrapper This package
| provides a small utility that uses the GNU readline
| library to allow the editing of keyboard input for any
| other command. Input history is remembered across
| invocations, separately for each command; history
| completion and search work as in bash and completion
| word lists can be specified on the command line.
| danieldk wrote:
| rlwrap is a life-saver. Back when I was a graduate student, I
| contributed a system that was written in SICStus Prolog 3.
| SICStus was (probably still is) a great Prolog interpreter, but
| its REPL interface was quite bare-bones. `rlwrap`-ing SICStus
| made it so much nicer!
| tristan957 wrote:
| I'm still not understanding rlwrap. Could you describe more
| about what I should notice running the ed command you posted.
| assbuttbuttass wrote:
| rlwrap provides line-editing capabilities including ctrl-a,
| ctrl-e, and up and down arrows to recall previous commands
| galenelias wrote:
| Shout-out to the clink project, which brings a modern shell
| experience (including Readline) to Windows' cmd.exe. This is the
| most advanced shell I have across Mac/Linux/Windows, which is
| always a bit surprising. It's extremely extensible and has some
| pretty incredible functionality written for it (also by the
| maintainer).
|
| https://github.com/chrisant996/clink
| chasil wrote:
| I just use the busybox port to Windows.
|
| https://frippery.org/busybox/index.html
| bbminner wrote:
| Bash uses readline, right? So
|
| > Tens of thousands of people probably use it every day without
| thinking about it.
|
| seems like an understatement.
| olau wrote:
| Some years ago I helped diagnose an O(n2) bug in readline.
|
| For years, I had problems pasting many lines of SQL in a psql
| session. It would slow down as it worked through the characters.
| One day the same happened in another shell, and it dawned on my
| that this was probably a problem with readline.
|
| So I fired up a profiler and sure enough, something inside
| readline was recalculating something upon each character input
| with the work done proportional to all the characters already
| input.
|
| I sent my findings to the mailing list, and Chet Ramey fixed it.
|
| In the process, I discovered that wonky editing of long lines
| when resizing a terminal window was also fixable. When you
| resize, you change the line width, so readline needs to take that
| into account when it wraps the long lines. I think it did have
| code to do that at the time, but it just didn't kick in for some
| reason. Can't remember the details, but it does seem to work fine
| in psql today. That was another multi-year annoyance.
| ramses0 wrote:
| Remiss for not mentioning "rlwrap":
| https://github.com/hanslub42/rlwrap
|
| ...basically "readline in a can" that you can use to improve text
| input of other programs.
|
| I forget if it was RMS or ESR that really wanted to hold
| "readline" away from corporations, so it's licensed as GPLv3 (not
| v2), and he explicitly wanted it to _not_ be LGPL (ie:
| embeddable).
|
| My crazy readline/bash tip is `ESC, .` (or maybe `alt+.`, I'm not
| 100% sure, random search result here:
| https://gist.github.com/tuxfight3r/60051ac67c5f0445efee ).
| Basically it up-arrows through the last "word" of previous
| commands, adding it to the current command.
|
| Example: mkdir foo cd `esc, .` => cd
| foo vim bar.txt cp `esc, .` baz.txt => cp
| bar.txt baz.txt
|
| It's crucial in that it reduces the number of keystrokes, and
| avoids typing errors completely, as you're "recalling" something
| rather than re-typing.
|
| I'm also in the same boat as the author in that `set -o vi`
| doesn't quite do it for me (although I consider myself an expert
| in vi). What I tend to do instead is: C-a #
| <cr> => go to the beginning of the line and insert a comment
| char fc => "fix command", see "help fc" (it's
| a built-in)
|
| ...basically it invokes: `$EDITOR "$( history | tail -1 )"` and
| whatever you save/quit will get executed as a command.
|
| This lets me intentionally "damage" a command, but then get into
| `vim` to "fix it up" (eg: `dw, cw, df/, etc...`). Remove the
| comment from the beginning of the line to execute it, or keep it
| there to take the command back "out" of `vim` so you can keep
| building it up.
| wild_egg wrote:
| I've always used !$ to get the last word of the previous
| command like so: mkdir -p foo/bar cd
| !$ # => cd foo/bar
|
| I suppose the advantage of `ESC, .` is universality since it'd
| work inside any readline prompt? Not sure how frequently I
| actually need to do that outside of bash but going to keep it
| back of mind in case I do, thanks
| ramses0 wrote:
| I like the interactive nature of esc-., you can keep "up
| arrowing", to a value a few commands ago and crucially: edit
| the value. (add/remove `tgz`, etc)
| fragmede wrote:
| `alt .` :)
| chasil wrote:
| Debian dash is a minimal POSIX shell that also is able to
| implement "set -o vi" (as suggested by POSIX.2).
|
| http://gondor.apana.org.au/~herbert/dash/
|
| The dash shell doesn't use GNU Readline to implement "set -o vi"
| but instead uses "libedit":
|
| https://thrysoee.dk/editline/
|
| Debian does not appear to link dash with libedit, so command line
| editing is disabled.
|
| They should consider doing so, and offering dash as an
| interactive shell. This would give people fewer bashisms to
| unlearn when they need to write portable scripts for the POSIX
| shell.
|
| The dash shell is actually reasonably pleasant for interactive
| use when compiled with libedit.
| andrewshadura wrote:
| "They" have considered it and tried it, but had to revert the
| change. Dash is in Debian primarily for scripts, not for
| interactive usage. If you want to use dash with libedit, you
| have to compile it yourself, unfortunately.
| jlv2 wrote:
| "Tens of thousands of people probably use it every day without
| thinking about it."
|
| Probably tens of millions at this point.
| apitman wrote:
| This is way off topic but 2 hours ago I was trying to figure out
| how to read a single line from stdio using Rust/tokio and failed
| to figure it out in a reasonable time. It was infuriating.
| kstrauser wrote:
| I could stand to hear more about this. What problem were you
| running into?
| ComputerGuru wrote:
| let mut line = String::new();
| std::io::stdin().read_line(&mut line).unwrap();
|
| And I just looked it up and it's right there in the docs, too:
| https://doc.rust-lang.org/std/io/struct.Stdin.html
|
| You basically shouldn't use `tokio::io::stdin()` for what you
| want, as is documented at
| https://docs.rs/tokio/latest/tokio/io/fn.stdin.html
|
| > For interactive uses, it is recommended to spawn a thread
| dedicated to user input and use blocking IO directly in that
| thread.
|
| So the code under tokio would be let line =
| rt.spawn_blocking(|| { use std::io::stdin;
| let mut buffer = String::new();
| stdin().read_line(&mut buffer).unwrap()
| }).await.unwrap();
| gumby wrote:
| ^U in readline isn't an emacs command (that keystroke does
| something else in emacs); it's the old teletype protocol for line
| input.
|
| So if you aren't using readline, ^U deletes everything back to
| the beginning of the line. Readline preserves that because us
| pre-readline old farts have it wired into our fingers.
|
| Before display terminals there were just printing terminals: IIRC
| # deleted a character and @ everything to the beginning of the
| line. This goes back to Multics and was carried forward in early
| releases of Unix at Bell Labs.
|
| This is obviously pretty inconvenient when you have a display
| terminal but I am pretty sure that code remains in the bowels of
| the BSD TTY IO system at least and can probably be enabled. Maybe
| it even survived into linux for some compatibility reasons.
|
| Also I WUZ THERE and I think Chet has it backwards on the POSIX
| controls issue: bfox talked about the TWENEX line input JSYS that
| had that stuff built in (I believe it was also, perhaps even
| earlier, in VMS, and maybe TENEX, and surely he had talked to
| some of those folks too)
| mklein994 wrote:
| > Also, without some sort of indicator, Vim's modal design is
| awkward here--it's very easy to forget which mode you're in.
|
| With `bash`, you can show which mode you're in by putting this in
| your `~/.inputrc`: show-mode-in-prompt on
|
| It makes your prompt look like this: [foo@bar
| ~]$ # before turning it on @[foo@bar ~]$ # after
| @[foo@bar ~]$ set -o vi (ins)[foo@bar ~]$ # and after I
| press esc: (cmd)[foo@bar ~]$
|
| Customize these with `emacs-mode-string`, `vi-ins-mode-string`,
| and `vi-cmd-mode-string`.
| uncletaco wrote:
| One thing trying to work with Guix over the last five years
| taught me is how much I take for granted all the little things
| that come packaged extra. I was using guix for about a month
| before I learned that readline was the package that allowed me to
| do a lot of the extra commands like ctrl-c etc.
| usr1106 wrote:
| The article feels incomplete for not not mentioning the bash
| built-in called bind. It allows you to work with the reeadline
| bindings.
|
| I use Ctrl-R a lot to find previous commands from my shell
| history. Often I have to press Ctrl-R several or even many times
| to find the right one. And then it happens that I overshoot and
| would like to change the search direction. Unfortunately forward-
| search-history is on Ctrl-S, which is overloaded by flow control.
| Occasionally I use flow control, so I cannot remove that. What
| solution are others using to get forward-search-history?
| lohfu wrote:
| fzf has pretty killer history fuzzy search. Just load its
| keybindings in your .bashrc
| wswope wrote:
| If you're open to a paradigm shift, I can't recommend atuin
| highly enough. It's truly the pinnacle of shell history
| tooling, but requires a ~1-2 day muscle-memory learning curve.
|
| https://atuin.sh/
| klibertp wrote:
| One important characteristic of this `readline(const char*)` call
| is that it blocks. So, if you're trying to write a REPL for a
| language that uses green threads for concurrency - I'm looking at
| you, GNU Smalltalk - then DON'T. At least not from the main
| thread.
| BeetleB wrote:
| Readline is good, but once I started using the xonsh shell, and
| prompt_toolkit, going back to Readline always feels a bit
| lacking.
| godelski wrote:
| > Ramey has now worked on Bash and Readline for well over a
| decade. He has never once been compensated for his work
|
| I just want to remind everyone of the xz hack. The lesson here is
| that a few people maintain projects that are critical to our
| infrastructure. You may be familiar with the XKCD comic[0], but
| this makes it look like the unpaid single/few maintainer critical
| projects are rare.
|
| These people are generally unpaid and that has big ramifications.
| Sure, it makes them susceptible to bribes and more prone to
| hostile takeovers (however you view xz), but there's more. It
| means these works are simply a work of passion, and they are
| working on them in their spare time. We all know here that that
| time is less and has lower priority than our work time. So you're
| more likely to be rushed and make mistakes, or not be able to fix
| things fast enough, and so on. Is this really the way we want
| this infrastructure to be maintained? Startups have more
| stability than this and are more likely to pass the "CEO hit by a
| bus" rule[1]. Not to mention the difficulties of transitioning
| when the dev wants to retire or move onto something else. This
| does lead to issues, and while we've solved them in the past,
| that doesn't mean we can't do better.
|
| Surely they deserve some compensation. We have 8 companies which
| are worth over a trillion dollars and certainly all 8 use
| readline. Are you telling me that these companies can't
| collectively kick back $200k/yr. That's literally what Elon makes
| in 10 minutes if he gets 5% on his wealth. I find it hard to
| believe we don't have enough money to fund possibly thousands of
| these projects (if there are that many, but there are likely that
| many people). It only takes Ballmer 16 minutes and there are 20
| people who can do it in 30 minutes or less (~50 for 1hr).
| Collectively the top 10 make 230 million per day for doing
| nothing. I think we have the money. (remember, we're talking
| about products that these companies are using. This isn't just a
| "pure donation," as these things have clear market value and the
| loss of the maintenance will result in these companies also
| losing money)
|
| At the least, I'd like to remind everyone that the company you
| work for likely offers some matching donation. If you're at one
| of the big tech, they do.
|
| [0] https://xkcd.com/2347/
|
| [1] If your CEO, or any single specific employee, is hit by a bus
| and can no longer work, does the entire company also collapse?
| jeffrallen wrote:
| Ctrl-k kills the rest of the line. Ctrl-u kills the entire line.
|
| Ctrl-y yanks stuff back in from your kill ring. Esc-y will then
| replace the stuff with the previous item in the kill ring.
|
| Ctrl-arrows moves a word at a time.
|
| Ctrl-r starts a reverse interactive search through the history.
| Use any editing key, like ctrl-e to start working on the current
| search result.
| akira2501 wrote:
| Ctrl-c aborts input and leaves the previous partially edited
| line visible.
|
| Ctrl-g cancels Ctrl-r searches. So if you want to search and
| then search again you can clear the history position with
| Ctrl-g.
|
| Ctrl-s moves forward if you went too far with Ctrl-r.
|
| Ctrl-r twice in a row retrieves the previous search.
|
| Alt-u upper cases. Alt-l lower cases. Alt-c capitalizes. From
| current position to end of word.
| geophile wrote:
| I was writing a command-line tool in Python, and wanted bash-like
| line editing capabilities. And then I realized that there was a
| Python wrapper for readline. Problem solved!
| hollerith wrote:
| That's nice, but if GNU readline disappeared from my Linux
| install I probably wouldn't notice.
___________________________________________________________________
(page generated 2024-06-26 23:01 UTC)