Live data from Hacker News

12 Factor CLI Apps

medium.com

191–200 of 253 posts

Re: 12 Factor CLI Apps

#191

Earlier quoted context omitted.

My interpretation was that the prompt is for required information. In the example graphic, "run demo" really does require that "stage" be specified. This is considered more user-friendly than simply crashing. If you don't want to see the prompt, provide that information as a flag or in a config file or whatever.

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^)

Re: 12 Factor CLI Apps

#192
post #127

Earlier quoted context omitted.

If you're already piping to less, just use its search functionality; type '/', the regexp, and then enter.

For that, you might as well just use the regex functionality in man itself too. But that misses the point. The goal of grepping in that snippet is that you're `less `ing through precisely the parts that matter, and no more, rather than wading through the whole man page, and you're using -C to control how much context you (think you) need around the search results. This is a much better setup for skimming through pote…

'man' has no regex functionality; on most Unix systems, it just uses 'less' as its pager.

Re: 12 Factor CLI Apps

#193

Earlier quoted context omitted.

What do you mean by aggressive?

I don't know what they mean, but I know that I really dislike how PS's autocomplete works. If the possible commands are (for the sake of discussion) `Get-AppLockerFileInformation` and `Get-AppLockerPolicy`. If you type `Get-App` and hit Tab, it will autofill to `Get-AppLockerFileInformation` which I just really don't like, and I need to keep hitting tab to cycle through all other possible `Get-App*` commands. What I…

Actually, that isn't a PowerShell idea.

Firstly, that form of completion has existed in the Microsoft/IBM operating system world for significantly longer than PowerShell has, tabbing backwards and forwards around a list of matches being the way that one did filename completion with some MS/PC/DR-DOS tools back in the 1980s. Secondly, PowerShell ISE can do things differently, so this cannot be a PowerShell thing.

Crank up PowerShell ISE, enter "Get-App", then press Control+Space. For more, press Control+Space to complete an option after entering "-".

Re: 12 Factor CLI Apps

#194

Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them... While writing this I'm thinking on my experience trying to do anything with ffmpeg or imagemagick... or even find. * For any sufficiently complicated cmd line app, the list of arguments can be huge and the --help so terse as to be become useless. For man pages, t…

Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded.

(The following paragraph is not directed at the author of the parent post. It's fully rhetorical.)

Did you know that icons were supposed to be live representations of in-memory objects? That objects were more fundamental for the OS than files? Did you know that windows were views onto those objects? Did you know that interactions to and between icons were synonymous with OOP polymorphism?

https://www.youtube.com/watch?v=Cn4vC80Pv6Q

And this isn't the best UI, it's simply the first modern UI.

Re: 12 Factor CLI Apps

#195

Earlier quoted context omitted.

My interpretation was that the prompt is for required information. In the example graphic, "run demo" really does require that "stage" be specified. This is considered more user-friendly than simply crashing. If you don't want to see the prompt, provide that information as a flag or in a config file or whatever.

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.

It's possible to detect whether stdin or stdout is attached to a terminal, and do something different depending.

Re: 12 Factor CLI Apps

#196
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.

Re: 12 Factor CLI Apps

#197
post #127

Earlier quoted context omitted.

For that, you might as well just use the regex functionality in man itself too. But that misses the point. The goal of grepping in that snippet is that you're `less `ing through precisely the parts that matter, and no more, rather than wading through the whole man page, and you're using -C to control how much context you (think you) need around the search results. This is a much better setup for skimming through pote…

'man' has no regex functionality; on most Unix systems, it just uses 'less' as its pager.

sure, which means that it inherits regex support via less. You either have it on both, or neither.

Re: 12 Factor CLI Apps

#198

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…

> Also, "outputting something to stdout just because I can" kills scriptability a lot.

The article does specifically recommend using stderr for messages to the user, is there any reason that would kill scriptability?

Re: 12 Factor CLI Apps

#199

Earlier quoted context omitted.

> This is considered more user-friendly than simply crashing (I'm going to assume the passive voice means "the article considers this more user-friendly" rather than some sort of commonly accepted fact). I disagree with this strongly and agree with the GP -- I would much rather have the command exit with a message saying that a required parameter is missing. For example, if I have a script using a command and the com…

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 to a terminal and act accordingly.

There is some merit to having consistent and predictable behavior regardless of where and by whom the tool is invoked, though.

Re: 12 Factor CLI Apps

#200

I'm probably being picky, but I would also include that the CLI be a self-contained binary. I'm tired of managing Python / Ruby / Node versions.

Its bad both ways. The advantage to python/ruby for example is you can simply pip/gem install, or update. With a binary, you have to download, move, and change permissions every update. For experienced linux users, the binary is fine, but for newer users, its much more "friction"

IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.
Post reply on HN