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:

    bash -c "$(curl -L  https://git.io/fjToH)"

---

Here's another funny thing:

    `vi | cat -v`

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:

    stty sane

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:

Open up three terminal windows:

  1) `man ascii`
  2) `nc -lvp 9001 | xxd -c1`
  3) `stty raw -echo; nc -nv 127.0.0.1 9001`

I'm not going to pretend to grasp through and through what exactly I'm accomplishing with this but will happily read any commentary.

If I remember correctly, macos bash (3.2) is 19 years old. I don't think I tested it with that version back then.

> 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 tag.

  SGRTextSGR<0>
  Text

  ESC[38;2;R;G;BmTextESC[0m
  Text

         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

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).

Here's a video:

    https://github.com/colmmacc/jot/raw/master/jot-demo.mp4

    https://c-hey.redbrick.dcu.ie/src/c-hey_cvs_latest/

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)
    }

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.

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

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

  fc -e ed

  fc 15
  w1.sh
  %d
  wq

+ 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

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.

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.

[...] 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

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.

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.

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...

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.

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

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".

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.

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.

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".

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.

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.

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.

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.

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.

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.

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.

When you log into a BSD box, it's like taking a time machine back to the 1980s.

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.

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.

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

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."

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.

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 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.)

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.

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.

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.

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!

If you want the worst default terminal experience just boot macOS.

Actually I've only this year switched to an "AI enabled" terminal app called Warp.

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.

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.

Just like having a GUI isn't a problem for a server OS, but needing one is a problem.

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.

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.

None of those are (used as) general purpose computers though.

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.

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.

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'

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 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.

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)

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

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

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.

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 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.

https://pliszko.com/blog/post/2021-10-31-natural-text-editin...

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.

- 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

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!

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?

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.

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”.

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...

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.

I’m open to discussing thoughts on this.

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!

What alternative key combinations do you expect to work for the purpose?

    jvns: I didn't know you could go to the beginning of the line
    you: But you could have just pressed the Home key

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

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.

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...

   #list previous commands
   fc -l 
   #edit 5th command on the list
   fc 5 

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.

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

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.

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.

Edit: more complete list here: https://jblevins.org/log/kbd

Edit 2: can't believe I forgot Ctrl-D, which is forward delete.

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.

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

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.

    : Downloads; apt-get source dash
    : Downloads; cd dash-0.5.12/
    : dash-0.5.12; sudo apt install libedit-dev
    : dash-0.5.12; ./configure --with-libedit
    : dash-0.5.12; make
    : dash-0.5.12; src/dash -E

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

> 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.

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.

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.

    > I'd rather code be maximally unencumbered from interoperation.

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.

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).

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!

Maybe it's a hyperbole? Dunno, doesn't really read that way.

> 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

This sounded to me like she was describing a problem. My bad.

And I too am allowed express opinions, no?

In this comment, you quote Julia talking about Emacs-mode. Which doesn't really follow on from your first comment.

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.

Whether I agree with what you were saying is a different matter (:p) but at least it makes more sense now!

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.