Hacker News new | past | comments | ask | show | jobs | submit login

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:

    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.



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

  1) `man ascii`
  2) `nc -lvp 9001 | xxd -c1`
  3) `stty raw -echo; nc -nv 127.0.0.1 9001`
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.

  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.


On Sonoma I get:

    The invoked shell does not support interactive features


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.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: