Most/many mature apps do, so if vi is your thing, this brings your muscle memory to more places.
I’ve used vi for a long time, but I’ve never found vi mode in readline very intuitive. My muscle memory ends up that Emacs binds apply in line editing and vi binds apply inside of vi.
For bash history, I do use ctrl-R for search, but for editing history, ESC-k, k, k, … to step up through recent lines, then vi movement and editing within the line I want (f-CHAR or 3W to move to what I want to edit, then ‘cw’ etc to update) is quite natural.
Although the Readline library comes with a set of Emacs-like keybindings installed by default, it is possible to use a different set of keybindings. Any user can customize programs that use Readline by putting commands in an inputrc file, conventionally in his home directory. The name of this file is taken from the value of the environment variable INPUTRC. If that variable is unset, the default is ~/.inputrc. If that file does not exist or cannot be read, the ultimate default is /etc/inputrc.
It used to be the case that Mac Python shipped with a broken readline because it was the BSD version or some such, but I haven’t had that problem in years, so either it’s fixed or I just stopped using system Python and don’t notice anymore.
Readline is problematic. Unlike most other GNU libraries, it is GPL’d, not LGPL. Around 2007, it became GPLv3. This means that you cannot link libreadline in anything that has any component that is not GPLv3 compatible (or, at least, you can’t redistribute the result). Most code that I use moved over to libedit (originally from NetBSD) once it reached the point of being an adequate replacement for readline for precisely this reason. Libedit provides its own APIs and a readline compatibility shim and so is mostly a drop-in replacement.
I don’t know what the Python package does, whether it supports libedit upstream or if that’s an Apple-specific patch, but in general you need to be very careful of the license if you use readline.
[ Edit: ] From the link @andyc posted below, it looks as if it has a compile-time flag to use libedit, so you may find that any given Python deployment is using either readline or libedit and probably need to be careful to avoid depending on implementation-specific functionality.
Note that readline is not just intentionally GPL, but strategically licensed in order to force people to either release code which uses it or avoid it altogether. I seem to recall the FSF explicitly saying at one point that it was a victory for Free Software when Apple chose to stop shipping GNU software, and this attitude is specifically highlighted for the case of readline. For example, in this history of the GNU project, they say:
For other libraries, the strategic decision needs to be considered on a case-by-case basis. When a library does a special job that can help write certain kinds of programs, then releasing it under the GPL, limiting it to free programs only, is a way of helping other free software developers, giving them an advantage against proprietary software. Consider GNU Readline, a library that was developed to provide command-line editing for BASH. Readline is released under the ordinary GNU GPL, not the Lesser GPL. This probably does reduce the amount Readline is used, but that is no loss for us. Meanwhile, at least one useful application has been made free software specifically so it could use Readline, and that is a real gain for the community.
It would be just as reasonable to say that Apple is the problematic party, since their attitude extends beyond just readline.
It is a nice module that provides a lot of functionality behind a simple interface. If anyone wants an example of hairy details in the Python-C API, the module deals with a ton of nontrivial issues, e..g callbacks, signals, global variables, etc.
Oil uses it and I had to dive into the code (enabling horizontal-scroll-mode in the latest Oil release, which should solve some drawing problems with a zsh-like prompt.)
I learned that there is a lower level interface that lets you process things character-by-character, and that’s what CPython uses. Basically because readline and the Python interpreter “fight” over signals, which are process-global.
If you are making an interactive interpreter, make sure to check out the cmd module. https://docs.python.org/3/library/cmd.html Besides tab completions and help text, It handles readline automatically (you still need to save/load the history file if you value that feature.)
Very well, as long as you don’t
import skynet. ;)Nobody got that xkcd reference?https://xkcd.com/521/
Bah, don’t recommend dropping files in my home directory. Not even as as example!
There are far too many programs that seem to think this is acceptable.
I agree, this should use XDG_HOME instead
readline shlib reads ~/.inputrc.
All apps which use that will honour a:
Most/many mature apps do, so if vi is your thing, this brings your muscle memory to more places.
I’ve used vi for a long time, but I’ve never found vi mode in readline very intuitive. My muscle memory ends up that Emacs binds apply in line editing and vi binds apply inside of vi.
For bash history, I do use ctrl-R for search, but for editing history, ESC-k, k, k, … to step up through recent lines, then vi movement and editing within the line I want (f-CHAR or 3W to move to what I want to edit, then ‘cw’ etc to update) is quite natural.
Same, and there’s always
^x^eto fix up a long command in vim.Wait, that set goes into .inputrc?
Yep!
https://sourceware.org/gdb/onlinedocs/gdb/Readline-Init-File.html
It used to be the case that Mac Python shipped with a broken readline because it was the BSD version or some such, but I haven’t had that problem in years, so either it’s fixed or I just stopped using system Python and don’t notice anymore.
Readline is problematic. Unlike most other GNU libraries, it is GPL’d, not LGPL. Around 2007, it became GPLv3. This means that you cannot link libreadline in anything that has any component that is not GPLv3 compatible (or, at least, you can’t redistribute the result). Most code that I use moved over to libedit (originally from NetBSD) once it reached the point of being an adequate replacement for readline for precisely this reason. Libedit provides its own APIs and a readline compatibility shim and so is mostly a drop-in replacement.
I don’t know what the Python package does, whether it supports libedit upstream or if that’s an Apple-specific patch, but in general you need to be very careful of the license if you use readline.
[ Edit: ] From the link @andyc posted below, it looks as if it has a compile-time flag to use libedit, so you may find that any given Python deployment is using either readline or libedit and probably need to be careful to avoid depending on implementation-specific functionality.
Note that readline is not just intentionally GPL, but strategically licensed in order to force people to either release code which uses it or avoid it altogether. I seem to recall the FSF explicitly saying at one point that it was a victory for Free Software when Apple chose to stop shipping GNU software, and this attitude is specifically highlighted for the case of readline. For example, in this history of the GNU project, they say:
It would be just as reasonable to say that Apple is the problematic party, since their attitude extends beyond just readline.
It is a nice module that provides a lot of functionality behind a simple interface. If anyone wants an example of hairy details in the Python-C API, the module deals with a ton of nontrivial issues, e..g callbacks, signals, global variables, etc.
https://github.com/python/cpython/blob/main/Modules/readline.c
Oil uses it and I had to dive into the code (enabling
horizontal-scroll-modein the latest Oil release, which should solve some drawing problems with a zsh-like prompt.)I learned that there is a lower level interface that lets you process things character-by-character, and that’s what CPython uses. Basically because readline and the Python interpreter “fight” over signals, which are process-global.
https://tiswww.case.edu/php/chet/readline/readline.html#SEC43
If you are making an interactive interpreter, make sure to check out the
cmdmodule. https://docs.python.org/3/library/cmd.html Besides tab completions and help text, It handlesreadlineautomatically (you still need to save/load the history file if you value that feature.)