3 comments

  • teddyh 2 minutes ago
    No mention whatsoever of the $TERM environment variable. sigh

    Outputting raw escape codes and hope that they work is not how you do it. This is not how any reasonable library (or bash, or git, etc.) does it. These programs and libraries start with the $TERM environment variable to find out what terminal the user is using, and then use something like termcap(5) to look up what capabilities that specific terminal has, and what actual escape codes to output to get that effect.

    (And also not to output any terminal codes at all if the standard output is not a terminal, as in isatty(3) or tty(1).)

  • tl2do 32 minutes ago
    I've been programming for 20 years and apparently still don't understand what my terminal is doing. Recently I asked Claude Code to generate a small shell script. It came back full of escape codes and I just stared at it like a caveman looking at a smartphone. This article finally explains what's been happening right under my nose.
  • esafak 1 hour ago
    If you're going to do this also provide a way to disable it so parsers don't trip up on its escape-coded output.
    • klibertp 1 hour ago
      Also, disable the formatting if stdout is not a terminal. That way, your colors and cursor movements won't be visible when piping to another program, and your tool will be usable in apps that don't understand the CSI and chars that follow. Use a command-line switch with more than two states, e.g., `ls` (and probably other GNU tools) has `--color=always|auto|never` which covers most use cases.

      Also not mentioned in the article: there are a few syntaxes available for specifying things in control sequences, like

          \x1b[38;2;{r};{g};{b}m
      
      for specifying colors. There's a nice list here: https://gist.github.com/ConnerWill/d4b6c776b509add763e17f9f1... You can also cram as many control codes as you want into a control sequence, though it probably isn't useful in a modern context in 99.9% of cases.