5 ms·

I agree. Seeing the next generation of terminal apps that often seem to use "pretty" and "fancy" output formatting (read: "non-parseable" and "overly-decorated"

I agree. Seeing the next generation of terminal apps that often seem to use "pretty" and "fancy" output formatting (read: "non-parseable" and "overly-decorated") makes me sad. Plain, simple, human-readable, and machine-parseable output can't be beat in my mind.

touisteur 4y ago
I'll take two examples of interesting TUIs I've enjoyed over the years: - clonezilla boots by default to a very simple tui, in the vein of make menuconfig on Linux. You can forward, backward, see all options, expert or simple, and check or uncheck them, and get some contextual help. Once you've set up everything, you can start cloning (or restoring) and it gives you simple progress bars. But before you start it gives you the command-line you can just run next time you want to do the exact same operation, which is quite handy... - AFL (the fuzzing tool) renewed the interest (to me at least) in 'progress TUIs'. Fuzzing can be very long and there are many things that usually flby2go well at first, so you want a dashboard and AFL provides one. Bonus: it's quite fun to look at and you end up trying to optimize some metrics (like the number of fuzzing cases per second...) since the TUI taunts you. For long-term monitoring AFL also maintains TSV files, with gnuplot scripts, but the UI makes the tool fun to use (doesn't hurt that AFL was so easy to use and landed crashes real quick). Praised be Michał Zalewski, aka lcamtuf. Both have an optional TUI that make the user experience so much more powerful (sorry I know we're nitpicking the word today...).
dymk 4y ago
Human-readable and machine-readable: not the same thing in the general case. Hence -porcelain and friends.
bigyikes 4y ago
I think there’s room for two categories of terminal apps. “Library” apps, and “User” apps. Library apps are intended to be consumed by other terminal apps, or by advanced users. User apps are strictly intended for humans. Take ffmpeg as an example. This is an excellent “library” app, so much that there are many actual libraries that are thin wrappers around it. It’s incredibly versatile. Do I want to interact with ffmpeg, though? For one-off tasks, no, I’ll just fire up VLC or some other tool instead of reading the ffmpeg man pages. Friendly, stylized, non-parseable, “user” terminal apps are a comfortable middle ground between hard-core “library” apps and full-on GUI apps.
- diarrhea 4y ago
  Git follows this model as well, calling it porcelain and plumbing (the internals). Arguably, there’s a third layer in actual GUIs wrapping the porcelain (and sometimes plumbing).
- Beltalowda 4y ago
  ffmpeg specifically is a bit of an outlier; together with some other tools like qemu. For the rest of things, you can go a long way by just aligning things nicely, indentation, wrapping/indenting properly according to the terminal width, and maybe adding a bit of bold text which is both easily parsed by machines and human readable. I generally think these are often considerably more user-friendly than outputting 6 different colours – half of which don't work well on many background colours so it's unreadable – assuming the terminal is 290 characters wide – many tools these days seem to think you've got infinitely wide screens – and all the other things these "modern" things do. Something like "df" is a simple but classic example; GNU df at least aligns nicely no matter the column sizes (some other dfs, like NetBSD df, don't) and that's still easily used by machines and humans. Maybe -h should be the default though (which would break scripts, so it can't be changed for /usr/bin/df, but in an ideal world...) Basically, you can have your cake and eat it too.
mrighele 4y ago
Not all console programs are meant to be batch tools whose output needs to be piped and parsed. Sometimes you need an interactive tool and you may want to run then in a console. Emacs is an example
- chriswarbo 4y ago
  Yet Emacs is commonly run as a batch tool, whose output needs to be piped and parsed! For example, web sites which are generated via org-mode (I used to do this, about a decade ago). My Emacs config has unit tests, which are run via a non-interactive command (since tests are meant to find problems, and I don't want those problems to 'infect' the Emacs process I'm using for work)
capitol_ 4y ago
More and more terminal apps come with a --json parameter, so that their output can be easily machine parseable. Cramming output intended for humans, and output intended for data transfer between processes into the same format makes the lives of both groups of recipients worse.
indymike 4y ago
It's pretty common to write terminal apps so that if they are connected to a pipe, they use raw text that is very parsable, and if they are hooked up to a tty, they present a user experience that is much more human friendly. There is great value to both modes of operation.
- shabble 4y ago
  you might be (unintentionally) conflating CLI tools with TUI ones. CLI by and large treat the terminal as something to read/write lines to, with maybe some rudimentary interaction support like redrawing the same line for a progress bar etc. TUI use the various positioning and mode configuration escape sequences of the terminal to (typically) display "full-screen" applications within a terminal. Vim/Emacs would be obvious examples, or any of the Curses-based menu-ish systems. Try piping vim (not in batch mode) to a pager, and it doesn't really know what to do. There is some middle-ground, Github's `gh' command will use a TUI-lite interactive menu prompts for various parameters if omitted, but can run non-interactively and be piped / folded / mutilated etc if the appropriate args are given.
  - indymike 4y ago
    Not conflating anything. For example, systemctl will present results in a less/more like ui which is more tui than cli. gh is interactive, but it's about as TUI as a CS120 print and input exercise (and not much more advanced than a progress bar). There are a bunch of tools though (XXXcat type programs, systemctl, file transfer clients, mail clients) that go full TUI when invoked without CLI only parameters. There are even GUI apps that can be invoked from the CLI and run without the GUI. It's really common in unixland. What is awesome is to see interest in TUIs again. They are so productive.

touisteur 4y ago

I'll take two examples of interesting TUIs I've enjoyed over the years: - clonezilla boots by default to a very simple tui, in the vein of make menuconfig on Linux. You can forward, backward, see all options, expert or simple, and check or uncheck them, and get some contextual help. Once you've set up everything, you can start cloning (or restoring) and it gives you simple progress bars. But before you start it gives you the command-line you can just run next time you want to do the exact same operation, which is quite handy... - AFL (the fuzzing tool) renewed the interest (to me at least) in 'progress TUIs'. Fuzzing can be very long and there are many things that usually flby2go well at first, so you want a dashboard and AFL provides one. Bonus: it's quite fun to look at and you end up trying to optimize some metrics (like the number of fuzzing cases per second...) since the TUI taunts you. For long-term monitoring AFL also maintains TSV files, with gnuplot scripts, but the UI makes the tool fun to use (doesn't hurt that AFL was so easy to use and landed crashes real quick). Praised be Michał Zalewski, aka lcamtuf. Both have an optional TUI that make the user experience so much more powerful (sorry I know we're nitpicking the word today...).

dymk 4y ago

Human-readable and machine-readable: not the same thing in the general case. Hence -porcelain and friends.

bigyikes 4y ago

I think there’s room for two categories of terminal apps. “Library” apps, and “User” apps. Library apps are intended to be consumed by other terminal apps, or by advanced users. User apps are strictly intended for humans. Take ffmpeg as an example. This is an excellent “library” app, so much that there are many actual libraries that are thin wrappers around it. It’s incredibly versatile. Do I want to interact with ffmpeg, though? For one-off tasks, no, I’ll just fire up VLC or some other tool instead of reading the ffmpeg man pages. Friendly, stylized, non-parseable, “user” terminal apps are a comfortable middle ground between hard-core “library” apps and full-on GUI apps.

diarrhea 4y ago
Git follows this model as well, calling it porcelain and plumbing (the internals). Arguably, there’s a third layer in actual GUIs wrapping the porcelain (and sometimes plumbing).
Beltalowda 4y ago
ffmpeg specifically is a bit of an outlier; together with some other tools like qemu. For the rest of things, you can go a long way by just aligning things nicely, indentation, wrapping/indenting properly according to the terminal width, and maybe adding a bit of bold text which is both easily parsed by machines and human readable. I generally think these are often considerably more user-friendly than outputting 6 different colours – half of which don't work well on many background colours so it's unreadable – assuming the terminal is 290 characters wide – many tools these days seem to think you've got infinitely wide screens – and all the other things these "modern" things do. Something like "df" is a simple but classic example; GNU df at least aligns nicely no matter the column sizes (some other dfs, like NetBSD df, don't) and that's still easily used by machines and humans. Maybe -h should be the default though (which would break scripts, so it can't be changed for /usr/bin/df, but in an ideal world...) Basically, you can have your cake and eat it too.

mrighele 4y ago

Not all console programs are meant to be batch tools whose output needs to be piped and parsed. Sometimes you need an interactive tool and you may want to run then in a console. Emacs is an example

chriswarbo 4y ago
Yet Emacs is commonly run as a batch tool, whose output needs to be piped and parsed! For example, web sites which are generated via org-mode (I used to do this, about a decade ago). My Emacs config has unit tests, which are run via a non-interactive command (since tests are meant to find problems, and I don't want those problems to 'infect' the Emacs process I'm using for work)

capitol_ 4y ago

More and more terminal apps come with a --json parameter, so that their output can be easily machine parseable. Cramming output intended for humans, and output intended for data transfer between processes into the same format makes the lives of both groups of recipients worse.

indymike 4y ago

It's pretty common to write terminal apps so that if they are connected to a pipe, they use raw text that is very parsable, and if they are hooked up to a tty, they present a user experience that is much more human friendly. There is great value to both modes of operation.

shabble 4y ago
you might be (unintentionally) conflating CLI tools with TUI ones. CLI by and large treat the terminal as something to read/write lines to, with maybe some rudimentary interaction support like redrawing the same line for a progress bar etc. TUI use the various positioning and mode configuration escape sequences of the terminal to (typically) display "full-screen" applications within a terminal. Vim/Emacs would be obvious examples, or any of the Curses-based menu-ish systems. Try piping vim (not in batch mode) to a pager, and it doesn't really know what to do. There is some middle-ground, Github's `gh' command will use a TUI-lite interactive menu prompts for various parameters if omitted, but can run non-interactively and be piped / folded / mutilated etc if the appropriate args are given.
- indymike 4y ago
  Not conflating anything. For example, systemctl will present results in a less/more like ui which is more tui than cli. gh is interactive, but it's about as TUI as a CS120 print and input exercise (and not much more advanced than a progress bar). There are a bunch of tools though (XXXcat type programs, systemctl, file transfer clients, mail clients) that go full TUI when invoked without CLI only parameters. There are even GUI apps that can be invoked from the CLI and run without the GUI. It's really common in unixland. What is awesome is to see interest in TUIs again. They are so productive.