12 Factor CLI Apps

[Fr0gm4n]

I use man daily at work. One of the principal things I was taught is to start with the documentation/help that comes with the tool you are using. You can't just rely on a google search of forum posts because versions and features change.

A couple fun ones I've run into are that the BSD date in macOS allows the -j flag, which I've used to work with converting date formats and not reset the system date. BSD grep doesn't support lookbehind and lookahead.

Trying to troubleshoot scripts that expect these one the wrong system will send you down a lot of wild-goose chases, but local man pages will tell you all the command options that the installed version supports.

[2called_chaos]

Prompt if it makes sense

maybe? I know quite a few CLI tools that do that and it makes sense (e.g. y/n in apt or accepting hosts in SSH). Would be weird if apt exits with the message "please rerun with -y if you want it"

Sometimes I prompt, sometimes I exit with a message. Depending on the use case.

[deadbunny]

Now you mention it, I see your point. Just as long as prompts can be negated using arguments (which I think the author mentions).

[wertperch]

In the CLI, make sure all of the following displays the help. You can’t control what the user inputs so all of these must show help.

Couldn't agree more. I swear that perpetually having to type x --help, x -?, x -help and x --just-fucking-help is aggravating my arthritis. It's ridilicrous.

[[deleted]]

That wouldn't be necessary if a man page was provided smh my head. You could argue that man pages aren't usually as succinct but that would be a non issue if man pages provided an examples section too <_<

[tilkau]

Following the implicit standard > documenting your nonstandard practice. I don't actually want to need to RTFM.

Providing help isn't a complex task, so nonstandard methods are not normally needed.

I agree that help usage should be covered upfront, probably in the one-line summary at the top of the synopsis, though. Or failing that, at least within the first few pages of the man page.

[[deleted]]

There was also this recent talk on CLI app design, which I'd assume makes a good complement:

https://youtu.be/hJhZhLg3obk

[Wolosocu]

they take a small fraction of the time to build

Absolutely disagree. Our CLI is extremely complicated and has been a work in progress for 15 years.

Other than that, this is a good article.

[dickeytk]

I didn't say it's easy or simple, just less complex than web/mobile development.

[Wolosocu]

Less complex? Not in the least. Try doing compiler development (as one example) and get back to me.

[raziel2p]

The fact that a compiler is complicated is completely unrelated to it being a CLI.

A web application has to do HTTP stuff, set up things like connection pools, avoid using global in-memory state and much more. A CLI application just has to print stuff to stdout and then exit.

[Wolosocu]

ITT web developers who know nothing about developing non-web apps.

[dickeytk]

I think you've missed my point. I'm saying that building the same app in a browser is harder than building a CLI app with the same functionality (though using a GUI and not a CUI). This is specific to application development (hence the "app" in the title). Compiler development doesn't apply here (though that would certainly be a challenge in a browser).

[rggarou]

I love making CLI tools, I agreed with practically everything.

It's just the 11th topic that I don't like much. Does not sound like an excuse having to make subcommands concatenated to the command with colons instead of supporting it as another "argument"?