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

11–20 of 153 posts

Re: "Rules" that terminal programs follow

#11

Post by bombcar »

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

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.

Re: "Rules" that terminal programs follow

#12

Post by ryandrake »

packetlost wrote: post #6
matheusmoreira wrote: post #5

Earlier quoted context omitted.

Yeah, naming is hard. If there is a better word for "non-output", I don't know it.

I would maybe call it stdlog or stdinfo vs stderr, but yeah naming things is hard.

C++ has std::clog[1], but it's basically cerr, and the OS still only knows about stdin, stdout, and stderr.

1: https://cplusplus.com/reference/iostream/clog/

Re: "Rules" that terminal programs follow

#14

Post by Sesse__ »

“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. :-)

Re: "Rules" that terminal programs follow

#15

Post by sudobash1 »

bombcar wrote: post #11
lionkor wrote: post #8

Earlier quoted context omitted.

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

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`.

Re: "Rules" that terminal programs follow

#18

Post by packetlost »

matheusmoreira wrote: post #7
packetlost wrote: post #6

Earlier quoted context omitted.

I would maybe call it stdlog or stdinfo vs stderr, but yeah naming things is hard.

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.

Re: "Rules" that terminal programs follow

#20

Post by saghm »

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 slash would allow you to run the last command verbatim, but that didn't help with typos. Ctrl-L also didn't work for clearing the screen, but you could manually run `clear scr` to do it instead, because I guess having the command just be `clear` wouldn't be obvious enough.
Post reply on HN