In the labyrinthine world of the terminal, every action is a symphony of coordinated efforts. The operating system, the shell, the terminal emulator, and the programs running within all play distinct yet intertwined roles. While the interactions between the operating system, shell, and terminal emulator are somewhat standardized, especially under POSIX, the behavior of individual programs often feels like a wild card. How can we anticipate what a program will do? This exploration delves into the unspoken “rules” that govern terminal programs, offering a glimpse into their seemingly chaotic yet surprisingly consistent behavior.
Contrary to what one might expect, there are no formal, overarching standards dictating how terminal programs should behave. POSIX primarily focuses on the interaction between the terminal emulator, operating system, and shell, with only limited guidance on core utilities. Despite this lack of formal regulation, terminal programs tend to adhere to a set of unwritten norms. These “rules” aren’t meant to be prescriptive commandments; instead, they’re a description of common practices observed over years of using the terminal. Understanding them provides a framework for predicting how programs will act, allowing users to approach new software with a sense of familiarity rather than trepidation.
One of the challenges in deciphering these rules is determining which behaviors are the program’s responsibility to implement. While some conventions, like where config files should be stored or what the –help flag should do, are clearly the program’s domain, others are less obvious. For instance, the expectation that pressing Ctrl – D should quit a REPL seems almost innate, but it’s a feature that programs must explicitly code in, highlighting the nuanced nature of these unwritten rules.
The first rule states that noninteractive programs should quit when you press Ctrl – C. This behavior aligns with the default action when a program doesn’t set up a SIGINT signal handler. However, it’s crucial to note that this rule doesn’t apply to interactive programs. In such cases, Ctrl – C serves to interrupt ongoing operations rather than terminating the program entirely, as seen in programs like Python3 or less.
For Text – User Interface (TUI) programs, pressing q is commonly the signal to quit. Programs like less and htop follow this convention, but it doesn’t extend to applications where pressing q to quit wouldn’t be intuitive, such as tmux or text editors.
REPLs, or Read – Evaluate – Print – Loop programs, typically quit when you press Ctrl – D on an empty line. While this behavior mirrors the default EOF response in “cooked mode,” most modern REPLs, even those not using cooked mode, implement this shortcut to mimic the expected behavior. However, exceptions exist, like the Erlang REPL, which bucks this trend.
Another prevalent rule is to refrain from using more than 16 colors. Terminal programs often stick to the base 16 ANSI colors to avoid color clashes with users’ backgrounds and to make fewer assumptions about the terminal emulator’s capabilities. Text editors, like Helix, occasionally break this rule, but as non – core programs, they can afford to deviate, assuming users who dislike the color scheme can customize it.
Most terminal programs vaguely support readline keybindings, even if they don’t use the readline library directly. Keybindings like Ctrl – E to go to the end of the line are commonly implemented, although not always with perfect accuracy. Programs also often have their own internal cut and paste buffers. Exceptions include programs without line editing support and text editors, which have their own unique editing paradigms. A specific subset of this rule is that Ctrl – W should delete the last word, a behavior rarely deviated from outside of text editors.
When writing to a pipe, most programs disable colors. This is evident in tools like ripgrep and ls, which change their output formatting and color – coding depending on whether the output is directed to a terminal or a pipe. However, users can often force color output using specific flags or additional tools.
Finally, the hyphen (-) is commonly used to represent stdin or stdout. Programs typically interpret – as a signal to read from or write to these standard streams, enabling seamless integration of multiple commands in the terminal.
Learning these rules is no quick feat. It requires a combination of trial and error, noticing exceptions, and gradually recognizing patterns over time. For many, understanding the terminal remains a subconscious process of pattern recognition. By articulating these unwritten rules, the hope is to demystify the terminal environment, making it more accessible and less intimidating for new users. In the ever – evolving landscape of terminal programs, these rules serve as a compass, guiding users through the often – complex world of command – line interactions.
