"Rules" that terminal programs follow • Hacker News Board

Re: "Rules" that terminal programs follow

#31

Post by packetlost » Thu, Dec 12, 2024, 9:56 PM UTC

matheusmoreira wrote: post #24

packetlost wrote: post #18

Earlier quoted context omitted.

The idea for info is that it's informational, which is always the case regardless of whether it's printing error messages due to a failure or informational messages because the user specified a `-v` flag or whatever. Whether the command failed or not is communicated via the exit code. That being said, I do prefer stdlog for the reasons: it communicates the intent and usage as unambiguously and tersely as possible.

> because the user specified a `-v` flag or whatever The way I see it is the version information and help text belong on standard output if the user passes --version and --help since that's what the user explicitly asked for. When the command is invoked incorrectly, the help text should go to standard error while standard output should be empty. I agree about the exit code. People like to parse error messages and tha…

The `-v` was in reference to the common convention of one or more `v` flags increasing the verbosity of logging.

Re: "Rules" that terminal programs follow

#32

Post by saghm » Thu, Dec 12, 2024, 9:57 PM UTC

packetlost wrote: post #4

matheusmoreira wrote: post #2

> programs should print “regular” output to stdout and errors to stderr This is really important. I'd like to expand on this. Standard output is for the data the program was asked to produce, no more and no less. If user asked for some JSON data, standard output should contain that exact JSON object and absolutely nothing else. Standard "error" is actually a misnomer. It should have been called the standard user stre…

I'm not sure I like the "standard user stream" name, but I otherewise agree with everything here.

What about "debug"? I think the important part about stderr is that it's "meta" info about how the program is running (or ran) rather than what the program is intended to produce as output. This seems pretty similar to what often is referred to as the "debug" level of logging (which includes lower levels of logging like warnings and errors).

Re: "Rules" that terminal programs follow

#33

Post by bobbiechen » Thu, Dec 12, 2024, 10:06 PM UTC

thiisguy wrote: post #25

bobbiechen wrote: post #3

Nice writeup. Since she mentioned how hard it is to learn these conventions, I'll plug my preferred reference when thinking about CLIs specifically (rather than TUIs and REPLs) - the Command Line Interface Guidelines https://clig.dev It does include the blog post's rules on exiting on Ctrl-C, accepting `-` for stdin, disabling color in pipes, and much more.

This is referenced at the very beginning, just after the table of contents.

Oops, I missed it when I was reading, and assumed it wasn't referenced. Thanks!

Re: "Rules" that terminal programs follow

#34

Post by kps » Thu, Dec 12, 2024, 10:08 PM UTC

saghm wrote: post #20

Sesse__ wrote: post #14

“rule 5.1: Ctrl-W should delete the last word […] I can’t think of any exceptions to this other than text editors but if there are I’d love to hear about them!” mysql(1) only links to editline instead of readline, where Ctrl-W by default deletes everything to the start of the line, not just the last word. It drove me mad in the period where I had to use it; you just see your entire nice query disappear. :-)

It could be worse! Back in college, I had the misfortune to decide to try to use sqlplus, Oracle's CLI to try to connect to their database. Not only did terminal shortcuts like Ctrl-W not work at all, but you couldn't even move the cursor earlier in the line, and there was no history navigation to get to the previous command, so any typo forced you to retype the entire thing from scratch. Entering a single forward sl…

It could be worse! You could be using an un‐configurable modern browser or some such thing where attempting to erase a word closes your tab.

Re: "Rules" that terminal programs follow

#35

Post by chriswarbo » Thu, Dec 12, 2024, 10:09 PM UTC

Ctrl-D for REPLs always bites me with GHCi. My usual approach to quitting GHCi is:

- Press Ctrl-D, like normal

- Get confused when nothing happens

- Remember that it doesn't work in GHCi, so run `:q` instead

- Get an error message about "lexical error at character '\EOT'", due to Ctrl-D inserting an invisible char at the start of the input

- Try `:q` again, without any invisible prefix

- GHCi successfully quits

Re: "Rules" that terminal programs follow

#36

Post by blueflow » Thu, Dec 12, 2024, 10:17 PM UTC

CorrectHorseBat wrote: post #16

[flagged]

Do an "stty -a" in the terminal - you will see these two keys are handled by the kernel itself and will also work with programs reading dumbly from stdin, like "cat".

Re: "Rules" that terminal programs follow

#37

Post by mcint » Thu, Dec 12, 2024, 10:24 PM UTC

bobbiechen wrote: post #3

Nice writeup. Since she mentioned how hard it is to learn these conventions, I'll plug my preferred reference when thinking about CLIs specifically (rather than TUIs and REPLs) - the Command Line Interface Guidelines https://clig.dev It does include the blog post's rules on exiting on Ctrl-C, accepting `-` for stdin, disabling color in pipes, and much more.

I would also recommend, call to attention, the Further Reading from CLIG, https://clig.dev/#further-reading. POSIX, GNU, Unix resources, Heroku CLI guide, and 12-factor CLI app guide.

Re: "Rules" that terminal programs follow

#38

Post by jeffrallen » Thu, Dec 12, 2024, 10:25 PM UTC

If you are a young sysadmin, take the time to.learn Emacs. Not because Emacs is good (but it is) but because deadline keys are Emacs keys, so once you know Emacs you know shell, MySQL, etc.

Play your terminal like a piano . Your livelihood depends on it.

Re: "Rules" that terminal programs follow

#39

Post by jeffrallen » Thu, Dec 12, 2024, 10:26 PM UTC

chriswarbo wrote: post #35

Ctrl-D for REPLs always bites me with GHCi. My usual approach to quitting GHCi is: - Press Ctrl-D, like normal - Get confused when nothing happens - Remember that it doesn't work in GHCi, so run `:q` instead - Get an error message about "lexical error at character '\EOT'", due to Ctrl-D inserting an invisible char at the start of the input - Try `:q` again, without any invisible prefix - GHCi successfully quits

You think that's hard, try getting out of vi when you're on a keyboard from an unfamiliar country.

Re: "Rules" that terminal programs follow

#40

Post by machinestops » Thu, Dec 12, 2024, 10:29 PM UTC

saghm wrote: post #26

model-15-DAV wrote: post #19

As an addendum to Rule 7, `cd -` takes you to the last opened directory. Or is `cd` considered part of the terminal emulator's job, as a built-in?

I don't think it's part of the terminal emulator (e.g. xterm, gnome-terminal) but the shell (bash, zsh, etc.). You're correct that it's not something that's implemented as an external program though; the "current directory" is state for a currently running terminal session, so changing that state is done via the shell interface (either directly by built-in commands like cd or indirectly via external commands that use…

Note: Child processes can't change the working directory of the parent. An external command (that is, not a shell builtin, shell function, or externally loaded module) cannot change the working directory, because they're launched as child processes.