Exploring CLI Best Practices
Great advice on the whole!<p><i>&gt; 3. Use common command line options.</i><p>The GNU options standards are good, but see also the &quot;Command-Line Options&quot; chapter in &quot;The Art Of Unix Programming&quot; for some of the reasoning and history behind these conventions. Actually -- if you&#x27;re writing unix programs often, do yourself a favor and read all of TAOUP. It really helps crystallize the Unix Philosophy in a way that a grab bag of suggestions doesn&#x27;t.<p><a href="http:&#x2F;&#x2F;www.catb.org&#x2F;esr&#x2F;writings&#x2F;taoup&#x2F;html&#x2F;ch10s05.html" rel="nofollow">http:&#x2F;&#x2F;www.catb.org&#x2F;esr&#x2F;writings&#x2F;taoup&#x2F;html&#x2F;ch10s05.html</a><p><i>&gt; 4. Provide options for explicitly identifying the files to process.</i><p>Lots of options pointing to different files is a CLI smell. If your program &quot;does one thing and does it well&quot; (the Unix Philosophy), it often works like a filter: take one or more input files, apply the same transformation to them, output the result. `cat`, `head`, `tail`, `grep`, `cut`, `sort`, `join`, `sed`, `gzip`, `tar`, `cc`, `curl`, `md5sum` -- at the heart of all these programs is a unix filter.<p>In this case, just have your program accept input files as positional arguments beyond the last option. A nice side effect is that your program will be `find | xargs` -friendly. That puts the user in total control of the inputs. It also means they can parallelize your program with `xargs -P`!<p>Also consider whether you need input files at all! Can your unix filter program just transform stdin to stdout? If so, it can be used to process streams of data much larger than available disk space. Often you can trick programs that require a file argument by passing `&#x2F;dev&#x2F;stdin`, but note that `&#x2F;dev&#x2F;stdin` won&#x27;t be accessible in some environments.<p><i>&gt; 8. Don&#x27;t go for a long period without output to the user... Outputting something like ’Processing…’ can go a long way toward reassuring the user that their command went through.</i><p>I get the reasoning behind this, but as a heavy CLI user I&#x27;d prefer if programs didn&#x27;t crap progress all over the terminal by default. If I want verbose progress, I&#x27;ll pass `-v`. If I want even more insight into what&#x27;s happening, I&#x27;ll pass `-v -v`.<p>See Rule Number 11 in TAOUP:<p><i>Rule of Silence: When a program has nothing surprising to say, it should say nothing.</i><p><a href="http:&#x2F;&#x2F;www.catb.org&#x2F;esr&#x2F;writings&#x2F;taoup&#x2F;html&#x2F;ch01s06.html" rel="nofollow">http:&#x2F;&#x2F;www.catb.org&#x2F;esr&#x2F;writings&#x2F;taoup&#x2F;html&#x2F;ch01s06.html</a><p><i>&gt; 10. For long running operations, allow the user to recover at a failure point if possible.</i><p>One way to perform a sequence of expensive steps iff they haven&#x27;t been done yet (&quot;recover at failure points&quot;): orchestrate it with a Makefile.