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

161–170 of 253 posts

Re: 12 Factor CLI Apps

#161

Post by chriswarbo »

kpcyrd wrote: post #15

I disagree on the 2nd point. Flags prevent globbing by the shell and make the help text less clear. Consider a usage line like this: prog [password] This tells you which argument is mandatory and which argument is optional in a second, without searching for the help text of --user and --password. Also, an example like this: git add ... Tells you that git add accepts multiple paths and you can invoke it with: git add…

I don't like using arguments for key/value data, e.g. `prog --name foo`. Much better to use env vars like `NAME=foo prog`, since the OS handles the mapping automatically, reading them out is trivial in every language, passing args to subprocesses is easier, etc.

Re: 12 Factor CLI Apps

#162

Post by mxuribe »

Walkman wrote: post #83

Unless you already know your users will want man pages, I wouldn’t bother also outputting them as they just aren’t used often enough anymore. I don't know where this is coming from, me and my colleagues are reading man pages every day. I would be interested how much others read them.

Whether they're good or not, i feel manpages should ALWAYS be included every cli app. That being said, it is quite often that i begin my inquiry with manpages but then have to unfortunately look elsewhere for more info...specifically either a nice set of usage examples, or a bit more background on the "why" to use the cli app - in this order.

Re: 12 Factor CLI Apps

#163

Post by smarinov »

larkeith wrote: post #119
davidhcefx wrote: post #89

Earlier quoted context omitted.

I myself also love reading man pages, but speaking of compatibility, I have to say that “--help” is a more universal way of showing help pages. Of course it’s better to have both of them though.

--help is fine, but almost never a substitute for a full man page, except for the most trivial of applications (unless your --help is as complete as a man page, in which case... good on you for providing full documentation, but I'll hate you a bit every time I unthinkingly drop two hundred lines of text in my terminal.)

Unless it just opens the man page if it is so long. Like git.

Re: 12 Factor CLI Apps

#164

Post by dsr_ »

AnIdiotOnTheNet wrote: post #147
emmanueloga_ wrote: post #29

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…

At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome". Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily co…

Text is exact, programmable, repeatable and transmissible.

exact: in many GUI tools, you can have non-default settings that you changed via menus. Where are they stored? Which ones are currently active? Does it matter that you selected four objects first, then a transform tool, then another object?

programmable: > find /var/spool/program/data -name foop* -mtime +3d -print

vs "open the file manager, go to /var/spool/program/data, sort by name, secondary-sort by last modification time, find the ones that are more than 3 days old, make sure you don't slip"

repeatable: OK, do that again but in a different directory.

transmissible: here's the one-liner that does that.

Now, your specific requests are about audio and video toolchains, where I will admit that reasoning about flows is easier with spatial cues -- but I'd really like the output of that GUI to be an editable text file.

Re: 12 Factor CLI Apps

#165

Post by nhumrich »

sudofail wrote: post #81

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"

Re: 12 Factor CLI Apps

#166

Post by Retra »

AnIdiotOnTheNet wrote: post #147
emmanueloga_ wrote: post #29

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…

At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome". Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily co…

The command line is great because it makes it easy to automate tasks involving multiple arbitrary applications. It's why we still use it even after GUIs basically became mandatory on all user-facing computers.

Re: 12 Factor CLI Apps

#167

Post by 0x445442 »

AnIdiotOnTheNet wrote: post #147
emmanueloga_ wrote: post #29

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…

At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome". Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily co…

I think we (cli advocates) worship text because language happens to be a very powerful user interface.

What we need is a ubiquitous command interface where the output of any command is a tree set of typed objects and any command is free to consume any of those sets of typed objects. The typed objects in this pattern would not be limited to text.

This paradigm removes the restraints of GUI applications but satisfies a great many use cases with the obvious exceptions being any program that requires a lot of mouse or pointing device input like photo manipulation.

Re: 12 Factor CLI Apps

#168

Post by JdeBP »

davidhcefx wrote: post #89
kolme wrote: post #84

Earlier quoted context omitted.

I strongly disagree on this one too. That's the first place I look for help and it annoys me to no end when a CLI program that doesn't come with one. I stopped taking seriously the article at that point and quickly skimmed through the rest of it. Man pages are a great unix culture heritage, please new developers don't give up on them!

I myself also love reading man pages, but speaking of compatibility, I have to say that “--help” is a more universal way of showing help pages. Of course it’s better to have both of them though.

I strongly suspect that --help is on the contrary less universal, given that there exist entire toolsets lacking the --help convention but having manual pages. There was almost a quarter of a century's worth of Unix tools that developed before --help was invented.

* https://unix.stackexchange.com/a/416796/5132

* https://unix.stackexchange.com/questions/207136/

Re: 12 Factor CLI Apps

#169

Post by andrewla »

jessaustin wrote: post #133
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…

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.

> 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 command becomes interactive, then my script is dead; but if it simply exits then my script has failed at a repeatable point.

You could say that I should pass a "--noninteractive" flag into everything just in case, but sometimes these things aren't supported. I would much rather have an application support a "--interactive" flag to support those who want to be able to interact with the tool.

I think the two sides of this are unlikely to be able to convince each other. At least the article presents a reasonable-ish middle ground of always offering help as to the way to circumvent the interaction at the point where interaction is required.

Re: 12 Factor CLI Apps

#170

Post by Retra »

oblio wrote: post #101
de_watcher wrote: post #64

Earlier quoted context omitted.

> I'm sure we all end up using google Which is kinda a CLI application.

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.
Post reply on HN