This is nice. As always, Julia's articles are always a win.
Here's some stuff that's missing:
Within shell scripts, you can use `stty` to change a lot of stuff about the terminal, including how it deals with inputs. You can rewire all of these defaults and behaviors.
It is able to capture and understand most keyboard combinations and even mouse gestures (hold/drag/drop) from within the shell in any VT100-compatible terminal (mintty, xterm, Terminal.app, vscode, so many others).
Runnable demo:
bash -c "$(curl -L https://git.io/fjToH)"
Run it and press some keys or move the mouse. Use Ctrl+W to exit. It supports zsh and ksh too, but not dash or other shells lacking `read -rn1`.
---
Here's another funny thing:
`vi | cat -v`
If you pipe an interactive program to `cat -v`, you can see which VT100 escapes that program is using. I learned a lot from how vi does it.
Programs that draw a progressbar often hide the cursor so there won't be a blinking cursor "glitching" the visuals. Once you see it, you'll start noticing programs that hide the cursor.
If it happens only on wezterm, it is probably some kind of bug on their part (no support for the escape code that re-enables the cursor maybe?). Have you tried other terminals?
In maybe similar spirit, another screwy way to explore terminal IO mechanics I came up with when reading the start of Kernighan's UNIX Programming Environment:
With the #3 terminal active, try reproducing the whole "Hex" column of the manpage, in order. And, observing that some values have multiple ways to produce them, and also observing the multi-byte payloads of some of the other keys.
I'm not going to pretend to grasp through and through what exactly I'm accomplishing with this but will happily read any commentary.
Also, just in case anyone is wondering, as I once did, where many of these magical-looking stty parameters and symbols are coming from: they are control sequences defined a long time ago. A lot of stuff is defined in ambiguous old standards from the 70s such as ECMA-48 that include such arcane terminology not seen anywhere else.
For example, jargon like Select Graphic Rendition basically refers to a 70s version of the HTML <font> tag.
SGR<params>TextSGR<0>
<font params>Text</font>
Where params are something like 38/2 RGB to set foreground color. The parameter 0 clears the current style.
ESC[38;2;R;G;BmTextESC[0m
<font color="#RGB">Text</font>
ESC = The literal ASCII escape character
ESC[ = CSI = Control Sequence Introducer
m = SGR = Select Graphic Rendition
38 = Set foreground color
2 = Use the RGB color space
RGB = Color
0 = Reset style back to defaults
Parameters come before the command. Kind of backwards.
They even had the same implementation issues we have today with browsers. Terminals were and stil are inconsistent in what they implemented and how they did it. Stuff like colors is pretty well supported but many other features aren't. For example, SGR<7> is supposed to enable "negative image" mode, whatever that is. Standard doesn't really explain. Some terminals choose to do reverse video, other terminals do other equally valid things and to this day people have problems with it.
I like your comparison with browsers. In many ways, the only way to know for sure is to test in the desired terminals and figure out what works on all of them.
There's some "new" stuff as well (90's), like SIXEL graphics. I was surprised by how broad the support is (however not that broad to count on it).
Yeah. Even more recent efforts are the efforts to bring powerful features to terminals. Kitty in particular came up with many of them and had to deal with ncurses refusing to support it.
friendly reminder to always check before you slurp code directly to bash from the internet. this may have broke my (admittedly totally non standard) configuration in weird ways I didn't care to document.
Over 20 years ago now I wrote a state machine around readline that meant you could use it as a multi-line editor. Not "multi-line" as in a single line can wrap, but a true editor that lets you move up and down, but is windowless.
It tracks and redraws your cursor when you move up and down between lines, and also pays attention to SIGWINCH to redraw things when the terminal size changes. I've never had the time to rewrite it in Rust, but I'd like to and then release it as a small library.
It's always surprised me that nobody else has done this.
I can implement that specific case with a couple of lines in zsh. Something like:
autoload -Uz zed
icommit() {
() {
zed $1
git commit -F $1 # -a too, if you must ;)
} =(:) # Or maybe even =(< commit_template.txt)
}
Then icommit, via zed¹, will initiate an inline editor with all the power of ZLE available. Hit C-x C-w to write and commit, or C-c to abort. Obviously, you'd want some error checking and the like².
Beauty of this basic implementation is that the keymap is fully controllable in zed as it is simply a new ZLE widget. It works with emacs or vi mode out of the box, and is fully customisable beyond that.
You could make the interface generic by writing your own ZLE widget, so that it can be called directly from within the line editor and remove the need for wrapping commands like I did above.
This was fascinating!! Please do consider bringing it back to life as a library and sharing with HN.
I had no idea how much better such an editing experience is until your video, and completely agree about the benefit of not having to context-switch a la git commit "interactive mode". The "inline typewriter" effect is also really cool
+ different keyboard modes causing the same key press to be presented by different ANSI escape sequences
+ different TTY states (eg local echo)
+ different OSs having subtly different syscalls for changing TTY states
+ differing support for terminal emulation (most these days roughly emulate xterm, but even there, none aim for 100% be compatibility)
+ a lack of a consensus on how to check for features provided by a terminal (some use ANSI escape sequences and wait for an ansi sequence to be returned from the term (that’s how the old VTs worked), some check $TERM (that’s how the first wave of terminal emulation was detected), some terms expose themselves as xterm and ignore the VT feature sequences, but set other env vars. it’s honestly a bigger mess than the user-agent string.
…and this is assuming a POSIX system. Things get doubly interesting when you throw Windows into the mix
In bash, if you set $EDITOR to your favorite text editor, you can send the current line to $EDITOR with ctrl-x ctrl-e. After editing the command you can save and exit for the command to execute.
i don't even know where they are without looking at the keyboard. then when i try to press them half the time i accidentally press insert or print-screen instead
> First, there’s “the baseline” – what happens if a program just accepts text by calling fgets() or whatever and doing absolutely nothing else to provide a nicer experience.
[...] there are actually a few features that you get for free just from your terminal, without the program needing to do anything special at all.
The things you get for free are: [...]
- backspace
- Ctrl+W, to delete the previous word
- Ctrl+U, to delete the whole line
Linux noob here, so this may be a stupid question, but how does that work under the hood?
The documentation for fgets() says [1]:
> Reads at most count - 1 characters from the given file stream and stores them in the character array pointed to by str. Parsing stops if a newline character is found (in which case str will contain that newline character) or if end-of-file occurs.
Does that mean that, by default, fgets() blocks until the user enters a newline and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?
But there seems to be no guarantee that a program is using fgets() to read an entire line - it could also set count to 2 and read individual characters. Those could not be "unread" anymore when a backspace occurs. Is there some magic that lets fgets() buffer characters internally in such a situation, or would the backspace/line editing functionality just be broken then?
Programs like zsh, bash, ksh, fish and most TUIs put the terminal into cooked mode so that they can manage the terminals behavior manually. In cooked mode, the terminal is not new line buffered and instead every character is read. The terminal only appears to be new line buffered but is actually being managed by the shell, which then in turn allows the devs to add nice features like manipulating the text buffer to do tab completion or prepend the line with sudo.
> Does that mean that, by default, fgets() blocks until the user enters a newline
Yes. By default, terminals operate in canonical mode. I/O does not happen at all until the user inputs a full line. Until the user hits Enter, the characters on the screen are just sitting there in the terminal's memory while the application's read system call is blocking on the terminal's file descriptor. The terminal does not write the data until the line is complete.
> and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?
Provided that "it" refers to the terminal, then yes. Normally it's the terminal itself which allows you to edit the line you are typing on. This is also provided by the default canonical mode. Even the fact that letters show up on the line when you type is a terminal feature called echoing. So are things like backspace, delete, Ctrl+C for SIGINT, Ctrl+D for EOF.
Line and text editors just turn off all of this stuff. They place the terminal in raw mode where everything you type is sent immediately to the application where it is handled immediately. A wide variety of everyday programs do stuff like this. For example, password prompts simply turn off echoing to hide the characters.
Even the traditional Unix line ending \n is actually a feature of terminals. To the terminal, \n just moves the cursor down one line, \r is also needed to go back to the beginning of the line. The true line ending is therefore \r\n. The terminal just happens to invisibly turn \n into \r\n. This too can be disabled.
> The terminal just happens to invisibly turn \n into \r\n.
No, it was actually done by the Unixen itself, in the part of the kernel that handled ttys: it convert '\n' to '\r\n' on writes to ttys, and '\r' to '\n' on reads from ttys. Linux only recently have moved this functionality out into the user-land layer.
Hmmm, I could swear I have read about moving line discipline out of the kernel in some LWN article but apparently no, it never happened (although it probably should've, there is no much reason to perform mapping of NL to CR-NL in the privilleged mode). Maybe I've confused it with what happened on the Windows side of things? They moved almost all of the console infrastructure out of the kernel recently and into the user space, and that definitely has happened.
I suspect Linux actually can't move it to user space. It would break binary compatibility with all user space code that sets OPOST via the ioctl. They can't hide it in a libc either.
To be clear, it's not the terminal emulator (xterm, mintty, iTerm2, etc.) that does this. It's the tty layer. You can use the stty command to change the settings.
One of the first challenges I faced as someone who got paid to program: port the VMS "help" program to SunOS (a *nix). Initial challenge: how to respond to each keystroke rather than wait for enter/return. My boss was intentionally unhelpful and forced me to figure it out more or less all by myself (remember: no web, and hardly any O'Reilly books in 1986). I remain eternally grateful for his judgement to this day.
> some programs (the dash shell, cat, nc, git commit --interactive, etc) don’t support using arrow keys at all.
The dash shell does in fact support an editing mode if compiled with libedit. Debian derivatives do not do so (likely for concerns of space). They very much should, as people who start with bash will have much to unlearn.
The POSIX standard also specifies "set -o vi" as an optional extension. Every shell claiming POSIX-compatibility must support set -o vi if the shell implements this editing mode (so ignore inputrc if it pleases you).
"[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."
> They very much should, as people who start with bash will have much to unlearn.
Dash on Debian is intended as a light POSIX sh to execute shell scripts. It isn't meant to be your login shell or for interactive use. It makes sense to keep the dependencies light in that context.
I have continually contented that the terminal is the single thing eternally condemning Linux to <5% market penetration.
It's not just entering text. The entire experience is complicated. It's a Concorde jet cockpit[1] (with no labels too), when 95% of the population just wants to fly their drone around[2].
If the only Linux distributions were in the style of LFS, Gentoo and Arch* you would have a point, but as long as Ubuntu, Mint, OpenSUSE, Fedora, Manjaro and the myriad other user-friendly exist I fail to see the argument.
Yes, Ubuntu has a Concorde cockpit behind the scenes and yes, I can access it on my Ubuntu work* laptop and I am grateful that I have that choice. I would hate not having that level of control.
Meanwhile, my mother's laptop is also Ubuntu and my girlfriend's is Manjaro, and they are both perfectly happy "flying their drones around" without ever setting foot in the Concorde cockpit.
I have used ubuntu for 2 years now, and its the motivation for the post.
Ubuntu (or really any distro I am aware of) is great for pensioners (email readers) and power users (career linux user), with a protracted and hellishly complicated experience in between (technologically adept, but lifelong windows user).
True, if you just want to fly straight to one of the most popular cities, you can just enter it in the autopilot and it will go there. But if you want to go anywhere or do anything else, you better be good a googling and understanding "how to fly a Concorde".
A better way is to get a book about linux administration (if you want an in-depth manual) or "How Linux Works" by Brian Ward. Then learn bash.
Windows is pretty much all GUI (I've left before getting used to Powershell) and that works great until you want to do rules-based changes or do profiles (without using MDM) with changes snapshot.
Most software have good manuals so once you've got a bit used to the linux's way, it's quite easy to adjust anything you need. And after a while, you find you're mostly using a few handful packages and you'd have their configuration saved in your dotfiles. As for packages suggestions, that's what distros are there for.
Trust me, I understand that Linux is all about reading.
I also understand that it is perpetually irrelevant in the consumer computer space, despite everyone in that space absolutely hating the dominate OS. A hate that you can watch grow in virtually real time on any social platform. But that hate is focused on pushing the giant back in-line, not at abandoning that giant for fresh pastures. You know why?
Because 30 years ago, someone who touched grass realized that consumers cannot, let me repeat: cannot, use an OS that is "all about reading".
Most consumers want appliances, aka a collection of software pre configured with a few customization options. When the current solutions (ipad, phone, MacBook, PC) fit, it’s great. And the current linux desktop distros are doing great in that regard, except on two points. They do not come pre-installed (with hardware support) and some software don’t support linux.
But as soon as you want something custom and do your own configuration, the manuals are required. Or you get someone to do it for you.
The middle hellish experience being described here is not a bad thing.
Fact is, Ubuntu used as autopilot is pretty great! It is way better than it used to be. Mere mortals can jump on a computer and often get the few things they want done.
What I do with users of that type, and myself depending on my moods and motivations for a particular machine, is treat it like Android.
Find the users an app they can click on and or tell them it is not going to happen.
Many will be happy with that.
The ones who are not need help.
Either they grow and become readers, and can pilot the computer properly, or they won't and helping them makes as much sense as their own efforts do.
> technologically adept, but lifelong windows user
Windows power users are also the ones who rant about the lack of video games in the ecosystem. They already have their happy place, and are not a worthwhile target for recruitment.
Some of them are. Namely the ones willing to have an open mind and learn new things. Games in particular are not a problem unless you are set on playing modern online games which require draconian kernel-level DRM.
> technologically adept, but lifelong windows user
This kind of user is going to have a bad experience with anything that isn't exactly Windows unless they are willing to adapt. The problem isn't that the way Linux does things is bad, it is that it's different from what you are used to. I guarantee that as someone who is at home under Linux dealing with anything on Windows feels just as bad for me as Linux does for you.
Linux the kernel + some userland without terminal is used by majority of people in the form of Android and Chromebooks.
A terminal is a developer and sysadmin tool. It just so happens that most users of desktop GNU/Linux are developers and sysadmins. They are a few percent of population.
Gnome tries hard to emulate Apple's approach. Results are mixed, but I've seen fans of it.
Elementary OS goes in the "normal users" direction, too.
OTOH if something goes badly wrong, and you do need to open the hood and follow an arcane tech support recipe, you open a command line, be it Linux. macOS, or Windows. (Not Android or iOS though, where you do a reset + restore dance.)
> people want out of Windows
Yes, here's where they meet Steam Deck, that did take note, and just puts you into a cared-for gaming environment. It can also run a typical desktop. The hardware is proprietary, but the software is (mostly / completely?) free.
> Yes, here's where they meet Steam Deck, that did take note, and just puts you into a cared-for gaming environment. It can also run a typical desktop. The hardware is proprietary, but the software is (mostly / completely?) free.
The SteamDeck hardware is about as proprietary as any other x86 PC. It's not open source HW but it's also not really all that custom for the most part.
Except Classic Mac OS never had this. You'd sometimes need to do arcane rituals like "re-bless the system folder", but they were entirely GUI-based arcane rituals that involved double-clicking icons, opening and closing windows, and dragging files in and out of folders.
Text interfaces: streams of discrete objects (characters) with some having special purposes
GUI: A matrix of pixels + a set of of rectangles with special properties attached.
If you want to quickly write a program, text is the way to go. Most developers are scratching their own itch and already know the system. They may surface a few GUI settings (if it's GUI), but no one wants to build a complete GUI ecosystem on top of Linux (unless you go fo a restricted version like ChromeOS or Android).
And with scripts, you can quickly write your own software by using existing ones. It can be your very special computing world.
There was no other, simpler interface. And the whole system was much simpler (and less capable). The graphical hardware was way simpler and fully in-house, unlike the current GPUs that are third-party and evolve quickly.
Exactly, there was no other, complicated interface. Except in 1991-1995 when System 6 was going to merge with AIX and be A/UX and Apple was going to merge with IBM and it was all briefly very weird.
I must be doing something wrong because I can just use Home to go to the beginning of the line and End to go to the end and I am pretty sure all the things that are easy to type as just as easy to type be in Gnome Terminal on Ubuntu or Windows Terminal on Windows.
The only place I need to know a bunch of weird shortcuts to figure things out is in the macOS terminal where everything is the less intuitive as possible.
What's condemning Linux to negligible market share is lack of preinstalls. Virtually no one used Windows, either, until Microsoft did everything short of coercing OEMs to bundle and preinstall it during the 3.x era.
If you love cars, popping the hood is probably part of the experience. For everyone else, it’s the sign of a very frustrating day ahead.
As computer lovers, I feel we must endeavour to remain mindful that almost everyone else aren’t like us. They’re trying to get a task done. They don’t want to maintain or talk with the computer.
> As computer lovers, I feel we must endeavour to remain mindful that almost everyone else aren’t like us. They’re trying to get a task done. They don’t want to maintain or talk with the computer.
This was pretty much my point. 95% of the population isn't like us, and don't need to interact with the terminal; thus, thinking the terminal is what's keeping Linux back doesn't make much sense to me
The larger issue is the times that the Linux UX goes off the rails and the solution turns out to be "You're going to have to bleat this esoteric incantation at the command line." I plugged my laptop into a second monitor the other day and, oops, for whatever Godforsaken reason it didn't auto-detect. Suddenly I'm munging around in `xrandr` to get my screens to work.
To its credit, all the major desktop distributions today are making real inroads to narrowing the scope of situations where that happens. This was a much larger concern in the past, where key aspects of the user experience were still in the category "There was a command-line tool written to control it and that's all you'll ever need, dammit."
The alternative is "it just won't work". You too can live in that world by simply not trying to fix it.
My wife's Macbook won't suspend correctly when it's plugged into a Dell monitor, the monitor going into power save wakes up the laptop. I wish there was an arcane incantation that would fix it, but no, the proprietary walled garden is well locked up, with glossy user-friendly rounded corners everywhere.
This is the most insightful post in the thread -- there's definitely a false dichotomy here. It's not "have to use a terminal" vs "everything works without a need for a terminal ever" -- it's "able to use a terminal to accomplish some goal or recover from Really Bad Thing" vs "Can't Do That Thing / have to factory restore to recover".
Like the way Apple Maps on my iPhone can't save the person to notify when I navigate to Home. I can save a person to be notified to any arbitrary location besides Home. With Home though, the setting simply doesn't save. I'm sure if I had a terminal I could inspect the data involved and manually fix what's wrong, but the 'Apple' or GUI-only approach simply makes that out of the question. Even better, when the corrupted data is cloud-resident I think the answer is often just that it's broken permanently unless you want to create a brand new account.
There are millions of computers out there that just don't work right, or where people can't accomplish some goal they wish they could. That's the flip side of the 'terminal or not' coin. Neither is a good experience for users who aren't technical though. For nerds though the Terminal provides a great deal.
I think my main gripe though is that there simply isn't enough drive to move things out of the terminal and into a GUI.
I really think that a core problem is that once you are in a position where you are contributing to distros, contributing to the kernal, you are well versed and acquainted with the terminal, and you love it's incredible power and efficiency. The cockpit is no longer a sci-fi meme, it's a meticulous masterpiece granting a god-like computing interface. Nobody at that level is interested in much GUI-ification, because, holy shit, this CLI is the best! (Never mind that software engineering is dominated by "complexity and control" types vs "simplicity and automatic" types of the wider population.)
In general, Apple would solve that problem by recommending you plug an Apple computer into an Apple monitor.
The Apple ecosystem is well incentivized to make all of their pieces work with their other pieces. The Windows ecosystem is pretty decently incentivized to make things work together in general (In both directions... Windows suffers in sales if there's some popular hardware it won't work with, and popular hardware suffers in sales if it doesn't work with Windows).
One certainly does run into the occasional Dell monitor with Apple laptop problem that you then need a couple of insider specialists to address. But I've not really been sold on the notion that The open ecosystem is strictly superior in that sense... In theory it is, in practice you can't be an expert at everything and there's no guarantee anyone's going to come along and care about how to fix your particular Dell / Linux distro configuration.
How does the monitor thing relate to what I was saying? In my case, I'm saying that Apple's tightly-coupled, app-OS-cloud integration means I have no ability to see what's wrong (and I'm positive the minimum wage phone support guys will not be able to escalate a bug like that to Engineering and get it fixed). My point was even first-party walled garden stuff doesn't work right, and having no access beneath the GUI rules out anyone outside being able to fix it. I get your point though that the 'right person' who could use that access to more obscure things may be rare anyways.
> They’re trying to get a task done. They don’t want to maintain or talk with the computer.
Computers are complex things. Sometimes, things broke and you just can't do the task. But for a knowledgeable person, you just "pop the hood", fix the problem, and then get things done. On My iPad when the Files app freeze, there's nothing to be done other than reboot to get it working again. On Linux, I could pkill a software, restart it in debug mode or go find the logs to know what's wrong. Yes, there's a difference of mindset. But I prefer the "hood" to be there instead of having it be an opaque box.
If you want to get a task done, learn the software that can do it, externalize everything else (IT support). But sometimes, that software is the terminal or it's where the software is.
Doesn't Windows, the most popular OS out there, have a cmd.exe terminal thing? Why isn't that harming Windows?
The Windows Command Prompt's default experience is worse than most if not all terminals you find on Linux systems. Even in play TTY, you're bound to find that the shortcuts the author mentioned work like a charm.
> Doesn't Windows, the most popular OS out there, ...
The most popular desktop OS. It is nowhere to be found in the Top 500 supercomputers, is nowhere to be found on smartphones, lags in the Cloud, is nowhere to be found in the billions of appliances, etc.
> Why isn't that harming Windows?
It is harming Windows. That horrible cmd.exe is one of the reason Windows lost in all the other markets and has hardly any market share there.
> is nowhere to be found in the billions of appliances, etc.
It is unfortunately found in plenty of embedded systems. Usually not in cheap end-user appliances though where it is outpriced due to both the OS license as well as the hardware required.
Back in the 90's a lot of movie production was being done on the SGI IRIX computers. Jurassic Park themed ones even. Really spiffy machines with both an excellent GUI and terminal.
Cheap WIN NT boxes with nVidia GPUs on them, were seen as the beat path forward.
SGI gear is also Jurassic Park style, "Spare no expense" and was not cheap! Super expensive machines, but people got what they paid for too.
Alias, Maya were ported to Windows and off to the races right?
Nope. Unix scripting, that awesome terminal and friends made all the difference in the world.
This was true even for smaller or single person shops who would do the work in a now slower SGI because the user experience was bang on point and that meant getting the desired outcome first time no bullshit.
The minute we had nVidia drivers, Linux was in to replace the SGI machines.
And, the production community realized they could each write tools or poet tools they were good at, share and share alike (to a point) and all be in business a whole lot cheaper and faster.
That took a couple maybe few years.
The "terminal" and what can happen in one and why really does matter.
Windows Power Shell is pretty OK at this point, but it is still its own thing, not playing very nice with the other kids in the sane box.
Lol, I always thought Microsoft happening in Redmond was symbolic. It really is!
Windows has a new terminal as default that is pretty cool - I install MSYS2 and set it in the new Windows Terminal and it's all good. Gnome Terminal and other terminals on Linux are also pretty cool too.
If you want the worst default terminal experience just boot macOS.
Can you explain what's the big appeal of other terminal apps? I have been using Terminal for 21 years without any issue -- but I'm open to trying something else.
Actually I've only this year switched to an "AI enabled" terminal app called Warp.
I’m curious to know what your experience of changing to Warp has been like? Sounds like terminal was working fine for you - was the switch worth the time?
I signed up for the waitlist ages ago and finally got the announcement of Linux support in February but am still yet to try it. Mainly because I’ve had a particularly busy year and I can’t justify fiddling around with my stack just for fun. I have no appetite for the risk I may lose hours to fixing something that goes wrong.
On Warp: After adjusting a couple of minor settings, I found Warp to be worth it. In fact, I at first trialed it 'side by side,' meaning keeping Terminal.app and Warp both open -- and found myself going for the Warp window more often. So it was an easy call for me.
I chose to not use its custom prompt because I wanted things to be more 'stock' in the terminal and not to rely on an app external to the shell for the features -- the only really fancy prompt feature I have is git branch display, and that's already working fine with my existing zsh prompt.
So, anyway, I can vouch that it didn't try to make changes to my environment (other than that offering to override the prompt, which I think it does in a way that doesn't update your .zshrc/.bashrc file anyway).
And for what it does do, I think it's great. Having command outputs separated and in little scrolling panes, really great. And mouse-able, standard text field to edit commands in, also amazing. Say you have a long URL on the clipboard with a {object_id} variable in the middle. You can paste it in, and use the mouse to select "{object_id}" and replace it instead of using arrow keys etc. to manually delete and replace the variable. So with the above efficiency gains it is already pretty cool compared to any kind of terminal app I knew of.
The AI stuff has been great to have as well. It's really convenient to have free access, right in the terminal, to an LLM that I assume has been well prompted to produce shell or scripting code as requested.
One thing I turned off is their recent "Detect natural language automatically" feature. Before, if you wanted to invoke AI, you just did a #comment. So for instance "# docker command to remove exited containers" -- well, they updated it so that even without that "#" it should "just know" from inspecting the command. But I had a problem with it getting confused by a shell command that was also parseable as 2 English words. I think I prefer actually knowing whether I'm commanding a shell or operating an LLM, anyway.
BTW - it occurs to me that there are also big categories of features that it has which I don't even use, such as like, runbooks that can automate frequently-done tasks, things like that. Those may also factor into your decision.
Plus for a long time desktop Windows needed cmd.exe to support login scripts.
Just as people use Linux daily without ever touching the command line. Eg Android, LG smart TVs (webOS), Satellite TV set top boxes (eg Sky Q), home routers, etc.
And if you want to focus on Linux running on laptops, then there are ChromeBooks and the old Asus EeePCs.
The reason desktop Linux isn’t polished is because every time a company invests heavily into desktop Linux, Microsoft undercuts them (like how they sold XP at a loss to thwart Linux in the netbook market). But the fact that Apple could take BSD, Google take Linux, and Nintendo also run BSD on some of their consoles, really speaks volumes about how there’s nothing technically stopping people running a POSIX platform like Linux and still hide the command line from regular users.
Though going back to my “Linux isn’t polished” point, I still think Linux+KDE is a lot more polished than modern Windows. But that’s just my biased opinion.
For my main point, I suppose I should have specified GNU/Systemd/Linux as needing a CLI, not everything with a Linux kernel. POSIX-style kernel + libc is a very good basis for an OS, and such an OS doesn't need a CLI exposed to the user. It's all the Udev/Systemd/SysVInit & similar stuff that's CLI-only, and desktop Linux tends to require interacting with one or more of those on at least an occasional basis.
There are web based GUIs for systemd (and sysv init too).
But the main reason you don’t see GUIs for those services is because Desktop distros tend to abstract away systemd so you don’t even need to manage it, let alone have a GUI to do so.
Like with Windows, the average user wouldn’t be manually managing what services to start and stop.
And that’s the real crux of things. A lot of the stuff that people say you need a CLI for in Linux are operations that the average user wouldn’t know nor want to do on Windows even with a GUI. They just run a browser and if the machine goes slow they ask someone technical (friend or shop) to fix. I know this because I used to be that friend.
So I really don’t think the CLI is what holds back Linux. It’s just the economics was never there while Microsoft dominated the desktop world. And these days most people use phones and tablets as their general purpose device, so in a way Linux did eventually win anyway.
> Just as people use Linux daily without ever touching the command line. Eg Android, LG smart TVs (webOS), Satellite TV set top boxes (eg Sky Q), home routers, etc.
None of those are (used as) general purpose computers though.
Did you read my next paragraph where I acknowledged that point myself and gave some laptop examples too?
Plus I’d argue Android is the average persons general purpose computer. At least in terms of the people I know, they use their phones for 99% of things and actively avoid using a laptop as much as they can.
> Doesn't Windows, the most popular OS out there, have a cmd.exe terminal thing? Why isn't that harming Windows?
That's because the overwhelming majority of Windows usage, administration, and programming can be done almost entirely without ever touching the command-line, from Explorer.exe, Task Manager, Edge, Media Player, Paint, and built-in ZIP handling to the huge list of MMC snap-ins[1], and Visual Studio 2022.
> tl;dr You're comparing the choice of wheels on a plane to what makes planes sell more.
For the record, aeroplane cockpits have also gotten considerably simpler in the intervening half-century since Concorde and the first 747s. Here is an Airbus A350 cockpit[2].
That does not match my experience, even if I also believed that myth.
At one time I had to install Windows Enterprise IoT on several kinds of embedded computers, all of which had various quirks.
The computers worked fine in Linux, from the first attempt to boot it, without the need to do anything special, but a customer wanted to have Windows on those.
After installing Windows, there have been a lot of problems, for instance Windows was unbelievably slow, because the SSD's had a very low writing speed, but they could not be replaced with decent SSD's, because the embedded computers were certified for certain applications only with their original components.
Making Windows usable on those computers has required a week of tuning and finding various workarounds by searching the Windows Knowledge Base and various Internet Forums, where many Windows users had the same complaints as me, but few were able to provide good advice about how to solve the problems.
I have been astonished to discover that for every workaround I was not able to find any way to do it in any graphic interface of Windows, but all workarounds required to use in a Cmd window some obscure Microsoft command-line utilities with a lot of magic command-line options, which I did not understand and I could not find in the official Windows Knowledge Base, but which were suggested as solutions on various Internet forums and indeed they worked as desired.
> For the record, aeroplane cockpits have also gotten considerably simpler in the intervening half-century since Concorde and the first 747s. Here is an Airbus A350 cockpit[2].
I mean, aesthetically it's simpler sure, but the complexity is still there; it's just now much more digital.
if you have a problem with gnu/linux (as opposed to android) you can usually find the solution on stack overflow, server fault, or superuser, but the solution you find there is going to be a textual command line, not a gui. gpt-4 can tell you how to solve the problem, but only using a textual command line, not a gui. text is the most powerful, useful, effective communication technology ever, period. always bet on text: https://graydon2.dreamwidth.org/193447.html
on the other hand, 'always bet on text' doesn't mean 'always bet on editing your command line with inconsistent control-character commands in a mode where clicking with the mouse doesn't do anything'
In GUI environments there are check boxes, buttons, menus and english labels for everything.
With linux it's like you are copying down a sacred language and presenting it at the alter with your fingers crossed. You just changed something. Didn't fix the problem. But the change still happened. Can you undo it? Probably not without way more digging. So now you just cross another set of fingers hoping you didn't break it more, or break something else in the future.
Compare to windows:
I checked this box that says "disable firewall". Then hit "Apply".
That did not fix my problem.
I unchecked the box that says "disable firewall". Then hit "Apply".
The usual solution is to read the manual. The CLI is not an esoteric language. Software does complex things and you can either go with the GUI-fiction which...does things. Or have every options available to do what the software can do. Take find where the first line is the manual is: find - search for files in a directory hierarchy. Think however you want to find files inside a specific directory and find can do it for you and more. Most users will only have a few use cases for finding and that's what most GUI file explorers offer, but when you need that extra power, it's available to you.
The solution for your problem is to not do stuff you don't understand. And for the above use case, there's usually a GUI for it. The CLI stuff heavily assume that you know what you're doing.
the cli is just as much of a fiction, just fiction with a different focus
i agree that reading the manual is helpful, but doing stuff you don't understand is necessary to come to understand it, so i don't think it's good advice to avoid it. using the cli for simple things builds the skills you can use for more complex things. the same is true of a gui
(of course there are clis and guis incapable of doing complex things, and those are kind of a dead end)
> but doing stuff you don't understand is necessary to come to understand it
Only if you're doing an experiment and can constrain accidents. Any other type of activities would require to read the manual first. They're terse because they're supposed to be a reference, but you can usually find books that ease the way in. And then there's the domain expertise that is required. You need networking knowledge to interact with software like ip, operating system knowledge to understand what top is showing to you, etc. You can't get around that.
The GUI is a fixed canvas already painted by someone else, the CLI let you write your own poetry.
obtaining networking and operating systems knowledge includes as an essential part using software like ip and top (though try htop instead). it's not a strict sequencing but a back-and-forth interplay, synergistic with factors like study and mentorship
as for poetry, there are plenty of clis that aren't very expressive—rt-11, cp/m, grub, ms-dos, and mpv come to mind—and plenty of guis that are very expressive, such as godot, blender, inkscape, labview, solidworks, freecad, and sieuferd. you can write your own poetry as easily in godot as in bash
what would be ideal from my point of view for check boxes, dropdowns, and labels would be if they were a simultaneous alternative view of a command line, or rather a configuration line. an additional simultaneous view would provide a live preview of the result of that line. but you could still type and copy and paste the text
interestingly this is not too far from my usual experience with the command line. i want to compile a target, so i type `make ` and hit tab twice. i see a list of targets and pick one by typing a letter or three and tab, and hit enter. the compiler errors out right away with a c99 construct, so i add `-k` to the command line (^p spc - k ret) to see how widespread the carnage is. it's everywhere, so i add a compiler flag to the options and try again. and in 30 seconds i have a working build. or maybe i need to use a different compiler, or something, but it's easy to return to the fresh unpacked tarball or git checkout
this is close to the opposite extreme from what you describe in
> You just changed something. Didn't fix the problem. But the change still happened. Can you undo it? Probably not without way more digging.
i very rarely do anything in text mode that is in any way hard to undo. shell commands are mostly purely ephemeral: their only effect is some text on your screen, an entry in your history file, and maybe an output file. if i want to change one, i hit ^p and change it before hitting enter. as for configuration changes, i would say that change management is actually the major strength of the text approach: you can copy configuration lines into your notes, comment out old versions in case you want to go back to them, check the whole configuration into git, diff it to see what all has changed, etc. everything can be undone in exactly the same way. everything is a controlled experiment, with the computer itself recording the configuration of each trial automatically and implicitly
admittedly there are occasional exceptions, like when you're reconfiguring the firewall or upgrading debian to a new release. though current configuration-as-code systems like docker and ansible go a long way to making all that stuff just as recoverable. the server went catatonic? too bad, revert the firewall rule change and reinstall it, and 45 seconds later the problem is fixed
by contrast, it's almost never obvious how to undo clicking on a command button or a menu item. even a dropdown selection is hard to undo: you have to remember what was previously selected
but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it
Trust me man, I know a few Concorde pilots and they sit in that cockpit and flip switches and the spin the controls such that the plane will glide like butter through a hurricane - while myself here is practically crash landing at every stop.
There is the chronic issue with skilled linux users where they keep flexing how good the terminal is (and lets be honest: flexing their fluidity and dexterity with it too) while completely missing the forest for the trees. The terminal sucks because it is difficult to use with an arduous learning curve.
There is a reason why Android, the most successful linux "distro" to the point at the summation of others is a rounding error, has no user terminal and a robust GUI. People don't even know it's linux. Thats what we need; an opensource linux distro that people don't even know is linux.
let's consider the possibility that people might disagree with you for reasons other than being dishonest. for example, i disagree with you because you're completely wrong on the facts, as i explained in my grandparent comment. unlike you, i'm not going to accuse you of dishonesty; possibly you are just ignorant (and aggressive) rather than mendacious
worse, though, you're using your ignorance to promote a vile ideology: the ideology of disempowering users in the name of ease of use. what you're advocating here is the strawman that people sometimes use to criticize guis: not powerful guis like excel, blender, solidworks, godot, photoshop, and autocad which empower users in ways that transcend the limitations of character-cell terminals, but glorified menu systems like mainstream android apps, which reduce users to passive consumers or machine operators
being a machine operator, manually telling a machine what to do over and over again, can be enjoyable and rewarding, as in riding a bicycle, driving a sports car, or your example of piloting a concorde (although you don't actually know any concorde pilots or you'd be aware there haven't been any concorde pilots in 20 years; interpreting you with extreme charity, perhaps you only meant this as a metaphorical explanation of what text-mode uis look like to you). but it must be voluntary, because it's an economically low-productivity activity; when you condemn people to be machine operators, you are condemning them to material poverty. bicycle messengers and taxi drivers do not have easy lives
computers permit people to automate machine operation, which enormously increases economic productivity. that's what we need. things like bash facilitate that, and things like android actively prevent it. good guis like godot's are in the first category, not the second
> but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it
That's where domain knowledge comes in. If you don't know anything about networking other than selecting the WiFi network and entering the password, you're going to have a hard time interacting with ip. If you don't know anything about codecs, ffmpeg will seem esoteric.
More often than not, in MacOS and the like, the GUI is reliable and there will be apps for not so common stuff. In Linux, the software (however complex) has already been written in CLI mode and works fine. Someone could do XLD or iTunes, but they're already happy with their ffmpeg scripts, and their MPD setups.
And the key to get there is to usually get a book about Linux at first, then learn about the software you are using.
When things work fine, then the average person does not need a terminal.
When you do have to fix something, you need a terminal. On Windows you need to touch the registry or worse. Try attaching a debugger to figure out the reason of a blue screen and tell me how user friendly it is.
Finding and changing a cryptic file to fix an issue is troublesome, but if the alternative is "just works" well... you cannot blame the terminal in that case, but the problems that are showing up.
Likely an unpopular take, but I switched to the "Natural text editing" preset in iTerm2 to get editing shortcuts that match the traditional macOS ones. It has the advantage of just remapping to the normal control sequences inside terminal apps, so you basically get this functionality everywhere without needed to change it in multiple places/worry about readline support/etc. It isn't perfect (I have rarely needed to enter sequences manually that then are remapped), but I find I have used way more command editing since its part of my muscle memory.
the top three default readline keybindings that would improve people's lives if they knew about them:
- control-w, which julia mentions in the post, to delete the last word
- control-o: when you're recalling a line from history, edited or no, runs the line and recalls the following line from history. so you can run a sequence of five commands from history by navigating to the first one and hitting control-o five times
- control-r: search backwards in time through your history as you type a search string. control-r again jumps to the previous hit, control-s goes back forward in time. hitting enter or control-o executes it
I've always wondered why control-s was chosen for this, given the obvious conflict with XOFF (pause), which in my experience is the default almost everywhere. One would have to (a) know why it wasn't working and (b) be willing to disable XOFF, in order to use that key combination for the forward history feature.
nowadays it is usually not the default anymore, since tcp connections and unix pipes have other ways to avoid overflowing their buffers. the history is that that keybinding originated on its. as i understand it, its also had another flow control protocol to avoid overflowing serial terminal buffers, the moral equivalent of the enq/ack scheme, which doesn't depend on hard real-time responsiveness to work reliably. (but it wasn't just literally ^e and ^f since emacs uses those even more than ^s.)
initially to get emacs running on unix systems you had to do a lot more than just stty -ixon -ixoff; you had to upgrade your host's ram and convince the other users that an editor was a reasonable use of such a large amount of resources. by comparison, adding a couple of extra wires to the modem cable to support rts/cts flow control (which was more reliable anyway) was no big deal
but yeah, it was a big pain for about 15 years, from 01990 to 02005. it still bites me occasionally when i accidentally type ^a^f in screen and accidentally enable xoff!
Oh I always do ctrl+shift+r for that last bit, like reverse-tabbing on a gui. Good to know about ctrl+s, though I imagine muscle memory will prevent me for ever using it. :)
normally control-shift-r is just control-r; both key combinations send the same byte, 0x12, so they both search backwards in readline history. is your terminal emulator doing something different? if you type control-v control-shift-r enter control-d as the input to the command od -t x1a, what does it say?
So when I use Windows Terminal and I press Ctrl-C, it always does the right thing: If I’m selecting text I want to copy it, if I’m not selecting text I want to kill the running process.
On Linux, every Terminal app I’ve used stubbornly refuses to copy when I press Ctrl-C, demanding I press Ctrl-Shift-C. When I paste, if I forget my manners and use Ctrl-V instead of Ctrl-Shift-V, I am punished by getting a weird character when I start typing again. And I am constantly pressing Ctrl-V because of muscle memory since no other app works this way.
Is there any terminal app for Linux that does things the Windows Terminal way and won’t slap me on the wrist for Improper Teletype Usage?
that doesn't work in terminal emulators because the terminal emulator doesn't know how to delete the selected text in whatever program drew it there (which may no longer even exist)
I copy from/to terminal with middle mouse button. Just select some text and click middle button where you want to paste the text. Some people don't like it because it needs a mouse, they prefer to keep their hands on the keyboard, but I don't see any issues with it.
This way to copy/paste uses it's own Xorg buffer, so you can copy something with Ctrl-C and select something else, and then Ctrl-V will paste the first thing and middle click the second. I have issues using Windows and smartphones because I sometimes try to copy by just selecting things, forgetting to hit Ctrl-C or something. It is really annoying.
> Is there any terminal app for Linux that does things the Windows Terminal way and won’t slap me on the wrist for Improper Teletype Usage?
I think not. The trouble is programs running in terminal may want to deal with Ctrl-C by themselves. Text editors for example do that, but terminals have no way to know it. Terminals even don't know what program is running now, because job control is a job of a shell.
> The trouble is programs running in terminal may want to deal with Ctrl-C by themselves. Text editors for example do that, but terminals have no way to know it. Terminals even don't know what program is running now, because job control is a job of a shell.
But then why does Windows Terminal (even when running against WSL) not have this problem? The terminal doesn’t need to know what’s running inside it to know “if text is selected, intercept Ctrl-C and copy the selected text”.
Idk, but I can guess. In windows terminal and shell are not so separate as in Unix. For example, is cmd.exe is a terminal or a shell? I believe it is both. Probably it is the same with powershell.
This is a mistake, but forgivable, as Windows executable launch behavior blurs this distinction.
Just like UNIX shells, cmd and PowerShell are ordinary console programs.
The Windows equivalent to xterm and friends — i.e., the mechanism responsible for displaying console I/O in a window — is a bit complicated, has changed over time, and only recently (Windows 10 1809 / Server 2019) adopted a UNIX-like pseudo tty / terminal emulator model.
For a good overview of Windows console architecture, past and present, see
I think you could achieve this in Wezterm, which is configurable with lua. Not on my laptop right now but will try to get it working later. I have other keybinds that run specific lua functions.
warp and and some powershell version were the only “terminals” i used that seemed fixing the input line, but also did not quite feel right. the worst parts of terminals for me are that input line does not behave like a normal text field with mouse click, select and everything a user would expect in another context, that history mostly scrolls on a line basis instead of smooth pixel scrolling like any other document (don’t get me started on pagers, i still don't manage to disable man pages opening in some archaic mode that takes 3 tries to even exit from git), commands that default to tuis or clearing the screen. i tried to avoid unix as long as possible because of this and the absurd random / hostile folder names + layout but just because *nixes won does that mean we have to keep these archaic absurdities alive? why does even something where innovation would be simple like the vscode terminal feel like that and not like the chrome console with a normal text input line with graphic autocomplete and mostly immutable command response history with collapse/expandable sections? even unix commands that would not work in this mode could just run in something like an inline widget or new tab where they could read input lines by character or whatever weird behavior they expect.
Ideally we'd have the equivalent of an ipython notebook for the terminal. But GUI on Unix is still an unsolved question with more and more incompatible implementations being written daily, so I'm not holding my breath. After using Linux for over 20 years now, I've concluded that if you want a desktop OS, use Windows. If you use Linux, learn to live in the terminal - it's the only consistently working piece of the OS, everything else is consistently broken.
I plan to make one day an alternative to terminals. My idea is not fully fleshed out, but I would like to try to forgo TTYs altogether. Use only pipes, file descriptors and job control.
One thing to start with is to not throw the user into a screen consisting of a grid of fixed width character cells at the very beginning. This is what immediately sends a signal of discomfort to most users not already familiar with terminal emulators. There's no real reason why the default experience of having a dialog with your system installation couldn't take place within an interface that resembles iMessage or ChatGPT or something like Quicksilver. Things like /bin/rm certainly don't care whether they're being invoked from a terminal emulator that has the conventional look or whether it's in a chat-like interface—it doesn't rely on any line drawing characters or output alignment. Even the Python REPL doesn't depend on that sort of thing a great deal, except for stuff like ASCII art arrows pointing to syntax errors. Only when you want to use stuff like vi or ps and ls helpfully trying to put things into columns will you start running into trouble if your terminal emulator has an non-traditional UI. This can be ameliorated to some degree with heuristics to detect e.g. spaces being used for alignment and cursor positioning escape sequences in the output stream.
The utility in your link, and the entire Arcan system, seem very pleasant to me; a dream of mine is to have a complete graphical LISP command-and-control via an interface like that; like the old lisp machine UIs but with more direct incorporation and seamless handling of multimedia Objects.
I’m working on a similar vision. Except instead of replacing the terminal, I’m turning it into a more of an ergonomic interface for structured data and multimedia.
Nice to see this writeup. Entering text into the terminal, and copying output out, is a huge barrier to entry for beginners. Windows terminals in particular feel downright antagonistic to use.
> took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end).
And the curse of bad defaults strikes again (daily).
After the realization that this is a weird default you don't train yourself for 15 years, but change it to your comfortable/common keybinds!
I wonder what terminal that is, because the Home and End keys, which I'm pretty sure are the expected alternatives, work fine in every terminal for me on Linux.
For the complaint to make any sense in the first place there needs to be an expected alternative way to go back to the beginning and end of a line. Otherwise it would be "it took me maybe 15 years to get used to being able to go to the beginning or end of a line in one keystroke". The two such options I'm aware of are Home/End (on macbooks I believe that is Fn+arrow keys) and Ctrl-a/Ctrl-e.
What alternative key combinations do you expect to work for the purpose?
It's usually the weight of my whole hand. I touch type, but my hands are usually tilted to the exterior. So I hit keys like Enter, Capslock, Shift, with the side instead of the tip of my fingers. And I don't mind sliding my whole hands if I'm going to use it repeatedly.
Side vs tip doesn't come close to tipping the balance
And the last part is backwards - you don't need to use it repeatedly, there are much better alternatives, so you could just as well not mind not doing it
Also worth mention the Plan 9 "fixed prompt" where any command is at the top, with it's output underneath, there are few variants and in few cases they are comfy.
Another neat trick is to use ctrl-x ctrl-e, this gets the command in a vim buffer (default editor for me). Edit the command and then :wq to reflect the changes
Give me arrows, tab, Ctrl+(R/C/D/W) etc and its a great.
But I agree with the point that different systems have their own implementation which could lead to frustration.
I am working on set of servers only accessible through PAM and those admins don't allow anything. It gets so frustrating.
I feel a lot of the frustration also comes from shifting to unfamiliar environment. Like I work on those restricted servers and am cursing the admins, but when I switch to Ubuntu's terminal I am thanking the gods for liberation.
Periodic reminder that many emacs-like keybindings exist in almost every text field in macOS: Ctrl A, E, P, N, K, Y, T, and probably others I'm forgetting (start of line, end of line, previous line, next line, kill (delete everything to the end of the line and put it in a special pasteboard), yank (paste from that special pasteboard) and transpose characters).
"The other day I asked what folks on Mastodon find confusing about working in the terminal, and one thing that stood out to me was "editing a command you already typed in".
This really resonated with me: even though entering some text and editing it is a very "basic" task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)."
Only took me a year or so to get used to using "v" in vi mode and fc. I am not a "developer" but I prefer textmode command line to GUI. I do not use X11/Wayland/etc.
I learned sh on NetBSD which I still think is one of the best shells available. It's fast. vi mode is the default. People may disagree but I think for editing single a line of text, i.e., a "command", vi mode offers more precision. For example, being able to jump directly to a particular column number.
It's been mentioned here before, but you should suggest the Ctrl + X, Ctrl + E combo - they can edit the command in their favourite text editor and then it gets executed when they exit the editor.
going to a particular column number is not useful to me because my commands are not on punched cards with column numbers printed on them. going to a particular piece of text is, and ^r or ^s gets me there with readline (in vi mode or emacs mode). i don't want to mentally count how many characters are on the line before the place i want to go; i have a computer to do that for me
vi movement by words is useful though, and slightly easier than emacs alt-f and alt-b
I think the lowest hanging fruit would be doing something (anything) to improve discovery of commands. I have great grokking abilities but terrible memorization skills, and I end up forgetting how to do what I want to do and maybe even have done before. Browsing man pages for every command is my bane. It's also why I dislike GUI with unlabelled icons, I never remember what each one does.
Maybe try fish? Tab completion will suggest subcommands, and if you type - or -- and hit tab, it will suggest the available options with help text generated from man pages (example: https://flaviocopes.com/images/fish-shell/autocomplete.png). Doesn't really help with positional arguments but it's definitely enhanced the discoverability of many tools for me.
At this point Google has basically taken over that function... "How do I _ on the command line?" more often than not gives one some starting point to develop from.
GPT is great at this. I wrote a little program that I can call from a shell. Bashai.py show me a bash one liner that does x. It then shows me the command and asks if I want to run it with or without root. Simple, yet one of the best tools I've ever made for myself.
> It took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end).
That looks like some cognitive problem or ADHD. (Obviously, completely unrelated to intellect.)
> some programs (cat, nc, git commit --, etc) don’t support using arrow keys at all: if you press arrow keys, you’ll just see ^[[D^[[D^[[C^[[C^
I've long argued that the readline-like functionality should be in the kernel. The POSIX line discipline should be replaced or augmented with full blown editing with history recall.
Imagine rlwrap, but always there, all the time, in the TTY driver.
There are downsides, because history wants to be contextual and persistent. The kernel knows what process is making the read() call on the TTY, though, so that could be somehow arranged. Certain new security issues come up also.
> it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)
Ctrl+LeftArrow and Ctrl+RightArrow also work with every readline-compatible shell and they are much more intuitive, especially if you are not used to terminal text editors.
> it’s very inconsistent between programs
Readline or emulations thereof are pretty common and the de-facto standard. But of course programs can do their own thing if they want to - it's not like GUI text eidtors all have consistent shortcuts.
cat / nc / etc. are not editors at all and therefore don't provide those shortcuts. They take an input stream and forward it.
The vi vs emacs thing permeates a lot of tools.
I find it useful to map all tools to be consistent with one or the other.
Personally I use vi. Unfortunately setting vi mode for readline has a few caveats, but I was able to work around all of them with the settings in:
I switched my Mac terminal to Warp.dev simply for the default mac text input. I can ⌥ and ⌘ left and right to select words or until the end of the line ⌘A to select all. It comes with so many other bells and whistles that I've mostly ignored for this simple convenience. I don't use emacs (or vim) keybindings in any other context and I'm not sure why the terminal forces you to.
I've never seen dash dump escape sequences instead of acting on arrow keys. Probably, it's due to a missing or wrong TERM value?
Nowadays, programs should be hard-coded to accept ANSI sequences and ignore TERM (unless they need to make some fine-grained distinction like do we have 256 color xterm compatibility).
Those programs will never have that problem of not understanding arrow keys.
it's more likely because she's running a version of dash compiled without readline support, probably debian's version (which is compiled that way because it's not intended as an interactive shell, but rather the lightest-weight posix-compliant shell they could build)
i agree about ansi sequences. even that doesn't go far enough, though: we should probably be moving past character-cell terminals to something better so we can have things like proportional fonts, multiple font sizes, properly spaced borders, and rounded corners
Looks like I'm wrong. If I fire up an interactive dash on Ubuntu or Debian, no arrow keys. /bin/sh is dash, but that's only for hash bang scripts.
Not just no arrow keys, but nothing. No Ctrl-P to recall previous line. No editing beyond the POSIX TTY line discipline stuff: Ctrl-W word erase, Ctrl-U line erase, backspace.
also i'm wrong; it doesn't have an option to compile with readline, just libedit (which indeed is not included in the debian package configuration). the incantation was as follows:
on the other hand my dash process with libedit is 1.3 megs rss while my bash process is 7 megs rss. and the dash executable is only 130k. still, bash is only about 20% slower to start up
A meta-question for those of us very comfortable composing complex sequences on the command line: when I’m trying to help someone with something, how can I avoid becoming frustrated by their lack of facility - or worse, their lack of interest in obtaining facility, without being an ass and taking over the keyboard? Grumble.
I use M-x shell and variants in Emacs for almost all of my command line work. No problems with editing, as it is always Emacs on top. For true ncurses apps there are some limitations inside vterm or ansi term but even there, I can still use elisp and fix these problems if needed.
> license reasons, if the program’s license is not GPL-compatible – readline is GPL-licensed, not LGPL
The older I get, the less patient I become with finding out some user experience sucks because of GPL / non-GPL knife fights.
It's been thirty-nine years now. I think the GPL was useful at its origin, but now the benefits of open-source are proven out, the world is deeply interconnected via the Internet, and it's a hindrance to have some code burden other code with requirements. I, for one, don't expect to write any further GPL code in my lifetime. I'd rather code be maximally unencumbered from interoperation.
No, the GPL license for GNU Readline is very intentional. There is a bunch of written history from Richard Stallman about it. He felt it provided such an large advantage, that some programs might switch to GPL to use GNU Readline. After 35 years of development (started in 1989 according to Wiki), it has a hefty start is someone wants to beat it with a "clean room" BSD-licensed edition.
I cannot find any specific writing from him, but I am sure I read words from him about 25 years ago.
> I'd rather code be maximally unencumbered from interoperation.
Yes, the problem is that commercial organizations would like open source to do all the hard work for them. Then, they use the software internally, and don't give anything back -- except two pence via RedHat licensing. (We have learned this the hard way in the last 10 years of major security bugs due to underfunded projects.) However, you are free to re-implement the API and license it in a different way.
Yes, I think we are in agreement. The GPL in this era is a wrench in the process of useful code. You have brought to my attention how intentional that was.
Rms did something impressive but he doesn't impress me in this day and age. Many revolutionaries make for poor governors; in my personal opinion the software ecosystem would be best served by cutting around him these days.
@shadowgovt Genuine question: if i wanted to create new software nowadays, and i wished for it to be as you noted "mmaximally unencumbered from interoperation", which license should i choose for my software? Which license would you use? Again, not trying to be snarky; just wanting to learn and understand. :-)
I generally use the ISC license these days. It is short, indemnifies me from damage caused by the software I write being used by other people, has a thin requirement that the copyright be carried forward into other projects using my code (A requirement that I'm probably not going to enforce), And that's it. No encumbrances against interoperation with other people's code.
I've been using terminal for +15 years, and I just learned what this is. Because you highlighted it being crazy that someone didn't know what it was, I looked it up.
Neat! Thanks for teaching me something today. This will be helpful, especially after I spent all morning messing with crontabs and logs and permissions and PATH env's.
Edit: Having read more about this now, I'm realizing that I do use a couple of these out of habit. I just didn't know they were called "readline commands". I thought they were just "how to use the terminal". But there's dozens and dozens of other commands I never knew were possible. Brilliant. Happy Monday.
> This really resonated with me: even though entering some text and editing it is a very “basic” task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end).
I think your take is a bit harsh. She is quite a popular writer, and day after day, lays out her ego out for a beating by the InterWebs each time that she posts. She is never afraid to be humble. That is part of the genius of her posts. She says what so many are afraid to say publicly -- "oh this 'simple' thing is very complex" or vice versa.
I've also been using Linux and the terminal ~15 years, and these things i keep forgetting and relearning every now and then. About Ctrl+A in particular, it never sticks in my memory, since i find typing the Home key to be more intuitive. Maybe the author has this same "problem".
It's funny how other programs don't seem to have this issue, and their users are able to learn new things without having to resort to an external manual. Makes one wonder about the design of everyday things!
Yeah, I have my doubts about the claim. I forgot what I read way back when as an intro book, but I suspect it was more like a month in my case, if that. But I remember having been surprised at various points that there was an undo (C-_), and a clipboard (C-y to paste) including a history (M-y). So yeah, I guess it depends on the scope.
Maybe it's a hyperbole? Dunno, doesn't really read that way.
How can you discover something on the terminal itself? You fall into a pattern and stick with it. It is only if you get out of band information that you can learn these tricks.
Bit confused by this comment. I don't think anybody suggested you're going to find these things solely by interacting with the terminal - but rather through "out of band information" as you put it, which in GP's case, as he said, was a book. The surprising part of TFA, and replies to my comment - to me anyway - is how one can go so many years without picking up that information.
I have never read a book about improving my terminal knowledge. I have a few tricks I have picked up over time (probably through posts like this!), but never done holistic research on the subject. Therefore, despite having used the terminal for decades, I likely have a similarly long list of basic terminal knowledge gaps. I do not know what I do not know.
I have to agree with the other commenter (drewg123). Been a Vim user for decades but don't use Vi-mode in the terminal.
> the problem she describes is a non-issue. And I am not a pro.
Not sure what you're saying here. Julia didn't describe a problem but a preference ("I didn’t really like using it"). I'm not sure how you can you call someone's preference a non-issue. It's a preference and we're allowed to have those last I checked! :p
"even though entering some text and editing it is a very “basic” task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)."
This sounded to me like she was describing a problem. My bad.
I felt Julia was describing a problem that she was having for 15 years to do with editing on the CLI. Then she said "even though I’m a vim user I didn’t really like using it when I tried it."
To me, even still, it seems weird that there is a tool (vi-mode) that solves the problem she seemed to be describing earlier on. I am not denying that she "didn’t really like using it when I tried it".
Not sure that even with this reply I have cleared up my earlier confusion-causing comment. I shall endeavour to refrain from further nonsense in the future.
I don't find that strange at all (prefering emacs to vi mode). I feel the same way.
I use tcsh, and have it configured for emacs-style command line editing. I use emacs for complex stuff (coding) and vi for simple stuff (editing a config file), so I'm comfy with both.
I think my issue is that it seems slightly unnatural to remember the mode I'm in on a random terminal command line, and much easier to just use the emacs keys to edit when needed.
This is nice. As always, Julia's articles are always a win.
Here's some stuff that's missing:
Within shell scripts, you can use `stty` to change a lot of stuff about the terminal, including how it deals with inputs. You can rewire all of these defaults and behaviors.
Here's an experiment I did a while ago using sh and stty: https://gist.github.com/alganet/63f1dbc97b8fd35f7bb14ec30f79...
It is able to capture and understand most keyboard combinations and even mouse gestures (hold/drag/drop) from within the shell in any VT100-compatible terminal (mintty, xterm, Terminal.app, vscode, so many others).
Runnable demo:
Run it and press some keys or move the mouse. Use Ctrl+W to exit. It supports zsh and ksh too, but not dash or other shells lacking `read -rn1`.---
Here's another funny thing:
If you pipe an interactive program to `cat -v`, you can see which VT100 escapes that program is using. I learned a lot from how vi does it.Here's a bonus:
Ever ran a command that left your terminal mangled after it finished? No output, weird chars, etc.
That's lack of proper tty hygiene on the offending command. Instead of killing your terminal, type:
And you'll demangle it.I think the command “reset” does something similar
You are correct! I think it does a little more (restoring cursor if hidden, etc). If you have it, it is probably better than `stty sane`
Any idea what can cause the cursor to suddenly dissappear? It's the only issue I currently have with wezterm, an otherwise fantastic terminal emulator
Many, many interactive programs.
Programs that draw a progressbar often hide the cursor so there won't be a blinking cursor "glitching" the visuals. Once you see it, you'll start noticing programs that hide the cursor.
If it happens only on wezterm, it is probably some kind of bug on their part (no support for the escape code that re-enables the cursor maybe?). Have you tried other terminals?
Or `tput reset` to skip the one-second wait intended for hardware terminals.
Thanks!
In maybe similar spirit, another screwy way to explore terminal IO mechanics I came up with when reading the start of Kernighan's UNIX Programming Environment:
Open up three terminal windows:
With the #3 terminal active, try reproducing the whole "Hex" column of the manpage, in order. And, observing that some values have multiple ways to produce them, and also observing the multi-byte payloads of some of the other keys.I'm not going to pretend to grasp through and through what exactly I'm accomplishing with this but will happily read any commentary.
> you can use `stty` to change a lot of stuff about the terminal, including how it deals with inputs
> You can rewire all of these defaults and behaviors
I've also found this article on implementing a terminal text editor to be illuminating:
https://viewsourcecode.org/snaptoken/kilo/
https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
Also, just in case anyone is wondering, as I once did, where many of these magical-looking stty parameters and symbols are coming from: they are control sequences defined a long time ago. A lot of stuff is defined in ambiguous old standards from the 70s such as ECMA-48 that include such arcane terminology not seen anywhere else.
For example, jargon like Select Graphic Rendition basically refers to a 70s version of the HTML <font> tag.
Where params are something like 38/2 RGB to set foreground color. The parameter 0 clears the current style. Parameters come before the command. Kind of backwards.They even had the same implementation issues we have today with browsers. Terminals were and stil are inconsistent in what they implemented and how they did it. Stuff like colors is pretty well supported but many other features aren't. For example, SGR<7> is supposed to enable "negative image" mode, whatever that is. Standard doesn't really explain. Some terminals choose to do reverse video, other terminals do other equally valid things and to this day people have problems with it.
I like your comparison with browsers. In many ways, the only way to know for sure is to test in the desired terminals and figure out what works on all of them.
There's some "new" stuff as well (90's), like SIXEL graphics. I was surprised by how broad the support is (however not that broad to count on it).
Yeah. Even more recent efforts are the efforts to bring powerful features to terminals. Kitty in particular came up with many of them and had to deal with ncurses refusing to support it.
friendly reminder to always check before you slurp code directly to bash from the internet. this may have broke my (admittedly totally non standard) configuration in weird ways I didn't care to document.
On Sonoma I get:
I don't have a mac here, but you might try replacing `bash` with `zsh` to see if zsh fares better. Sonoma should have it by default.
If I remember correctly, macos bash (3.2) is 19 years old. I don't think I tested it with that version back then.
Over 20 years ago now I wrote a state machine around readline that meant you could use it as a multi-line editor. Not "multi-line" as in a single line can wrap, but a true editor that lets you move up and down, but is windowless.
Here's a video:
and the CVS repository for the Unix terminal IM client it is part of is at: It tracks and redraws your cursor when you move up and down between lines, and also pays attention to SIGWINCH to redraw things when the terminal size changes. I've never had the time to rewrite it in Rust, but I'd like to and then release it as a small library.It's always surprised me that nobody else has done this.
That's pretty cool, gonna steal the idea.
I can implement that specific case with a couple of lines in zsh. Something like:
Then icommit, via zed¹, will initiate an inline editor with all the power of ZLE available. Hit C-x C-w to write and commit, or C-c to abort. Obviously, you'd want some error checking and the like².Beauty of this basic implementation is that the keymap is fully controllable in zed as it is simply a new ZLE widget. It works with emacs or vi mode out of the box, and is fully customisable beyond that.
You could make the interface generic by writing your own ZLE widget, so that it can be called directly from within the line editor and remove the need for wrapping commands like I did above.
¹ https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
² This at least uses, and cleans up, a temp file to handle the commit message so it isn't completely useless.
This was fascinating!! Please do consider bringing it back to life as a library and sharing with HN.
I had no idea how much better such an editing experience is until your video, and completely agree about the benefit of not having to context-switch a la git commit "interactive mode". The "inline typewriter" effect is also really cool
Oh, that looks really cool! Is the current iteration of the program stable?
Yeah. That's how rio's text windows [0] look like in hold mode, except that it has a much simpler design and better support of mouse.
[0] https://p9f.org/magic/man2html/1/rio
Checked out the video. Looks cool!
Thanks for the screencast. Another +1 for bringing it back to life!
> some things this post left out
+ wide characters
+ different keyboard modes causing the same key press to be presented by different ANSI escape sequences
+ different TTY states (eg local echo)
+ different OSs having subtly different syscalls for changing TTY states
+ differing support for terminal emulation (most these days roughly emulate xterm, but even there, none aim for 100% be compatibility)
+ a lack of a consensus on how to check for features provided by a terminal (some use ANSI escape sequences and wait for an ansi sequence to be returned from the term (that’s how the old VTs worked), some check $TERM (that’s how the first wave of terminal emulation was detected), some terms expose themselves as xterm and ignore the VT feature sequences, but set other env vars. it’s honestly a bigger mess than the user-agent string.
…and this is assuming a POSIX system. Things get doubly interesting when you throw Windows into the mix
In bash, if you set $EDITOR to your favorite text editor, you can send the current line to $EDITOR with ctrl-x ctrl-e. After editing the command you can save and exit for the command to execute.
You can also just press 'v' if you're using vi mode in ksh like hardened old unixbeards like me :}
fc builtin does the same thing. No ctrl-key sequences required.
Just type "fc"
With previous commands, one can also specify a particular editor instead of default $EDITOR
For example, to edit the previous command with ed when EDITOR=vi
A quick way to make shell scripts from command line history in vi mode (where 15th entry in history is the desired command line):And for the fish folk, it's Alt-e
I love these shortcuts but sadly I never remember them when I do need them
I use this with copilot.vim in Neovim and EDITOR=nvim to get AI shell autocomplete. It's pretty good!
Got it from here https://twitter.com/arjie/status/1575201117595926530?s=46&t=...
Or even just bind it to ctrl-e in bash:
bind '\C-e: edit-and-execute-command'
that sounds horrific. every time you tried to go to the end of the line you'd get interrupted by launching an editor!
I always just use the home and end buttons for that kind of thing.
i don't even know where they are without looking at the keyboard. then when i try to press them half the time i accidentally press insert or print-screen instead
When I have this problem I remap the key I needed to a location that does work for me.
now you have two problems
I have `set -o vi` so, `esc` and `$` takes me to the end of the line. `ctrl-e` is unused for me unless I bind it to something I think is useful.
> First, there’s “the baseline” – what happens if a program just accepts text by calling fgets() or whatever and doing absolutely nothing else to provide a nicer experience.
[...] there are actually a few features that you get for free just from your terminal, without the program needing to do anything special at all.
The things you get for free are: [...]
- backspace
- Ctrl+W, to delete the previous word
- Ctrl+U, to delete the whole line
Linux noob here, so this may be a stupid question, but how does that work under the hood?
The documentation for fgets() says [1]:
> Reads at most count - 1 characters from the given file stream and stores them in the character array pointed to by str. Parsing stops if a newline character is found (in which case str will contain that newline character) or if end-of-file occurs.
Does that mean that, by default, fgets() blocks until the user enters a newline and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?
But there seems to be no guarantee that a program is using fgets() to read an entire line - it could also set count to 2 and read individual characters. Those could not be "unread" anymore when a backspace occurs. Is there some magic that lets fgets() buffer characters internally in such a situation, or would the backspace/line editing functionality just be broken then?
[1] https://en.cppreference.com/w/c/io/fgets
Programs like zsh, bash, ksh, fish and most TUIs put the terminal into cooked mode so that they can manage the terminals behavior manually. In cooked mode, the terminal is not new line buffered and instead every character is read. The terminal only appears to be new line buffered but is actually being managed by the shell, which then in turn allows the devs to add nice features like manipulating the text buffer to do tab completion or prepend the line with sudo.
*raw
Cooked is when the kernel handles it (cooking it before it gets to your program)
Thanks, that's a good way to remember that.
> Does that mean that, by default, fgets() blocks until the user enters a newline
Yes. By default, terminals operate in canonical mode. I/O does not happen at all until the user inputs a full line. Until the user hits Enter, the characters on the screen are just sitting there in the terminal's memory while the application's read system call is blocking on the terminal's file descriptor. The terminal does not write the data until the line is complete.
> and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?
Provided that "it" refers to the terminal, then yes. Normally it's the terminal itself which allows you to edit the line you are typing on. This is also provided by the default canonical mode. Even the fact that letters show up on the line when you type is a terminal feature called echoing. So are things like backspace, delete, Ctrl+C for SIGINT, Ctrl+D for EOF.
Line and text editors just turn off all of this stuff. They place the terminal in raw mode where everything you type is sent immediately to the application where it is handled immediately. A wide variety of everyday programs do stuff like this. For example, password prompts simply turn off echoing to hide the characters.
Even the traditional Unix line ending \n is actually a feature of terminals. To the terminal, \n just moves the cursor down one line, \r is also needed to go back to the beginning of the line. The true line ending is therefore \r\n. The terminal just happens to invisibly turn \n into \r\n. This too can be disabled.
> The terminal just happens to invisibly turn \n into \r\n.
No, it was actually done by the Unixen itself, in the part of the kernel that handled ttys: it convert '\n' to '\r\n' on writes to ttys, and '\r' to '\n' on reads from ttys. Linux only recently have moved this functionality out into the user-land layer.
> in the part of the kernel that handled ttys
Yes, that's what I meant.
That gets set in a termios structure that gets passed to the kernel's terminal subsystem via ioctl.https://github.com/torvalds/linux/blob/master/include/uapi/a...
https://github.com/torvalds/linux/blob/master/include/uapi/a...
https://github.com/torvalds/linux/blob/master/include/uapi/a...
https://github.com/torvalds/linux/blob/master/include/uapi/a...
> Linux only recently have moved this functionality out into the user-land layer.
That's certainly news to me. Numerous functions in this file allude to OPOST processing:
https://github.com/torvalds/linux/blob/master/drivers/tty/n_...
If it's not here, where did it move to?
Hmmm, I could swear I have read about moving line discipline out of the kernel in some LWN article but apparently no, it never happened (although it probably should've, there is no much reason to perform mapping of NL to CR-NL in the privilleged mode). Maybe I've confused it with what happened on the Windows side of things? They moved almost all of the console infrastructure out of the kernel recently and into the user space, and that definitely has happened.
I suspect Linux actually can't move it to user space. It would break binary compatibility with all user space code that sets OPOST via the ioctl. They can't hide it in a libc either.
It's provided by the terminal (emulator) in "cooked" mode: https://en.wikipedia.org/wiki/Terminal_mode
raw mode doesn't do this.
To be clear, it's not the terminal emulator (xterm, mintty, iTerm2, etc.) that does this. It's the tty layer. You can use the stty command to change the settings.
Yes, quite right. I was thinking of the terminal driver and typed emulator for some reason. Good catch.
Ah, that's exactly the answer and makes a lot of sense. Thanks a lot.
One of the first challenges I faced as someone who got paid to program: port the VMS "help" program to SunOS (a *nix). Initial challenge: how to respond to each keystroke rather than wait for enter/return. My boss was intentionally unhelpful and forced me to figure it out more or less all by myself (remember: no web, and hardly any O'Reilly books in 1986). I remain eternally grateful for his judgement to this day.
> some programs (the dash shell, cat, nc, git commit --interactive, etc) don’t support using arrow keys at all.
The dash shell does in fact support an editing mode if compiled with libedit. Debian derivatives do not do so (likely for concerns of space). They very much should, as people who start with bash will have much to unlearn.
The POSIX standard also specifies "set -o vi" as an optional extension. Every shell claiming POSIX-compatibility must support set -o vi if the shell implements this editing mode (so ignore inputrc if it pleases you).
"[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."
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
> They very much should, as people who start with bash will have much to unlearn.
Dash on Debian is intended as a light POSIX sh to execute shell scripts. It isn't meant to be your login shell or for interactive use. It makes sense to keep the dependencies light in that context.
Bash can do a lot of damage to somebody who ends up needing to write POSIX shell scripts for dash.
I very much disagree that dash should be prepared without something that POSIX specifically mentions. This is bad from several perspectives.
I have continually contented that the terminal is the single thing eternally condemning Linux to <5% market penetration.
It's not just entering text. The entire experience is complicated. It's a Concorde jet cockpit[1] (with no labels too), when 95% of the population just wants to fly their drone around[2].
[1]https://qph.cf2.quoracdn.net/main-qimg-2566f4c91b894e4169d77... [2]https://media.thedroningcompany.com/images/tincy/WQZpC56vqMp...
If the only Linux distributions were in the style of LFS, Gentoo and Arch* you would have a point, but as long as Ubuntu, Mint, OpenSUSE, Fedora, Manjaro and the myriad other user-friendly exist I fail to see the argument.
Yes, Ubuntu has a Concorde cockpit behind the scenes and yes, I can access it on my Ubuntu work* laptop and I am grateful that I have that choice. I would hate not having that level of control.
Meanwhile, my mother's laptop is also Ubuntu and my girlfriend's is Manjaro, and they are both perfectly happy "flying their drones around" without ever setting foot in the Concorde cockpit.
(*) I use Arch btw
I have used ubuntu for 2 years now, and its the motivation for the post.
Ubuntu (or really any distro I am aware of) is great for pensioners (email readers) and power users (career linux user), with a protracted and hellishly complicated experience in between (technologically adept, but lifelong windows user).
True, if you just want to fly straight to one of the most popular cities, you can just enter it in the autopilot and it will go there. But if you want to go anywhere or do anything else, you better be good a googling and understanding "how to fly a Concorde".
A better way is to get a book about linux administration (if you want an in-depth manual) or "How Linux Works" by Brian Ward. Then learn bash.
Windows is pretty much all GUI (I've left before getting used to Powershell) and that works great until you want to do rules-based changes or do profiles (without using MDM) with changes snapshot.
Most software have good manuals so once you've got a bit used to the linux's way, it's quite easy to adjust anything you need. And after a while, you find you're mostly using a few handful packages and you'd have their configuration saved in your dotfiles. As for packages suggestions, that's what distros are there for.
Linux is all about reading.
Trust me, I understand that Linux is all about reading.
I also understand that it is perpetually irrelevant in the consumer computer space, despite everyone in that space absolutely hating the dominate OS. A hate that you can watch grow in virtually real time on any social platform. But that hate is focused on pushing the giant back in-line, not at abandoning that giant for fresh pastures. You know why?
Because 30 years ago, someone who touched grass realized that consumers cannot, let me repeat: cannot, use an OS that is "all about reading".
Most consumers want appliances, aka a collection of software pre configured with a few customization options. When the current solutions (ipad, phone, MacBook, PC) fit, it’s great. And the current linux desktop distros are doing great in that regard, except on two points. They do not come pre-installed (with hardware support) and some software don’t support linux.
But as soon as you want something custom and do your own configuration, the manuals are required. Or you get someone to do it for you.
Truth, but!
The middle hellish experience being described here is not a bad thing.
Fact is, Ubuntu used as autopilot is pretty great! It is way better than it used to be. Mere mortals can jump on a computer and often get the few things they want done.
What I do with users of that type, and myself depending on my moods and motivations for a particular machine, is treat it like Android.
Find the users an app they can click on and or tell them it is not going to happen.
Many will be happy with that.
The ones who are not need help.
Either they grow and become readers, and can pilot the computer properly, or they won't and helping them makes as much sense as their own efforts do.
> technologically adept, but lifelong windows user
Windows power users are also the ones who rant about the lack of video games in the ecosystem. They already have their happy place, and are not a worthwhile target for recruitment.
Some of them are. Namely the ones willing to have an open mind and learn new things. Games in particular are not a problem unless you are set on playing modern online games which require draconian kernel-level DRM.
> technologically adept, but lifelong windows user
This kind of user is going to have a bad experience with anything that isn't exactly Windows unless they are willing to adapt. The problem isn't that the way Linux does things is bad, it is that it's different from what you are used to. I guarantee that as someone who is at home under Linux dealing with anything on Windows feels just as bad for me as Linux does for you.
Linux the kernel + some userland without terminal is used by majority of people in the form of Android and Chromebooks.
A terminal is a developer and sysadmin tool. It just so happens that most users of desktop GNU/Linux are developers and sysadmins. They are a few percent of population.
>Linux the kernel + some userland without terminal is used by majority of people in the form of Android and Chromebooks.
Exactly, so why hasn't the open source community driving free distros taken note of this?
Now more than ever, people want out of Windows, but the only they step into the seat of exit craft and see the above cockpit.
> free distros taken note of this?
Gnome tries hard to emulate Apple's approach. Results are mixed, but I've seen fans of it.
Elementary OS goes in the "normal users" direction, too.
OTOH if something goes badly wrong, and you do need to open the hood and follow an arcane tech support recipe, you open a command line, be it Linux. macOS, or Windows. (Not Android or iOS though, where you do a reset + restore dance.)
> people want out of Windows
Yes, here's where they meet Steam Deck, that did take note, and just puts you into a cared-for gaming environment. It can also run a typical desktop. The hardware is proprietary, but the software is (mostly / completely?) free.
> Yes, here's where they meet Steam Deck, that did take note, and just puts you into a cared-for gaming environment. It can also run a typical desktop. The hardware is proprietary, but the software is (mostly / completely?) free.
The SteamDeck hardware is about as proprietary as any other x86 PC. It's not open source HW but it's also not really all that custom for the most part.
> you open a command line
Except Classic Mac OS never had this. You'd sometimes need to do arcane rituals like "re-bless the system folder", but they were entirely GUI-based arcane rituals that involved double-clicking icons, opening and closing windows, and dragging files in and out of folders.
> Except Classic Mac OS never had this.
Text interfaces: streams of discrete objects (characters) with some having special purposes
GUI: A matrix of pixels + a set of of rectangles with special properties attached.
If you want to quickly write a program, text is the way to go. Most developers are scratching their own itch and already know the system. They may surface a few GUI settings (if it's GUI), but no one wants to build a complete GUI ecosystem on top of Linux (unless you go fo a restricted version like ChromeOS or Android).
And with scripts, you can quickly write your own software by using existing ones. It can be your very special computing world.
There was no other, simpler interface. And the whole system was much simpler (and less capable). The graphical hardware was way simpler and fully in-house, unlike the current GPUs that are third-party and evolve quickly.
Exactly, there was no other, complicated interface. Except in 1991-1995 when System 6 was going to merge with AIX and be A/UX and Apple was going to merge with IBM and it was all briefly very weird.
I must be doing something wrong because I can just use Home to go to the beginning of the line and End to go to the end and I am pretty sure all the things that are easy to type as just as easy to type be in Gnome Terminal on Ubuntu or Windows Terminal on Windows.
The only place I need to know a bunch of weird shortcuts to figure things out is in the macOS terminal where everything is the less intuitive as possible.
What's condemning Linux to negligible market share is lack of preinstalls. Virtually no one used Windows, either, until Microsoft did everything short of coercing OEMs to bundle and preinstall it during the 3.x era.
However, GNU/Linux's better terminal experience compared to Unix could be part of the reason why it wiped the floor with Unix.
When you log into a BSD box, it's like taking a time machine back to the 1980s.
95% of the population doesn't need to use the terminal.
If you love cars, popping the hood is probably part of the experience. For everyone else, it’s the sign of a very frustrating day ahead.
As computer lovers, I feel we must endeavour to remain mindful that almost everyone else aren’t like us. They’re trying to get a task done. They don’t want to maintain or talk with the computer.
> As computer lovers, I feel we must endeavour to remain mindful that almost everyone else aren’t like us. They’re trying to get a task done. They don’t want to maintain or talk with the computer.
This was pretty much my point. 95% of the population isn't like us, and don't need to interact with the terminal; thus, thinking the terminal is what's keeping Linux back doesn't make much sense to me
The larger issue is the times that the Linux UX goes off the rails and the solution turns out to be "You're going to have to bleat this esoteric incantation at the command line." I plugged my laptop into a second monitor the other day and, oops, for whatever Godforsaken reason it didn't auto-detect. Suddenly I'm munging around in `xrandr` to get my screens to work.
To its credit, all the major desktop distributions today are making real inroads to narrowing the scope of situations where that happens. This was a much larger concern in the past, where key aspects of the user experience were still in the category "There was a command-line tool written to control it and that's all you'll ever need, dammit."
The alternative is "it just won't work". You too can live in that world by simply not trying to fix it.
My wife's Macbook won't suspend correctly when it's plugged into a Dell monitor, the monitor going into power save wakes up the laptop. I wish there was an arcane incantation that would fix it, but no, the proprietary walled garden is well locked up, with glossy user-friendly rounded corners everywhere.
This is the most insightful post in the thread -- there's definitely a false dichotomy here. It's not "have to use a terminal" vs "everything works without a need for a terminal ever" -- it's "able to use a terminal to accomplish some goal or recover from Really Bad Thing" vs "Can't Do That Thing / have to factory restore to recover".
Like the way Apple Maps on my iPhone can't save the person to notify when I navigate to Home. I can save a person to be notified to any arbitrary location besides Home. With Home though, the setting simply doesn't save. I'm sure if I had a terminal I could inspect the data involved and manually fix what's wrong, but the 'Apple' or GUI-only approach simply makes that out of the question. Even better, when the corrupted data is cloud-resident I think the answer is often just that it's broken permanently unless you want to create a brand new account.
There are millions of computers out there that just don't work right, or where people can't accomplish some goal they wish they could. That's the flip side of the 'terminal or not' coin. Neither is a good experience for users who aren't technical though. For nerds though the Terminal provides a great deal.
I think my main gripe though is that there simply isn't enough drive to move things out of the terminal and into a GUI.
I really think that a core problem is that once you are in a position where you are contributing to distros, contributing to the kernal, you are well versed and acquainted with the terminal, and you love it's incredible power and efficiency. The cockpit is no longer a sci-fi meme, it's a meticulous masterpiece granting a god-like computing interface. Nobody at that level is interested in much GUI-ification, because, holy shit, this CLI is the best! (Never mind that software engineering is dominated by "complexity and control" types vs "simplicity and automatic" types of the wider population.)
In general, Apple would solve that problem by recommending you plug an Apple computer into an Apple monitor.
The Apple ecosystem is well incentivized to make all of their pieces work with their other pieces. The Windows ecosystem is pretty decently incentivized to make things work together in general (In both directions... Windows suffers in sales if there's some popular hardware it won't work with, and popular hardware suffers in sales if it doesn't work with Windows).
One certainly does run into the occasional Dell monitor with Apple laptop problem that you then need a couple of insider specialists to address. But I've not really been sold on the notion that The open ecosystem is strictly superior in that sense... In theory it is, in practice you can't be an expert at everything and there's no guarantee anyone's going to come along and care about how to fix your particular Dell / Linux distro configuration.
How does the monitor thing relate to what I was saying? In my case, I'm saying that Apple's tightly-coupled, app-OS-cloud integration means I have no ability to see what's wrong (and I'm positive the minimum wage phone support guys will not be able to escalate a bug like that to Engineering and get it fixed). My point was even first-party walled garden stuff doesn't work right, and having no access beneath the GUI rules out anyone outside being able to fix it. I get your point though that the 'right person' who could use that access to more obscure things may be rare anyways.
Sorry if I was vague! I was commenting in complete agreement with you.
> They’re trying to get a task done. They don’t want to maintain or talk with the computer.
Computers are complex things. Sometimes, things broke and you just can't do the task. But for a knowledgeable person, you just "pop the hood", fix the problem, and then get things done. On My iPad when the Files app freeze, there's nothing to be done other than reboot to get it working again. On Linux, I could pkill a software, restart it in debug mode or go find the logs to know what's wrong. Yes, there's a difference of mindset. But I prefer the "hood" to be there instead of having it be an opaque box.
If you want to get a task done, learn the software that can do it, externalize everything else (IT support). But sometimes, that software is the terminal or it's where the software is.
Doesn't Windows, the most popular OS out there, have a cmd.exe terminal thing? Why isn't that harming Windows?
The Windows Command Prompt's default experience is worse than most if not all terminals you find on Linux systems. Even in play TTY, you're bound to find that the shortcuts the author mentioned work like a charm.
To make my cmd.exe bearable I am using https://chrisant996.github.io/clink
tl;dr You're comparing the choice of wheels on a plane to what makes planes sell more.
> Doesn't Windows, the most popular OS out there, ...
The most popular desktop OS. It is nowhere to be found in the Top 500 supercomputers, is nowhere to be found on smartphones, lags in the Cloud, is nowhere to be found in the billions of appliances, etc.
> Why isn't that harming Windows?
It is harming Windows. That horrible cmd.exe is one of the reason Windows lost in all the other markets and has hardly any market share there.
> is nowhere to be found in the billions of appliances, etc.
It is unfortunately found in plenty of embedded systems. Usually not in cheap end-user appliances though where it is outpriced due to both the OS license as well as the hardware required.
Seriously.
Back in the 90's a lot of movie production was being done on the SGI IRIX computers. Jurassic Park themed ones even. Really spiffy machines with both an excellent GUI and terminal.
Cheap WIN NT boxes with nVidia GPUs on them, were seen as the beat path forward.
SGI gear is also Jurassic Park style, "Spare no expense" and was not cheap! Super expensive machines, but people got what they paid for too.
Alias, Maya were ported to Windows and off to the races right?
Nope. Unix scripting, that awesome terminal and friends made all the difference in the world.
This was true even for smaller or single person shops who would do the work in a now slower SGI because the user experience was bang on point and that meant getting the desired outcome first time no bullshit.
The minute we had nVidia drivers, Linux was in to replace the SGI machines.
And, the production community realized they could each write tools or poet tools they were good at, share and share alike (to a point) and all be in business a whole lot cheaper and faster.
That took a couple maybe few years.
The "terminal" and what can happen in one and why really does matter.
Windows Power Shell is pretty OK at this point, but it is still its own thing, not playing very nice with the other kids in the sane box.
Lol, I always thought Microsoft happening in Redmond was symbolic. It really is!
Windows has a new terminal as default that is pretty cool - I install MSYS2 and set it in the new Windows Terminal and it's all good. Gnome Terminal and other terminals on Linux are also pretty cool too.
If you want the worst default terminal experience just boot macOS.
Can you explain what's the big appeal of other terminal apps? I have been using Terminal for 21 years without any issue -- but I'm open to trying something else.
Actually I've only this year switched to an "AI enabled" terminal app called Warp.
I’m curious to know what your experience of changing to Warp has been like? Sounds like terminal was working fine for you - was the switch worth the time?
I signed up for the waitlist ages ago and finally got the announcement of Linux support in February but am still yet to try it. Mainly because I’ve had a particularly busy year and I can’t justify fiddling around with my stack just for fun. I have no appetite for the risk I may lose hours to fixing something that goes wrong.
On Warp: After adjusting a couple of minor settings, I found Warp to be worth it. In fact, I at first trialed it 'side by side,' meaning keeping Terminal.app and Warp both open -- and found myself going for the Warp window more often. So it was an easy call for me.
I chose to not use its custom prompt because I wanted things to be more 'stock' in the terminal and not to rely on an app external to the shell for the features -- the only really fancy prompt feature I have is git branch display, and that's already working fine with my existing zsh prompt.
So, anyway, I can vouch that it didn't try to make changes to my environment (other than that offering to override the prompt, which I think it does in a way that doesn't update your .zshrc/.bashrc file anyway).
And for what it does do, I think it's great. Having command outputs separated and in little scrolling panes, really great. And mouse-able, standard text field to edit commands in, also amazing. Say you have a long URL on the clipboard with a {object_id} variable in the middle. You can paste it in, and use the mouse to select "{object_id}" and replace it instead of using arrow keys etc. to manually delete and replace the variable. So with the above efficiency gains it is already pretty cool compared to any kind of terminal app I knew of.
The AI stuff has been great to have as well. It's really convenient to have free access, right in the terminal, to an LLM that I assume has been well prompted to produce shell or scripting code as requested.
One thing I turned off is their recent "Detect natural language automatically" feature. Before, if you wanted to invoke AI, you just did a #comment. So for instance "# docker command to remove exited containers" -- well, they updated it so that even without that "#" it should "just know" from inspecting the command. But I had a problem with it getting confused by a shell command that was also parseable as 2 English words. I think I prefer actually knowing whether I'm commanding a shell or operating an LLM, anyway.
BTW - it occurs to me that there are also big categories of features that it has which I don't even use, such as like, runbooks that can automate frequently-done tasks, things like that. Those may also factor into your decision.
I use MSYS2 too, can't stand WSL. Foe my terminal choice, I find wezterm to be awesome for my daily 3 OS use.
Essentially nothing in Windows requires cmd.exe. Having a terminal in a desktop OS isn't a problem. Needing one is.
Just like having a GUI isn't a problem for a server OS, but needing one is a problem.
Apple would disagree with you on both counts.
Plus for a long time desktop Windows needed cmd.exe to support login scripts.
Just as people use Linux daily without ever touching the command line. Eg Android, LG smart TVs (webOS), Satellite TV set top boxes (eg Sky Q), home routers, etc.
And if you want to focus on Linux running on laptops, then there are ChromeBooks and the old Asus EeePCs.
The reason desktop Linux isn’t polished is because every time a company invests heavily into desktop Linux, Microsoft undercuts them (like how they sold XP at a loss to thwart Linux in the netbook market). But the fact that Apple could take BSD, Google take Linux, and Nintendo also run BSD on some of their consoles, really speaks volumes about how there’s nothing technically stopping people running a POSIX platform like Linux and still hide the command line from regular users.
Though going back to my “Linux isn’t polished” point, I still think Linux+KDE is a lot more polished than modern Windows. But that’s just my biased opinion.
I agree about Linux + KDE being more polished.
For my main point, I suppose I should have specified GNU/Systemd/Linux as needing a CLI, not everything with a Linux kernel. POSIX-style kernel + libc is a very good basis for an OS, and such an OS doesn't need a CLI exposed to the user. It's all the Udev/Systemd/SysVInit & similar stuff that's CLI-only, and desktop Linux tends to require interacting with one or more of those on at least an occasional basis.
There are web based GUIs for systemd (and sysv init too).
But the main reason you don’t see GUIs for those services is because Desktop distros tend to abstract away systemd so you don’t even need to manage it, let alone have a GUI to do so.
Like with Windows, the average user wouldn’t be manually managing what services to start and stop.
And that’s the real crux of things. A lot of the stuff that people say you need a CLI for in Linux are operations that the average user wouldn’t know nor want to do on Windows even with a GUI. They just run a browser and if the machine goes slow they ask someone technical (friend or shop) to fix. I know this because I used to be that friend.
So I really don’t think the CLI is what holds back Linux. It’s just the economics was never there while Microsoft dominated the desktop world. And these days most people use phones and tablets as their general purpose device, so in a way Linux did eventually win anyway.
> Just as people use Linux daily without ever touching the command line. Eg Android, LG smart TVs (webOS), Satellite TV set top boxes (eg Sky Q), home routers, etc.
None of those are (used as) general purpose computers though.
Did you read my next paragraph where I acknowledged that point myself and gave some laptop examples too?
Plus I’d argue Android is the average persons general purpose computer. At least in terms of the people I know, they use their phones for 99% of things and actively avoid using a laptop as much as they can.
> Doesn't Windows, the most popular OS out there, have a cmd.exe terminal thing? Why isn't that harming Windows?
That's because the overwhelming majority of Windows usage, administration, and programming can be done almost entirely without ever touching the command-line, from Explorer.exe, Task Manager, Edge, Media Player, Paint, and built-in ZIP handling to the huge list of MMC snap-ins[1], and Visual Studio 2022.
> tl;dr You're comparing the choice of wheels on a plane to what makes planes sell more.
For the record, aeroplane cockpits have also gotten considerably simpler in the intervening half-century since Concorde and the first 747s. Here is an Airbus A350 cockpit[2].
[1]: https://serverfault.com/questions/158075/what-are-the-names-...
[2]: https://cdn.airplane-pictures.net/images/uploaded-images/201...
That does not match my experience, even if I also believed that myth.
At one time I had to install Windows Enterprise IoT on several kinds of embedded computers, all of which had various quirks.
The computers worked fine in Linux, from the first attempt to boot it, without the need to do anything special, but a customer wanted to have Windows on those.
After installing Windows, there have been a lot of problems, for instance Windows was unbelievably slow, because the SSD's had a very low writing speed, but they could not be replaced with decent SSD's, because the embedded computers were certified for certain applications only with their original components.
Making Windows usable on those computers has required a week of tuning and finding various workarounds by searching the Windows Knowledge Base and various Internet Forums, where many Windows users had the same complaints as me, but few were able to provide good advice about how to solve the problems.
I have been astonished to discover that for every workaround I was not able to find any way to do it in any graphic interface of Windows, but all workarounds required to use in a Cmd window some obscure Microsoft command-line utilities with a lot of magic command-line options, which I did not understand and I could not find in the official Windows Knowledge Base, but which were suggested as solutions on various Internet forums and indeed they worked as desired.
> For the record, aeroplane cockpits have also gotten considerably simpler in the intervening half-century since Concorde and the first 747s. Here is an Airbus A350 cockpit[2].
I mean, aesthetically it's simpler sure, but the complexity is still there; it's just now much more digital.
if you have a problem with gnu/linux (as opposed to android) you can usually find the solution on stack overflow, server fault, or superuser, but the solution you find there is going to be a textual command line, not a gui. gpt-4 can tell you how to solve the problem, but only using a textual command line, not a gui. text is the most powerful, useful, effective communication technology ever, period. always bet on text: https://graydon2.dreamwidth.org/193447.html
https://news.ycombinator.com/item?id=40909185 documents that this is actually also true for microsoft windows
on the other hand, 'always bet on text' doesn't mean 'always bet on editing your command line with inconsistent control-character commands in a mode where clicking with the mouse doesn't do anything'
But that is passionately what I hate about it.
In GUI environments there are check boxes, buttons, menus and english labels for everything.
With linux it's like you are copying down a sacred language and presenting it at the alter with your fingers crossed. You just changed something. Didn't fix the problem. But the change still happened. Can you undo it? Probably not without way more digging. So now you just cross another set of fingers hoping you didn't break it more, or break something else in the future.
Compare to windows:
I checked this box that says "disable firewall". Then hit "Apply".
That did not fix my problem.
I unchecked the box that says "disable firewall". Then hit "Apply".
The usual solution is to read the manual. The CLI is not an esoteric language. Software does complex things and you can either go with the GUI-fiction which...does things. Or have every options available to do what the software can do. Take find where the first line is the manual is: find - search for files in a directory hierarchy. Think however you want to find files inside a specific directory and find can do it for you and more. Most users will only have a few use cases for finding and that's what most GUI file explorers offer, but when you need that extra power, it's available to you.
The solution for your problem is to not do stuff you don't understand. And for the above use case, there's usually a GUI for it. The CLI stuff heavily assume that you know what you're doing.
the cli is just as much of a fiction, just fiction with a different focus
i agree that reading the manual is helpful, but doing stuff you don't understand is necessary to come to understand it, so i don't think it's good advice to avoid it. using the cli for simple things builds the skills you can use for more complex things. the same is true of a gui
(of course there are clis and guis incapable of doing complex things, and those are kind of a dead end)
> but doing stuff you don't understand is necessary to come to understand it
Only if you're doing an experiment and can constrain accidents. Any other type of activities would require to read the manual first. They're terse because they're supposed to be a reference, but you can usually find books that ease the way in. And then there's the domain expertise that is required. You need networking knowledge to interact with software like ip, operating system knowledge to understand what top is showing to you, etc. You can't get around that.
The GUI is a fixed canvas already painted by someone else, the CLI let you write your own poetry.
as i said in my other comment at https://news.ycombinator.com/item?id=40912296, text really helps a lot with constraining accidents
obtaining networking and operating systems knowledge includes as an essential part using software like ip and top (though try htop instead). it's not a strict sequencing but a back-and-forth interplay, synergistic with factors like study and mentorship
as for poetry, there are plenty of clis that aren't very expressive—rt-11, cp/m, grub, ms-dos, and mpv come to mind—and plenty of guis that are very expressive, such as godot, blender, inkscape, labview, solidworks, freecad, and sieuferd. you can write your own poetry as easily in godot as in bash
what would be ideal from my point of view for check boxes, dropdowns, and labels would be if they were a simultaneous alternative view of a command line, or rather a configuration line. an additional simultaneous view would provide a live preview of the result of that line. but you could still type and copy and paste the text
interestingly this is not too far from my usual experience with the command line. i want to compile a target, so i type `make ` and hit tab twice. i see a list of targets and pick one by typing a letter or three and tab, and hit enter. the compiler errors out right away with a c99 construct, so i add `-k` to the command line (^p spc - k ret) to see how widespread the carnage is. it's everywhere, so i add a compiler flag to the options and try again. and in 30 seconds i have a working build. or maybe i need to use a different compiler, or something, but it's easy to return to the fresh unpacked tarball or git checkout
this is close to the opposite extreme from what you describe in
> You just changed something. Didn't fix the problem. But the change still happened. Can you undo it? Probably not without way more digging.
i very rarely do anything in text mode that is in any way hard to undo. shell commands are mostly purely ephemeral: their only effect is some text on your screen, an entry in your history file, and maybe an output file. if i want to change one, i hit ^p and change it before hitting enter. as for configuration changes, i would say that change management is actually the major strength of the text approach: you can copy configuration lines into your notes, comment out old versions in case you want to go back to them, check the whole configuration into git, diff it to see what all has changed, etc. everything can be undone in exactly the same way. everything is a controlled experiment, with the computer itself recording the configuration of each trial automatically and implicitly
admittedly there are occasional exceptions, like when you're reconfiguring the firewall or upgrading debian to a new release. though current configuration-as-code systems like docker and ansible go a long way to making all that stuff just as recoverable. the server went catatonic? too bad, revert the firewall rule change and reinstall it, and 45 seconds later the problem is fixed
by contrast, it's almost never obvious how to undo clicking on a command button or a menu item. even a dropdown selection is hard to undo: you have to remember what was previously selected
but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it
Trust me man, I know a few Concorde pilots and they sit in that cockpit and flip switches and the spin the controls such that the plane will glide like butter through a hurricane - while myself here is practically crash landing at every stop.
There is the chronic issue with skilled linux users where they keep flexing how good the terminal is (and lets be honest: flexing their fluidity and dexterity with it too) while completely missing the forest for the trees. The terminal sucks because it is difficult to use with an arduous learning curve.
There is a reason why Android, the most successful linux "distro" to the point at the summation of others is a rounding error, has no user terminal and a robust GUI. People don't even know it's linux. Thats what we need; an opensource linux distro that people don't even know is linux.
let's consider the possibility that people might disagree with you for reasons other than being dishonest. for example, i disagree with you because you're completely wrong on the facts, as i explained in my grandparent comment. unlike you, i'm not going to accuse you of dishonesty; possibly you are just ignorant (and aggressive) rather than mendacious
worse, though, you're using your ignorance to promote a vile ideology: the ideology of disempowering users in the name of ease of use. what you're advocating here is the strawman that people sometimes use to criticize guis: not powerful guis like excel, blender, solidworks, godot, photoshop, and autocad which empower users in ways that transcend the limitations of character-cell terminals, but glorified menu systems like mainstream android apps, which reduce users to passive consumers or machine operators
being a machine operator, manually telling a machine what to do over and over again, can be enjoyable and rewarding, as in riding a bicycle, driving a sports car, or your example of piloting a concorde (although you don't actually know any concorde pilots or you'd be aware there haven't been any concorde pilots in 20 years; interpreting you with extreme charity, perhaps you only meant this as a metaphorical explanation of what text-mode uis look like to you). but it must be voluntary, because it's an economically low-productivity activity; when you condemn people to be machine operators, you are condemning them to material poverty. bicycle messengers and taxi drivers do not have easy lives
computers permit people to automate machine operation, which enormously increases economic productivity. that's what we need. things like bash facilitate that, and things like android actively prevent it. good guis like godot's are in the first category, not the second
> but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it
That's where domain knowledge comes in. If you don't know anything about networking other than selecting the WiFi network and entering the password, you're going to have a hard time interacting with ip. If you don't know anything about codecs, ffmpeg will seem esoteric.
More often than not, in MacOS and the like, the GUI is reliable and there will be apps for not so common stuff. In Linux, the software (however complex) has already been written in CLI mode and works fine. Someone could do XLD or iTunes, but they're already happy with their ffmpeg scripts, and their MPD setups.
And the key to get there is to usually get a book about Linux at first, then learn about the software you are using.
It also allows you to copypaste the solution, as opposed to following directions for a GUI settings window.
When things work fine, then the average person does not need a terminal.
When you do have to fix something, you need a terminal. On Windows you need to touch the registry or worse. Try attaching a debugger to figure out the reason of a blue screen and tell me how user friendly it is.
Finding and changing a cryptic file to fix an issue is troublesome, but if the alternative is "just works" well... you cannot blame the terminal in that case, but the problems that are showing up.
Likely an unpopular take, but I switched to the "Natural text editing" preset in iTerm2 to get editing shortcuts that match the traditional macOS ones. It has the advantage of just remapping to the normal control sequences inside terminal apps, so you basically get this functionality everywhere without needed to change it in multiple places/worry about readline support/etc. It isn't perfect (I have rarely needed to enter sequences manually that then are remapped), but I find I have used way more command editing since its part of my muscle memory.
https://pliszko.com/blog/post/2021-10-31-natural-text-editin...
Came here to say this, it's one of the first things I configure when I install iTerm.
Being able to naturally use cmd+arrows, opt+arrows, cmd+del or opt+del is invaluable to me. I don't want text editing in my terminal to be special.
the top three default readline keybindings that would improve people's lives if they knew about them:
- control-w, which julia mentions in the post, to delete the last word
- control-o: when you're recalling a line from history, edited or no, runs the line and recalls the following line from history. so you can run a sequence of five commands from history by navigating to the first one and hitting control-o five times
- control-r: search backwards in time through your history as you type a search string. control-r again jumps to the previous hit, control-s goes back forward in time. hitting enter or control-o executes it
I've always wondered why control-s was chosen for this, given the obvious conflict with XOFF (pause), which in my experience is the default almost everywhere. One would have to (a) know why it wasn't working and (b) be willing to disable XOFF, in order to use that key combination for the forward history feature.
nowadays it is usually not the default anymore, since tcp connections and unix pipes have other ways to avoid overflowing their buffers. the history is that that keybinding originated on its. as i understand it, its also had another flow control protocol to avoid overflowing serial terminal buffers, the moral equivalent of the enq/ack scheme, which doesn't depend on hard real-time responsiveness to work reliably. (but it wasn't just literally ^e and ^f since emacs uses those even more than ^s.)
initially to get emacs running on unix systems you had to do a lot more than just stty -ixon -ixoff; you had to upgrade your host's ram and convince the other users that an editor was a reasonable use of such a large amount of resources. by comparison, adding a couple of extra wires to the modem cable to support rts/cts flow control (which was more reliable anyway) was no big deal
but yeah, it was a big pain for about 15 years, from 01990 to 02005. it still bites me occasionally when i accidentally type ^a^f in screen and accidentally enable xoff!
Oh I always do ctrl+shift+r for that last bit, like reverse-tabbing on a gui. Good to know about ctrl+s, though I imagine muscle memory will prevent me for ever using it. :)
normally control-shift-r is just control-r; both key combinations send the same byte, 0x12, so they both search backwards in readline history. is your terminal emulator doing something different? if you type control-v control-shift-r enter control-d as the input to the command od -t x1a, what does it say?
You’re right, I was wrong. Thank you for the gentle lesson. :)
happy to help!
So when I use Windows Terminal and I press Ctrl-C, it always does the right thing: If I’m selecting text I want to copy it, if I’m not selecting text I want to kill the running process.
On Linux, every Terminal app I’ve used stubbornly refuses to copy when I press Ctrl-C, demanding I press Ctrl-Shift-C. When I paste, if I forget my manners and use Ctrl-V instead of Ctrl-Shift-V, I am punished by getting a weird character when I start typing again. And I am constantly pressing Ctrl-V because of muscle memory since no other app works this way.
Is there any terminal app for Linux that does things the Windows Terminal way and won’t slap me on the wrist for Improper Teletype Usage?
I've always configured my terminal to copy on select. I never press ctrl-c. I mean, why would I want to select text if not to copy it?
E.g., to press Ctrl-(Shift)-V and replace the selection with something you copied (to the buffer / clipboard) earlier?
that doesn't work in terminal emulators because the terminal emulator doesn't know how to delete the selected text in whatever program drew it there (which may no longer even exist)
Its funny, the thing which most keeps me on a Mac is simply the disambiguation of copy vs kill (Command-C vs Ctrl-c) in the terminal.
I copy from/to terminal with middle mouse button. Just select some text and click middle button where you want to paste the text. Some people don't like it because it needs a mouse, they prefer to keep their hands on the keyboard, but I don't see any issues with it.
This way to copy/paste uses it's own Xorg buffer, so you can copy something with Ctrl-C and select something else, and then Ctrl-V will paste the first thing and middle click the second. I have issues using Windows and smartphones because I sometimes try to copy by just selecting things, forgetting to hit Ctrl-C or something. It is really annoying.
> Is there any terminal app for Linux that does things the Windows Terminal way and won’t slap me on the wrist for Improper Teletype Usage?
I think not. The trouble is programs running in terminal may want to deal with Ctrl-C by themselves. Text editors for example do that, but terminals have no way to know it. Terminals even don't know what program is running now, because job control is a job of a shell.
> The trouble is programs running in terminal may want to deal with Ctrl-C by themselves. Text editors for example do that, but terminals have no way to know it. Terminals even don't know what program is running now, because job control is a job of a shell.
But then why does Windows Terminal (even when running against WSL) not have this problem? The terminal doesn’t need to know what’s running inside it to know “if text is selected, intercept Ctrl-C and copy the selected text”.
Idk, but I can guess. In windows terminal and shell are not so separate as in Unix. For example, is cmd.exe is a terminal or a shell? I believe it is both. Probably it is the same with powershell.
This is a mistake, but forgivable, as Windows executable launch behavior blurs this distinction.
Just like UNIX shells, cmd and PowerShell are ordinary console programs.
The Windows equivalent to xterm and friends — i.e., the mechanism responsible for displaying console I/O in a window — is a bit complicated, has changed over time, and only recently (Windows 10 1809 / Server 2019) adopted a UNIX-like pseudo tty / terminal emulator model.
For a good overview of Windows console architecture, past and present, see
https://devblogs.microsoft.com/commandline/windows-command-l...
Most decent linux terminals let you configure this. For example in kitty:
map ctrl+c copy_or_interrupt
https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_inte...
I think you could achieve this in Wezterm, which is configurable with lua. Not on my laptop right now but will try to get it working later. I have other keybinds that run specific lua functions.
Please do share what you learn! I'm considering switching from mac to Linux, and wezterm is my daily driver.
Whenever someone brings up this subject, I'm reminded of this classic article from Linus which has appeared many times on HN: http://www.linusakesson.net/programming/tty/index.php
Always a good read; I enjoy rereading it every time.
warp and and some powershell version were the only “terminals” i used that seemed fixing the input line, but also did not quite feel right. the worst parts of terminals for me are that input line does not behave like a normal text field with mouse click, select and everything a user would expect in another context, that history mostly scrolls on a line basis instead of smooth pixel scrolling like any other document (don’t get me started on pagers, i still don't manage to disable man pages opening in some archaic mode that takes 3 tries to even exit from git), commands that default to tuis or clearing the screen. i tried to avoid unix as long as possible because of this and the absurd random / hostile folder names + layout but just because *nixes won does that mean we have to keep these archaic absurdities alive? why does even something where innovation would be simple like the vscode terminal feel like that and not like the chrome console with a normal text input line with graphic autocomplete and mostly immutable command response history with collapse/expandable sections? even unix commands that would not work in this mode could just run in something like an inline widget or new tab where they could read input lines by character or whatever weird behavior they expect.
Ideally we'd have the equivalent of an ipython notebook for the terminal. But GUI on Unix is still an unsolved question with more and more incompatible implementations being written daily, so I'm not holding my breath. After using Linux for over 20 years now, I've concluded that if you want a desktop OS, use Windows. If you use Linux, learn to live in the terminal - it's the only consistently working piece of the OS, everything else is consistently broken.
I plan to make one day an alternative to terminals. My idea is not fully fleshed out, but I would like to try to forgo TTYs altogether. Use only pipes, file descriptors and job control.
The closest thing I saw to what I have in mind is this: https://github.com/letoram/cat9/ but more in a way of interface.
One thing to start with is to not throw the user into a screen consisting of a grid of fixed width character cells at the very beginning. This is what immediately sends a signal of discomfort to most users not already familiar with terminal emulators. There's no real reason why the default experience of having a dialog with your system installation couldn't take place within an interface that resembles iMessage or ChatGPT or something like Quicksilver. Things like /bin/rm certainly don't care whether they're being invoked from a terminal emulator that has the conventional look or whether it's in a chat-like interface—it doesn't rely on any line drawing characters or output alignment. Even the Python REPL doesn't depend on that sort of thing a great deal, except for stuff like ASCII art arrows pointing to syntax errors. Only when you want to use stuff like vi or ps and ls helpfully trying to put things into columns will you start running into trouble if your terminal emulator has an non-traditional UI. This can be ameliorated to some degree with heuristics to detect e.g. spaces being used for alignment and cursor positioning escape sequences in the output stream.
The utility in your link, and the entire Arcan system, seem very pleasant to me; a dream of mine is to have a complete graphical LISP command-and-control via an interface like that; like the old lisp machine UIs but with more direct incorporation and seamless handling of multimedia Objects.
Are you talking about terminals, or about shells?
I suppose the latter. Have you checked Oilshell, Elvish, or PowerShell (yes, on Windows)?
I’m working on a similar vision. Except instead of replacing the terminal, I’m turning it into a more of an ergonomic interface for structured data and multimedia.
I’m open to discussing thoughts on this.
Nice to see this writeup. Entering text into the terminal, and copying output out, is a huge barrier to entry for beginners. Windows terminals in particular feel downright antagonistic to use.
cmd.exe or the new https://github.com/microsoft/terminal ?
I haven't used the new one! Will check it out, thanks.
> took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end).
And the curse of bad defaults strikes again (daily).
After the realization that this is a weird default you don't train yourself for 15 years, but change it to your comfortable/common keybinds!
I wonder what terminal that is, because the Home and End keys, which I'm pretty sure are the expected alternatives, work fine in every terminal for me on Linux.
There are many keyboards without home and end keys.
I feel like you're being willfully obtuse here. I can't remember the last time I used a laptop which had Home / End keys.
Edit: actually I do remember -- it was an HP ProBook from 2011.
For the complaint to make any sense in the first place there needs to be an expected alternative way to go back to the beginning and end of a line. Otherwise it would be "it took me maybe 15 years to get used to being able to go to the beginning or end of a line in one keystroke". The two such options I'm aware of are Home/End (on macbooks I believe that is Fn+arrow keys) and Ctrl-a/Ctrl-e.
What alternative key combinations do you expect to work for the purpose?
I think I didn't communicate that well. What I saw was:
The obvious answer is: jvns doesn't have a Home key.Almost every (Windows) laptop has them, although they do all use their own unique (IMHO often awkward) layout.
I can't remember the last time I used a laptop without Home/End keys.
Among them are a Dell from 2002, an IBM from 2006, another Dell from 2018, and a Lenovo from 2019.
...and here's one from 2024 that still does: https://www.storagereview.com/wp-content/uploads/2024/04/Sto...
I have the same experience.
I'd rather press left or right arrow keys 40 times than pollute my brain with yet another keystroke to remember.
If you were an Emacs user you would find this to be a good and useful default. ;)
Remaps Capslock to Ctrl and it will make a lot of sense. Other heavily used shortcuts are Alt+d, Alt+Backspace, and Alt+Left|Right.
Still wouldn't, why would you use your weakest finger in the bad sideways motion for such a frequent operation???
It's usually the weight of my whole hand. I touch type, but my hands are usually tilted to the exterior. So I hit keys like Enter, Capslock, Shift, with the side instead of the tip of my fingers. And I don't mind sliding my whole hands if I'm going to use it repeatedly.
Side vs tip doesn't come close to tipping the balance
And the last part is backwards - you don't need to use it repeatedly, there are much better alternatives, so you could just as well not mind not doing it
These defaults are not bad if you use Emacs :) Or if you use macOS that (gasp) supports the very same ^A and ^E shortcuts in all edit controls.
They are, you just remap them in emacs and Mac as well
There is no point in suffering for decades just because some bad defaults exist elsewhere
Also worth mention the Plan 9 "fixed prompt" where any command is at the top, with it's output underneath, there are few variants and in few cases they are comfy.
Another neat trick is to use ctrl-x ctrl-e, this gets the command in a vim buffer (default editor for me). Edit the command and then :wq to reflect the changes
That's neat!
For me, Ubuntu's terminal is perfect.
Give me arrows, tab, Ctrl+(R/C/D/W) etc and its a great.
But I agree with the point that different systems have their own implementation which could lead to frustration.
I am working on set of servers only accessible through PAM and those admins don't allow anything. It gets so frustrating.
I feel a lot of the frustration also comes from shifting to unfamiliar environment. Like I work on those restricted servers and am cursing the admins, but when I switch to Ubuntu's terminal I am thanking the gods for liberation.
Periodic reminder that many emacs-like keybindings exist in almost every text field in macOS: Ctrl A, E, P, N, K, Y, T, and probably others I'm forgetting (start of line, end of line, previous line, next line, kill (delete everything to the end of the line and put it in a special pasteboard), yank (paste from that special pasteboard) and transpose characters).
Edit: more complete list here: https://jblevins.org/log/kbd
Edit 2: can't believe I forgot Ctrl-D, which is forward delete.
"The other day I asked what folks on Mastodon find confusing about working in the terminal, and one thing that stood out to me was "editing a command you already typed in".
This really resonated with me: even though entering some text and editing it is a very "basic" task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)."
Only took me a year or so to get used to using "v" in vi mode and fc. I am not a "developer" but I prefer textmode command line to GUI. I do not use X11/Wayland/etc.
I learned sh on NetBSD which I still think is one of the best shells available. It's fast. vi mode is the default. People may disagree but I think for editing single a line of text, i.e., a "command", vi mode offers more precision. For example, being able to jump directly to a particular column number.
https://web.archive.org/web/20240528201424if_/https://pubs.o...
IMO, as a dumb computer user who is not a "developer", this is not complicated. I think terminal emulators are complicated, though. I do not use them.I believe fc came to POSIX from ksh.
For me, it is not that UNIX is objectively good. It is that the available alternatives are still comparatively bad.
> editing a command you already typed in
It's been mentioned here before, but you should suggest the Ctrl + X, Ctrl + E combo - they can edit the command in their favourite text editor and then it gets executed when they exit the editor.
yes, fc is from ksh
going to a particular column number is not useful to me because my commands are not on punched cards with column numbers printed on them. going to a particular piece of text is, and ^r or ^s gets me there with readline (in vi mode or emacs mode). i don't want to mentally count how many characters are on the line before the place i want to go; i have a computer to do that for me
vi movement by words is useful though, and slightly easier than emacs alt-f and alt-b
tcsh has a (maybe) unique command line editing feature: transpose characters.
Ctrl-T
It's vi mode is not as good as libedit's (IMHO) yet each shares the same author/maintainer.
Though it's no longer the default, I believe tcsh may still be included with MacOS.
I think the lowest hanging fruit would be doing something (anything) to improve discovery of commands. I have great grokking abilities but terrible memorization skills, and I end up forgetting how to do what I want to do and maybe even have done before. Browsing man pages for every command is my bane. It's also why I dislike GUI with unlabelled icons, I never remember what each one does.
Haven’t used it much but “apropos” is probably what you want.
https://man7.org/linux/man-pages/man1/apropos.1.html
Maybe try fish? Tab completion will suggest subcommands, and if you type - or -- and hit tab, it will suggest the available options with help text generated from man pages (example: https://flaviocopes.com/images/fish-shell/autocomplete.png). Doesn't really help with positional arguments but it's definitely enhanced the discoverability of many tools for me.
This is by far the best practical option! Life could be even better, but out of all options this one's great.
At this point Google has basically taken over that function... "How do I _ on the command line?" more often than not gives one some starting point to develop from.
GPT is great at this. I wrote a little program that I can call from a shell. Bashai.py show me a bash one liner that does x. It then shows me the command and asks if I want to run it with or without root. Simple, yet one of the best tools I've ever made for myself.
fzf replacing my default ^R has been a godsend to me for remembering how to do things in the shell.
https://github.com/junegunn/fzf
A note file with the commands written would be your best bet. Then bring the most common ones in your shell as aliases or functions.
> It took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end).
That looks like some cognitive problem or ADHD. (Obviously, completely unrelated to intellect.)
> some programs (cat, nc, git commit --, etc) don’t support using arrow keys at all: if you press arrow keys, you’ll just see ^[[D^[[D^[[C^[[C^
I've long argued that the readline-like functionality should be in the kernel. The POSIX line discipline should be replaced or augmented with full blown editing with history recall.
Imagine rlwrap, but always there, all the time, in the TTY driver.
There are downsides, because history wants to be contextual and persistent. The kernel knows what process is making the read() call on the TTY, though, so that could be somehow arranged. Certain new security issues come up also.
> it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)
Ctrl+LeftArrow and Ctrl+RightArrow also work with every readline-compatible shell and they are much more intuitive, especially if you are not used to terminal text editors.
> it’s very inconsistent between programs
Readline or emulations thereof are pretty common and the de-facto standard. But of course programs can do their own thing if they want to - it's not like GUI text eidtors all have consistent shortcuts.
cat / nc / etc. are not editors at all and therefore don't provide those shortcuts. They take an input stream and forward it.
those move by words, not to the end of the line
Wirth showed us decades ago how to do UIs using text in a modern way yet we remain firmly tied to digital analogues of teletype terminals.
https://en.wikipedia.org/wiki/Oberon_(operating_system)
From which, plan9/sam/acme got it's inspiration afaik.
The downside is being required to use the mouse often plus some dexterity.
The vi vs emacs thing permeates a lot of tools. I find it useful to map all tools to be consistent with one or the other. Personally I use vi. Unfortunately setting vi mode for readline has a few caveats, but I was able to work around all of them with the settings in:
https://www.pixelbeat.org/settings/.inputrc
I switched my Mac terminal to Warp.dev simply for the default mac text input. I can ⌥ and ⌘ left and right to select words or until the end of the line ⌘A to select all. It comes with so many other bells and whistles that I've mostly ignored for this simple convenience. I don't use emacs (or vim) keybindings in any other context and I'm not sure why the terminal forces you to.
I've never seen dash dump escape sequences instead of acting on arrow keys. Probably, it's due to a missing or wrong TERM value?
Nowadays, programs should be hard-coded to accept ANSI sequences and ignore TERM (unless they need to make some fine-grained distinction like do we have 256 color xterm compatibility).
Those programs will never have that problem of not understanding arrow keys.
it's more likely because she's running a version of dash compiled without readline support, probably debian's version (which is compiled that way because it's not intended as an interactive shell, but rather the lightest-weight posix-compliant shell they could build)
i agree about ansi sequences. even that doesn't go far enough, though: we should probably be moving past character-cell terminals to something better so we can have things like proportional fonts, multiple font sizes, properly spaced borders, and rounded corners
Looks like I'm wrong. If I fire up an interactive dash on Ubuntu or Debian, no arrow keys. /bin/sh is dash, but that's only for hash bang scripts.
Not just no arrow keys, but nothing. No Ctrl-P to recall previous line. No editing beyond the POSIX TTY line discipline stuff: Ctrl-W word erase, Ctrl-U line erase, backspace.
also i'm wrong; it doesn't have an option to compile with readline, just libedit (which indeed is not included in the debian package configuration). the incantation was as follows:
libedit supports ^r but not ^oon the other hand my dash process with libedit is 1.3 megs rss while my bash process is 7 megs rss. and the dash executable is only 130k. still, bash is only about 20% slower to start up
A meta-question for those of us very comfortable composing complex sequences on the command line: when I’m trying to help someone with something, how can I avoid becoming frustrated by their lack of facility - or worse, their lack of interest in obtaining facility, without being an ass and taking over the keyboard? Grumble.
I use M-x shell and variants in Emacs for almost all of my command line work. No problems with editing, as it is always Emacs on top. For true ncurses apps there are some limitations inside vterm or ansi term but even there, I can still use elisp and fix these problems if needed.
> the readline keybindings come from Emacs
> Because I’m a vim user, It took me a very long time to understand where these keybindings come from
libreadline supports a basic vi mode. In bash, `set -o vi` lets you use vim-style editing. It is a lifesaver.
Already addressed in the article
I just press and hold backspace and try again from scratch
Or you can just write a bash script file to do shortcut executions of complicated terminal commands...
See also the same blog's previous article, "What happens when you press a key in your terminal?"
https://jvns.ca/blog/2022/07/20/pseudoterminals/
(It's a great article, and I'm fairly surprised the post doesn't directly link to it)
Rlwrap is a great utility. rlwrap telnet ... makes life so much easier.
Mode ∞: shell mode in Emacs.
I thought this was going to cover RS232 implementations. Oh well, next time :-)
[dead]
> license reasons, if the program’s license is not GPL-compatible – readline is GPL-licensed, not LGPL
The older I get, the less patient I become with finding out some user experience sucks because of GPL / non-GPL knife fights.
It's been thirty-nine years now. I think the GPL was useful at its origin, but now the benefits of open-source are proven out, the world is deeply interconnected via the Internet, and it's a hindrance to have some code burden other code with requirements. I, for one, don't expect to write any further GPL code in my lifetime. I'd rather code be maximally unencumbered from interoperation.
No, the GPL license for GNU Readline is very intentional. There is a bunch of written history from Richard Stallman about it. He felt it provided such an large advantage, that some programs might switch to GPL to use GNU Readline. After 35 years of development (started in 1989 according to Wiki), it has a hefty start is someone wants to beat it with a "clean room" BSD-licensed edition.
Some HN info about Stallman's reasoning: https://news.ycombinator.com/item?id=26606328
I cannot find any specific writing from him, but I am sure I read words from him about 25 years ago.
Yes, the problem is that commercial organizations would like open source to do all the hard work for them. Then, they use the software internally, and don't give anything back -- except two pence via RedHat licensing. (We have learned this the hard way in the last 10 years of major security bugs due to underfunded projects.) However, you are free to re-implement the API and license it in a different way.Yes, I think we are in agreement. The GPL in this era is a wrench in the process of useful code. You have brought to my attention how intentional that was.
Rms did something impressive but he doesn't impress me in this day and age. Many revolutionaries make for poor governors; in my personal opinion the software ecosystem would be best served by cutting around him these days.
@shadowgovt Genuine question: if i wanted to create new software nowadays, and i wished for it to be as you noted "mmaximally unencumbered from interoperation", which license should i choose for my software? Which license would you use? Again, not trying to be snarky; just wanting to learn and understand. :-)
I generally use the ISC license these days. It is short, indemnifies me from damage caused by the software I write being used by other people, has a thin requirement that the copyright be carried forward into other projects using my code (A requirement that I'm probably not going to enforce), And that's it. No encumbrances against interoperation with other people's code.
Today I learned! I hadn't heard of the ISC license. I've heard of GPL, Apache, MIT, and other common ones, but not USC until now. Thanks!
The ISC is basically pretty similar to the MIT license.
It took the author 15 years to learn basic readline commands?
I've been using terminal for +15 years, and I just learned what this is. Because you highlighted it being crazy that someone didn't know what it was, I looked it up.
Neat! Thanks for teaching me something today. This will be helpful, especially after I spent all morning messing with crontabs and logs and permissions and PATH env's.
Edit: Having read more about this now, I'm realizing that I do use a couple of these out of habit. I just didn't know they were called "readline commands". I thought they were just "how to use the terminal". But there's dozens and dozens of other commands I never knew were possible. Brilliant. Happy Monday.
Terminal feature discovery is hard. If you don't regularly use the commands it's easy to forget they exist.
Here is the exact quote in question:
I think your take is a bit harsh. She is quite a popular writer, and day after day, lays out her ego out for a beating by the InterWebs each time that she posts. She is never afraid to be humble. That is part of the genius of her posts. She says what so many are afraid to say publicly -- "oh this 'simple' thing is very complex" or vice versa.I've also been using Linux and the terminal ~15 years, and these things i keep forgetting and relearning every now and then. About Ctrl+A in particular, it never sticks in my memory, since i find typing the Home key to be more intuitive. Maybe the author has this same "problem".
It's funny how other programs don't seem to have this issue, and their users are able to learn new things without having to resort to an external manual. Makes one wonder about the design of everyday things!
Yeah, I have my doubts about the claim. I forgot what I read way back when as an intro book, but I suspect it was more like a month in my case, if that. But I remember having been surprised at various points that there was an undo (C-_), and a clipboard (C-y to paste) including a history (M-y). So yeah, I guess it depends on the scope.
Maybe it's a hyperbole? Dunno, doesn't really read that way.
How can you discover something on the terminal itself? You fall into a pattern and stick with it. It is only if you get out of band information that you can learn these tricks.
Bit confused by this comment. I don't think anybody suggested you're going to find these things solely by interacting with the terminal - but rather through "out of band information" as you put it, which in GP's case, as he said, was a book. The surprising part of TFA, and replies to my comment - to me anyway - is how one can go so many years without picking up that information.
I have never read a book about improving my terminal knowledge. I have a few tricks I have picked up over time (probably through posts like this!), but never done holistic research on the subject. Therefore, despite having used the terminal for decades, I likely have a similarly long list of basic terminal knowledge gaps. I do not know what I do not know.
I have great respect for Julia Evans and love her contributions that get shown here.
But...
> "I’ve always thought that vi mode seems really cool, but for some reason even though I’m a vim user I didn’t really like using it when I tried it."
Really, that seems weird to me.
I use zsh (btw) and the problem she describes is a non-issue. And I am not a pro. (Sorry, Julia).
I have to agree with the other commenter (drewg123). Been a Vim user for decades but don't use Vi-mode in the terminal.
> the problem she describes is a non-issue. And I am not a pro.
Not sure what you're saying here. Julia didn't describe a problem but a preference ("I didn’t really like using it"). I'm not sure how you can you call someone's preference a non-issue. It's a preference and we're allowed to have those last I checked! :p
"even though entering some text and editing it is a very “basic” task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)."
This sounded to me like she was describing a problem. My bad.
And I too am allowed express opinions, no?
In your first comment, you said it "seems weird" that Julia doesn't like Vi-mode.
In this comment, you quote Julia talking about Emacs-mode. Which doesn't really follow on from your first comment.
Thanks. I appreciate your civility.
The lack of clarity is my fault.
I felt Julia was describing a problem that she was having for 15 years to do with editing on the CLI. Then she said "even though I’m a vim user I didn’t really like using it when I tried it."
To me, even still, it seems weird that there is a tool (vi-mode) that solves the problem she seemed to be describing earlier on. I am not denying that she "didn’t really like using it when I tried it".
Not sure that even with this reply I have cleared up my earlier confusion-causing comment. I shall endeavour to refrain from further nonsense in the future.
Ah, this reply does indeed make it clearer what you were saying :)
Whether I agree with what you were saying is a different matter (:p) but at least it makes more sense now!
I don't find that strange at all (prefering emacs to vi mode). I feel the same way.
I use tcsh, and have it configured for emacs-style command line editing. I use emacs for complex stuff (coding) and vi for simple stuff (editing a config file), so I'm comfy with both.
I think my issue is that it seems slightly unnatural to remember the mode I'm in on a random terminal command line, and much easier to just use the emacs keys to edit when needed.