"Rules" that terminal programs follow
1–10 of 153 posts
Re: "Rules" that terminal programs follow
#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 stream. Anything meant for the user to read on the terminal is supposed to go there. Error messages are of course included in that set but so are status messages and verbose output.
This ensures the output of programs can be piped into other programs seamlessly. Non-output data still gets sent to the terminal or redirected somewhere else.
Would have been great if programs were able to easily create new terminal-connected file descriptors for specific purposes. They could document those numbers in their manuals just like they document exit codes. Then users would get "ports" for every output. Could cut down on parsing significantly.
For compatibility, they could all redirect to either standard output or standard error by default... I think I'm gonna experiment with this a bit.
Re: "Rules" that terminal programs follow
#3Nice 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.
Re: "Rules" that terminal programs follow
#4> 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.
Re: "Rules" that terminal programs follow
#5> 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.
Yeah, naming is hard. If there is a better word for "non-output", I don't know it.
Re: "Rules" that terminal programs follow
#6Earlier quoted context omitted.
I'm not sure I like the "standard user stream" name, but I otherewise agree with everything here.
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.
Re: "Rules" that terminal programs follow
#7Earlier 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.
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!
Re: "Rules" that terminal programs follow
#8> 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
Re: "Rules" that terminal programs follow
#9I'd add "long-running processes should reload their configuration on SIGHUP". :)
Re: "Rules" that terminal programs follow
#10Nice 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.
[deleted]