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.
rlwrap is fantastic. here's a multichannel text chat system for other people who can ssh to the same host, with command-line editing, cross-session history, and logging provided by rlwrap:
#!/bin/sh
# Simple chat system frontend, wrapping gyap in rlwrap and maybe ssh.
: ${GYAP_LOGFILE=$HOME/gyap.log} ${GYAP_COMMAND=gyap}
if [ "$#" -eq 0 ]; then
rlwrap -C gyap -l "$GYAP_LOGFILE" "$GYAP_COMMAND" "$@"
else
host=$1; shift
rlwrap -C gyap -l "$GYAP_LOGFILE" ssh "$host" "$GYAP_COMMAND" "$@"
fi
the actual chat system is another 10-line shell script called `gyap`
#!/bin/sh
: Simple chat system. cf. rgyap. ${nick=${1-$USER}} ${chan=${2-/var/tmp/chat}}
echo "Chatting on $chan as <$nick> (override with $0 \$nick [\$chan])"
touch "$chan" && chmod 666 "$chan" 2>/dev/null
sign() {
echo "$(date +%T) * $nick signed $1 ($(date +%05Y-%m-%d))" >> "$chan"
}
echo "Press ^R if a chat line appears as you are typing. Recently:"
tail -Fn 16 "$chan" & pid=$?; trap "sign off; sleep .1; kill $pid" 0
sign on; while read t; do echo "$(date +%T) <$nick> $t"; done >> "$chan"
it's not secure of course; anyone can spoof anyone else or fill up your /var/tmp disk, or read the log without signing onto the channel
it would be nice to have rlwrap options to customize tab-completion, for example for expanding to recently-mentioned nicks or slapping someone around a bit with a large trout
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!
Some years ago I helped diagnose an O(n²) 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.
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.
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!
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.
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.
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:
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).
Plus C-a, C-k etc. This is one of the reasons I'm so glad I learnt Emacs defaults instead of something else like vi. It works in every program that users readline!
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.
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.
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.
^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)
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.
"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.
"The dash shell is actually reasonably pleasant for interactive use when compiled with libedit."
For me it's the preferred interactive shell. When compiling dash with libedit, I edit dash source to enable tabcomplete. Then it feels more like NetBSD.
I've been running an experiment using busybox bash instead of dash as both interactive and scripting shell; have discovered numerous busybox idiosyncracies as a result. One thing I like about busybox bash is it's command history search: Ctrl-r. A bit faster than libedit.
busybox "ash" is littered with "bash-like" features. Searching command history using Ctrl-R is just one of many. IMO, it has enough changes from NetBSD sh and Debian sh that it is neither ash nor bash. Regardless, I should have referred to it as "busybox ash". Apologies for the inadvertence.
busybox includes a config option to include a "bash" applet name that points to "ash"; typing "busybox" one will then see "bash" listed as an applet, but is the same shell
Sometimes when compiling software, authors insist on using bash scripts at compile-time rather than sh scripts. Trying to use busybox ash to run these scripts will fail because there is no applet called "bash". There might be another workaround but I find it useful to compile busybox to include a "bash" applet name.
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.
Did not know of this plugin but my life changed when I realized that pressing ALT+<key> registers as pressing Esc then pressing the key. Therefore in insert mode I just do ALT+I to go to start of line, ALT+A to go to end of line, ALT+o / ALT+O are also useful
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.
People do like to talk about emacs bindings causing RSI, usually to rib on the editor and to keep the tradition of the editor wars going. However, there really isn't all that much evidence for it, is there?
Of course it's often in jest and somewhat famously the plural of anecdote is data, but it would be nice to know if there actually is something to the RSI. Ergonomics is complicated enough as-is.
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.
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.
Readit News
it's not secure of course; anyone can spoof anyone else or fill up your /var/tmp disk, or read the log without signing onto the channel
it would be nice to have rlwrap options to customize tab-completion, for example for expanding to recently-mentioned nicks or slapping someone around a bit with a large trout
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.
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.
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!
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.
<https://oracle-base.com/articles/linux/rlwrap>
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
Apparently, a pretty incurious one.
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)
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.
For me it's the preferred interactive shell. When compiling dash with libedit, I edit dash source to enable tabcomplete. Then it feels more like NetBSD.
I've been running an experiment using busybox bash instead of dash as both interactive and scripting shell; have discovered numerous busybox idiosyncracies as a result. One thing I like about busybox bash is it's command history search: Ctrl-r. A bit faster than libedit.
NB. "set -o vi" can be abbreviated to "set -V"
busybox includes a config option to include a "bash" applet name that points to "ash"; typing "busybox" one will then see "bash" listed as an applet, but is the same shell
Sometimes when compiling software, authors insist on using bash scripts at compile-time rather than sh scripts. Trying to use busybox ash to run these scripts will fail because there is no applet called "bash". There might be another workaround but I find it useful to compile busybox to include a "bash" applet name.
Normally I would do this in NetBSD sh using the builtin "fc"; dash excludes the fc builtin.
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
Of course it's often in jest and somewhat famously the plural of anecdote is data, but it would be nice to know if there actually is something to the RSI. Ergonomics is complicated enough as-is.
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 :
Probably tens of millions at this point.