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.
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, it seems like a no-brainer in this context to build in a rich command-line history feature with search, cut, paste, and movement by words for command-line editing, plus filename completion. readline is solving a much harder problem given that it had to do everything through termcap and degrade gracefully on shitty terminals! 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
(for batch files, it also seems like a no-brainer to implement something like the bourne shell's control structures, and there was less excuse for not doing that, given that they were already aping unix's hierarchical filesystem)
it makes me wonder what kind of obvious improvements on today's computer systems we're missing
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
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).
i'm a little rusty wrt facts at my fingertips, but broadly speaking (i'm using "you" to mean program author, but that entails sometimes being a program's victim):
when you want a program to get everything the keyboard sends (which means the program will have to handle everything the keyboard sends), your program needs to put your tty into "raw-mode". If you want the operating system to handle things like backspace or left-arrow to correct typos, instead of putting it into raw mode, your program just leaves it with the default in what-came-to-be-called "cooked mode"; cooked mode generally means a line will be sent at a time after ENTER, instead of char by char as keys are pressed (note, this is not the same as half and full duplex, though it is related).
Programs can be linked to use readline to read, while the rest of the program can be written as if the tty is in cooked mode; readline will handle the raw mode. Upon receiving characters typed and an ENT, readline will send cooked lines
If your program is getting char by char in raw mode, you need to realize that some keys don't send single chars, they send a series of chars, generally an "escape sequence", both because the sequence needs to be escaped, and also because the sequences escape with the ESC key-char.
you can get into weird modes where the ESC chars get swallowed but the rest of the key-chars pass through. That's what you are seeing when you see letters get typed but not interpreted as arrow key movements. if your keyboard is persistently screwed up, you can use stty to reset it, or if you are really fancy, set it the way your non-functioning program expects it to be set.
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'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.
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).
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.
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.
It's not BlueZ's license that is the problem, it's readline's license which BlueZ unconditionally pulls in. I wonder if they considered just stubbing out the functions, or if any of the more liberally licensed libraries (editline, tecla) have compatibility headers?
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.
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.
> 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.
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.
Except that GPLv3 overrides the contracts. If you violate it, you lose the right to use the GPLv3 software.
Technically, a litigious-happy contractor can use that to cause a lot of damage to the company. So that's why many companies (e.g. Apple) just ban as much GPLv3 software as they can.
you're right; i had a vague memory that they had perhaps included language in the license to clarify questions like this, but apparently not. this is all it says
> To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
> Is making and using multiple copies within one organization or company “distribution”? (#InternalDistribution)
> No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.
> However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.
note that this is talking about gplv2 ('distribution'), so presumably contractors can already sue apple for this if apple uses gplv2 code in internal tools; they might not win, but the fsf thinks they should
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.
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.
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.