Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

12 Factor CLI Apps

medium.com

Post reply on HN
Print view View original

201–210 of 253 posts

Re: 12 Factor CLI Apps

#201

Post by boomlinde »

jessaustin wrote: post #191
boomlinde wrote: post #188

Earlier quoted context omitted.

User friendly until the user decides to invoke that command in a cron job and ends up with a headless process waiting for additional input.

Anyone who doesn't test cron jobs before saving them deserves whatever she gets. There are scores of ways for cronjobs to fail. b^)

Well, this is not a cronjob that failed, it's just waiting for input.

Let's say that I did test the cronjob but that it starts "failing" after an update to the tool. My fault, I know, but at least I get mail when it fails while I won't if it's just waiting for input.

Re: 12 Factor CLI Apps

#202

Post by oblio »

Retra wrote: post #170
oblio wrote: post #101

Earlier quoted context omitted.

But done the right way. With autocompletion based on your frequent searches, recent searches, machine learning based suggestions using what the whole internet searches, etc. It's qualitatively different from your average CLI experience. As such, I don't think you can actually compare the two.

It is a command-based line-input UI. Just because it is different in other ways doesn't mean it a comparison is unwarranted.

My argument was that the "other ways" it is different in are more important than the similarities.

Re: 12 Factor CLI Apps

#203

Post by 013a »

curun1r wrote: post #22
013a wrote: post #10

This is all great advice. The one thing this does miss is distribution, which is a HUGE part of offering a great CLI app. Specifically, I'd say: 1. Make your OFFICIAL distribution channel the primary package manager on each platform (ex: on Mac, homebrew. Ubuntu, apt/snap). Beyond that, support as many as you have capacity to. 2. Also offer an official docker image which fully encapsulates the CLI tool and all of its…

Homebrew is NOT the primary package manager on Mac and I wish people would stop perpetuating that falsehood. Apple includes pkgutil/pkgbuild in the OS and that official package management strategy plays much better with corporate IT control of managed machines. In my experience, Homebrew always eventually results in pain and complex debugging and it's almost impossible to audit software it installs to prevent the ins…

Thank you for your opinion. I'm going to continue using homebrew and encouraging developers to support it.

Re: 12 Factor CLI Apps

#204

Post by scbrg »

oblio wrote: post #120
bayindirh wrote: post #85

I don't agree with 7 and 8. I like silent apps while working, and actually I'm used to applications saying nothing if everything is correct. Also, "outputting something to stdout just because I can" kills scriptability a lot. Using tables, colors and other stuff requires a lot of terminal support. MacOS terminal, iTerm, Linux terminals supports a lot of stuff, but not always (our team is generally using XTerm for exa…

You can just have a "quiet" mode for scripting. Or even better, detect if you're connected to a TTY.

I run scripts from a tty all the time...

Re: 12 Factor CLI Apps

#205

Post by 013a »

cpburns2009 wrote: post #151
013a wrote: post #10

This is all great advice. The one thing this does miss is distribution, which is a HUGE part of offering a great CLI app. Specifically, I'd say: 1. Make your OFFICIAL distribution channel the primary package manager on each platform (ex: on Mac, homebrew. Ubuntu, apt/snap). Beyond that, support as many as you have capacity to. 2. Also offer an official docker image which fully encapsulates the CLI tool and all of its…

Why would you put a CLI tool in a docker instance? I'd understand if it were a server environment or web application.

> This can be a great way to get a CLI tool loaded into a bespoke CI environment.

Re: 12 Factor CLI Apps

#206

Post by jessaustin »

boomlinde wrote: post #199
jessaustin wrote: post #189

Earlier quoted context omitted.

So you want the script to [EDIT:] exit with an error code rather than hanging around waiting for input? That seems possible, with some sort of generous (e.g. 5 minutes) exit timer on the prompt. Would that satisfy your concerns? If not, what else is needed here? ps. the verb "considered" is a good sign that this is an opinion, and would be even in a more "active" sentence.

First of all I think "crash" is the wrong word here. Unix tools commonly exit gracefully with an error code when the argument requirements are not met. Often with an informative error message. A five minute pause sounds ridiculous to me, absolutely not user friendly from either end. It's jus unpredictable and time wasting. If you absolutely must, you can use 'isatty' to check whether stdin/stdout/stderr are connected…

Checking for the tty is discussed in TFA and in sibling comments.

Re: 12 Factor CLI Apps

#207

Post by twic »

ajross wrote: post #196
JepZ wrote: post #121

> 7. Prompt if you can Please don't. There is nothing wrong with interactive tools, but by default, they should not be. So instead of making non-interactive session possible via flags, the default should be to be non-interactive. If there is an option to start an interactive session, everything is fine. Otherwise, you would never know when your script could run into some kind of interactive session (and therefore bre…

The suggestion was to prompt if stdin was a TTY and the default behavior would have been to exit with a usage error. I think it's a fine suggestion, though in 94% of cases probably too much work to be worth it.

I think detecting whether stdin is a TTY is a huge antipattern. Most of the time, it works, but now and then, you either want to run an interactive session in a situation where stdin appears not to be a TTY, or a batch session in a situation where it appears to be. Plus, it means there's twice as much surface area to learn.

EDIT: remove rogue 'not'

Re: 12 Factor CLI Apps

#208

Post by another-cuppa »

JepZ wrote: post #121

> 7. Prompt if you can Please don't. There is nothing wrong with interactive tools, but by default, they should not be. So instead of making non-interactive session possible via flags, the default should be to be non-interactive. If there is an option to start an interactive session, everything is fine. Otherwise, you would never know when your script could run into some kind of interactive session (and therefore bre…

Prompting actually means it's no longer a CLI.

Re: 12 Factor CLI Apps

#209

Post by JdeBP »

dickeytk wrote: post #68
enriquto wrote: post #60

Earlier quoted context omitted.

I for one prefer actual manpages than online documentation. The web documentation is cumbersome to find, forces me to open a browser window, and I cannot copy-paste easily from inside my terminal. Notice that if you already have help, you can build the manpages automatically from them using "help2man". You could get manpages for all your tools by simply adding a line into your makefile!

If the man pages are simply generated from the help output, why bother having them when you can just use `--help`?

The end result argues against using help2man and thinking that --help and the user manual should be the same thing, not against having a user manual at all. (-:

* https://news.ycombinator.com/item?id=18174025

Re: 12 Factor CLI Apps

#210

Post by dickeytk »

twic wrote: post #207
ajross wrote: post #196

Earlier quoted context omitted.

The suggestion was to prompt if stdin was a TTY and the default behavior would have been to exit with a usage error. I think it's a fine suggestion, though in 94% of cases probably too much work to be worth it.

I think detecting whether stdin is a TTY is a huge antipattern. Most of the time, it works, but now and then, you either want to run an interactive session in a situation where stdin appears not to be a TTY, or a batch session in a situation where it appears to be. Plus, it means there's twice as much surface area to learn. EDIT: remove rogue 'not'

You get false positives sometimes (where it claims to not be a tty but is going to the screen), but because the fall back is just reduced functionality it never causes any issues. We make hundreds of checks like this for tty in the CLI
Post reply on HN