<story><title>Tell HN: Please don&apos;t print –-help to stderr in your CLI tools</title><text>Imagine you get a lengthy help description which then you pipe to less.. and you only get (END) in your terminal. Turns out the author decided to print help message to stderr instead of stdout. I assume newcomers will be as confused as I was when it happened to me for the first time. GNU utils use stdout for help texts, and so should you.</text></story><parent_chain><item><author>dingosity</author><text>This is going to sound snotty, and I&amp;#x27;m not really trying to be, but... Unix and its derivatives were made for people who sort of knew what they were doing.  The reason you pipe exceptional events to STDERR is so the STDOUT output, if it exists, can flow into the next command in the pipe.  Asking for help is an exceptional event.  If you want the error output of a Unixish (linux, macos, solaris, etc.) machine running bash to be lessable, re-direct it to STDOUT with `2&amp;gt;&amp;amp;1`.  You probably shouldn&amp;#x27;t be touching the shell if you don&amp;#x27;t know what that does.  These tools were developed assuming the users would have a basic understanding of the system they were running on.&lt;p&gt;The GNU Project has published tools of varying quality, based on who was around to write the tool, debug it, give feedback, etc.  It is not the exemplar of high quality software.  (But it&amp;#x27;s far from crap.)  The important bit about GNU (and any other software) is that it was written to adhere to their uses.  Other people have different requirements.  Telling people to &amp;quot;write your software like GNU writes their software&amp;quot; is to misunderstand personal agency and one of the major points of open source software.&lt;p&gt;Your comments sound like you&amp;#x27;re saying &amp;quot;Software freedom means you&amp;#x27;re free to write software the way I want you to write software.&amp;quot;&lt;p&gt;No thank you.</text></item></parent_chain><comment><author>figmert</author><text>Sure, but adding --help to a command means that the output of help is &lt;i&gt;not&lt;/i&gt; exceptional, thus you&amp;#x27;re expecting it in stdout. If on the other hand you invoke the command incorrectly, and the author decides the best thing to do is print out the help in such cases, then yes, it should be stderr.</text></comment>
<story><title>Tell HN: Please don&apos;t print –-help to stderr in your CLI tools</title><text>Imagine you get a lengthy help description which then you pipe to less.. and you only get (END) in your terminal. Turns out the author decided to print help message to stderr instead of stdout. I assume newcomers will be as confused as I was when it happened to me for the first time. GNU utils use stdout for help texts, and so should you.</text></story><parent_chain><item><author>dingosity</author><text>This is going to sound snotty, and I&amp;#x27;m not really trying to be, but... Unix and its derivatives were made for people who sort of knew what they were doing.  The reason you pipe exceptional events to STDERR is so the STDOUT output, if it exists, can flow into the next command in the pipe.  Asking for help is an exceptional event.  If you want the error output of a Unixish (linux, macos, solaris, etc.) machine running bash to be lessable, re-direct it to STDOUT with `2&amp;gt;&amp;amp;1`.  You probably shouldn&amp;#x27;t be touching the shell if you don&amp;#x27;t know what that does.  These tools were developed assuming the users would have a basic understanding of the system they were running on.&lt;p&gt;The GNU Project has published tools of varying quality, based on who was around to write the tool, debug it, give feedback, etc.  It is not the exemplar of high quality software.  (But it&amp;#x27;s far from crap.)  The important bit about GNU (and any other software) is that it was written to adhere to their uses.  Other people have different requirements.  Telling people to &amp;quot;write your software like GNU writes their software&amp;quot; is to misunderstand personal agency and one of the major points of open source software.&lt;p&gt;Your comments sound like you&amp;#x27;re saying &amp;quot;Software freedom means you&amp;#x27;re free to write software the way I want you to write software.&amp;quot;&lt;p&gt;No thank you.</text></item></parent_chain><comment><author>unflxw</author><text>&amp;gt; This is going to sound snotty&lt;p&gt;The word you’re looking for is “condescending”.&lt;p&gt;Regardless, there is no argument about software freedom to be made here.&lt;p&gt;You’re allowed, be it open or close source, to write and publish software that defies common, well-established conventions.&lt;p&gt;You can pretend that it’s some sort of first amendment right to do so if you like, and attempt to deflect your unwillingness to write software that behaves properly as incompetence on the users’ end.&lt;p&gt;But whether anyone will be convinced by that is a separate question, and those who aren’t convinced certainly have the right to tell you, in turn, that your software sucks. This does not inflige on your rights to write broken software.</text></comment>