Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Rules" that terminal programs follow

jvns.ca

Post reply on HN
Print view View original

21–30 of 153 posts

Re: "Rules" that terminal programs follow

#21

Post by ElevenLathe »

sudobash1 wrote: post #15
bombcar wrote: post #11

Earlier quoted context omitted.

You can learn the 2>&1 thing, but it would be nice if there was a feature of one of the greps to "slurp up" the error output. Of course, the real problem is there's no standard, the standards that do exist are ignored, and each new command-line tool generates a new standard.

It generally isn't possible for grep to "slurp up" the error output because stderr does not get passed through pipes (by default). This is shell behavior and grep cannot do anything about it. As a side note, some shells have started implementing a shorthand for `foo 2>&1 | grep` which is `foo |& grep`.

Probably you could do a hack like finding the program at the other end of the pipe and looking at its open file descriptors, but lots of corner cases to consider.

Re: "Rules" that terminal programs follow

#22

Post by paulddraper »

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.

I'd name it "standard log."

That's what it is....a log. Of errors, warnings, informational messages, whatever to complement the primary output.

BONUS: stdlog fits nicely :)

Re: "Rules" that terminal programs follow

#23

Post by matheusmoreira »

lionkor wrote: post #8
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…

Unless your app doesn't generate output,then grepping the output will not work if it's stderr and it will be confusing

How can you grep output if there's no output?

Can you provide a concrete example of such an application?

Re: "Rules" that terminal programs follow

#24

Post by matheusmoreira »

packetlost wrote: post #18
matheusmoreira wrote: post #7

Earlier quoted context omitted.

I think stdinfo would exclude error messages from the definition, just like stderr excludes info messages. I really like stdlog. Standard log stream is a pretty awesome name. Short and terse, the word "log" doesn't even need abbreviation and it's correct since it's a superset of error and info streams and also generic enough to cover other unforeseen categories. I'll use it from now on!

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 that's always wrong. Everything should be done via exit codes instead.

Re: "Rules" that terminal programs follow

#25

Post by thiisguy »

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.

Re: "Rules" that terminal programs follow

#26

Post by saghm »

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 those transitively).

Re: "Rules" that terminal programs follow

#27

Post by cafard »

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…

SQL*Plus is pretty basic, but L will show you the previous command, a number will give you that line of the previous command, to edit, etc.

Re: "Rules" that terminal programs follow

#28

Post by Sesse__ »

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…

If you ever need to do so again, try gqlplus, which wraps sqlplus to add such quality-of-life features :-)

Re: "Rules" that terminal programs follow

#30

Post by AndrewDucker »

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…

This is definitely one of the things that PowerShell got right. 6 different streams, each of which can be intercepted separately and configured differently.

https://learn.microsoft.com/en-us/powershell/module/microsof...

Post reply on HN