been thinking about even though “the terminal” is technically not a single thing (it’s your shell, terminal emulator, OS, and programs) there are a ton of UI conventions that make the terminal feel like a unified environment, like
* full screen programs like top often use “q” to quit
* programs often turn off colour when writing to a pipe/file
* if a program is displaying a lot of text, it’ll often open “less” to let you scroll
a lot of these feel more like social conventions to me
some more UI conventions that make “there terminal” feel unified
* there’s a loose standard for command line arguments that many programs follow (not all!)
* TUI programs almost always support using the mouse
* interactive REPLs often use readline or imitate it
i’m not sure how many of these are written down or standardized anywhere, it’s hard to imagine there’s a standard saying “you should imitate readline if appropriate” but maybe there is?
(2/?)
@b0rk is even possible to not turn off colour when writing to a pipe? The colour codes are terminal specific, so can only be accurately written when there is a terminal. So you could pipe colour for a specific terminal but not the general case.
@chrisgerhard yeah you can leave colour on, it can get ugly (you just end up with the raw escape codes mixed in with the text and it’s ugly)
@b0rk it took me an embarrassingly long time to grasp the distinction you're talking about. The hardest part was figuring out where convention ended and the solid foundation began.
@pixelkeen it’s SO hard to figure out and there’s really a huge spectrum, like how Ctrl+C handling does have a clear default behaviour, but also programs often override it and when they do you’re back in the realm of conventions
@b0rk Are you interested in hearing about times your readers have seen these sorts of guidelines collected?
anyway i’m curious about whether anyone has documented terminal UI conventions somewhere like “if you’re writing a REPL you should imitate readline for line editing somehow” and “if you’re displaying a lot of text maybe open ‘less’” and “turn off colour when writing to a pipe”
@b0rk I have used the tcsh shell for decades on various Linux and macOS machines but I recently switched to the zsh shell that is the default on macOS now. It is talking time to get all my command settings to work again. The dichotomy between the csh and sh shell families is a hassle.
@EricFielding an experience report of migrating from tcsh to zsh feels like it would help a lot of people
”
Early UNIX developers thought explicitly in terms of a social model for their programs. It looks like a unified environment now, but to me if feels more like evolution set in motion, built upon an idea that "things will be more useful if they are designed to do one thing well and simultaneously play well with others."
@BradRubenstein do you know if they wrote about it anywhere? would be interested to read more
@b0rk not sure if it covers all your mentioned topics, but some time ago i bookmarked this site https://clig.dev/ (Still haven’t read it complete)
@b0rk I first heard a lot of it formalized in the book The Art of UNIX Programming, edited by Eric S Raymond: http://www.catb.org/~esr/writings/taoup/
There's also some good high level discussion of it at https://en.wikipedia.org/wiki/Unix_philosophy
Neither of those is about the terminal per se, but before the explosive growth of the web, the terminal was the major way of interacting with a unix system. A lot of terminal design issues are pretty intertwined with system design and program design because that's what we used.
@b0rk (technically you shouldn't open less specifically but rather $PAGER, like how you shouldn't open nano specifically but rather $VISUAL or $EDITOR)
@alilly do you know if that’s documented anywhere? there are a million rules like that you and I have learned over the tests but I haven’t really seen them written down in one place
@b0rk It's worth noting that Eric S Raymond is a somewhat controversial figure these days, and I rarely hear about him. In the early days of corporate web explosion in the late 90s and early 2000s, a lot of us were less aware of those controversies. He was immensely influential, especially around the time of his 1999 work The Cathedral and the Bazaar.
@epilanthanomai that’s fair, maybe it’s worth taking a look at some of his writing from a historical perspective even if it doesn’t read well today
@b0rk Canonical places for config, caches, ... come to mind. Logging, too.
@b0rk Windows might be a bit of a blind spont in this consideration. CMD and powershell are generally referred to as "the terminal" in a windows context, yet they follow very few of those conventions, save for those programs that just offer the same interface as in the other environments (like say python).
I'm happy that at least with powershell we can use dashes for command flags instead of slashes :)
Maybe you clarified in a previous post that windows is not included in your meaning of "the terminal". I think that it can be helpful to include it to understand what is fundamental when learning how to operate a terminal (things that are in common).
@natpbs ah yeah I don’t know anything about Windows, i’m always talking about unix systems on here
(i have nothing against windows i just haven’t used it since 2003)
Sometimes it's the right thing to do though. You can run 'less -R' and the colour codes get passed through unmolested. Or you can redirect to a file and see the output as it was originally intended, later on.
Never when doing further processing though, of course.
@chrisgerhard
- replies
- 0
- announces
- 0
- likes
- 1
@b0rk Are you familiar with POSIX? It's an absolute behemoth of a standard, but it's basically the grandmother of unix standardization. It's wide ranging and goes into things like c system calls and threads, but it also has sections on what a shell ought to do and how tar ought to work. Modern distros don't always follow it to the letter, but it's definitely still a common starting point that system devs usually try to stay at least somewhat rooted in.
@epilanthanomai i mean I know POSIX exists but it’s not clear to me that reading it is a good use of time
@b0rk General rules for option processing are in POSIX. Sadly the authors of popular argument parsing libraries sometimes think they know better and/or reinvent the wheel with fewer corners. clap (the Rust library) is particularly bad.
@b0rk A lot of these conventions were explicit products of the GNU project in the mid-80s. The developers started from the outside of Unix and worked their way inward, so they created some libraries (`getopt`, `readline`, etc) to standardise the user experience from the command line as much as possible, and they got involved in the POSIX committees to try and define a "nicer" Unix than the hodgepodge that existed at the time.
They couldn't fix `find` or `dd` syntax much, but they did a good job of convincing people of a few obvious good practices there.
@b0rk I didn't really get "into" Unix until the early 90s (I was a rote user before then), but at that time it was common for you to have your vendor's commands as awkward old-fashioned things that you slowly supplanted with more comfortable stuff in `/opt/gnu/bin/` or similar. It's one reason that the Linux kernel kind of came as a surprise: most folks thought of GNU as add-on upgrade "utilities" rather than a fully-fledged OS project.