Entering text in the terminal is complicated

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.

95% of the population doesn't need to use the terminal.

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'

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.

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

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.

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.

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.

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.

Or even just bind it to ctrl-e in bash:

bind '\C-e: edit-and-execute-command'

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

I love these shortcuts but sadly I never remember them when I do need them

You can also just press 'v' if you're using vi mode in ksh like hardened old unixbeards like me :}

And for the fish folk, it's Alt-e

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

  fc -e ed

  fc 15
  w1.sh
  %d
  wq

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.

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.

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.

If you were an Emacs user you would find this to be a good and useful default. ;)

I'd rather press left or right arrow keys 40 times than pollute my brain with yet another keystroke to remember.

It's provided by the terminal (emulator) in "cooked" mode: https://en.wikipedia.org/wiki/Terminal_mode

raw mode doesn't do this.

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.

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.

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.

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.

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?

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.

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.

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:

    stty sane

On Sonoma I get:

    The invoked shell does not support interactive features

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.

  SGR<params>TextSGR<0>
  <font params>Text</font>

  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

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.

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.

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:

  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.

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.

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.

Here is the exact quote in question:

    > 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'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!

Terminal feature discovery is hard. If you don't regularly use the commands it's easy to forget they exist.

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.

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

Haven’t used it much but “apropos” is probably what you want.

https://man7.org/linux/man-pages/man1/apropos.1.html

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.

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.

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

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.

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

Thanks for the screencast. Another +1 for bringing it back to life!

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

Oh, that looks really cool! Is the current iteration of the program stable?

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

Checked out the video. Looks cool!

That's pretty cool, gonna steal the idea.

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

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.

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.

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

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

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.

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.

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

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.

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.

cmd.exe or the new https://github.com/microsoft/terminal ?

That's neat!

Already addressed in the article

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.

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.

From which, plan9/sam/acme got it's inspiration afaik.

The downside is being required to use the mouse often plus some dexterity.