Live data from Hacker News

12 Factor CLI Apps

medium.com

131–140 of 253 posts

Re: 12 Factor CLI Apps

#131

Earlier quoted context omitted.

> Sometimes I end up passing the help output through grep, then copy-pasting the flags from the output, and then hoping I got the right flag. man x | grep -P y -C 3 | less ...is my standard here (-C 3 includes the pre- and succeeding 3 lines). For all the delights of CLIs, man pages are by default opaque walls of text. And dear lord the number of regex variants... - at this point, if at all possible, I'll avoid appli…

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

IIRC you don't need to pipe to less at all for that - man already supports it. grep -C gives a good summary of the various options, then you can just pull up the man page and use that selfsame search to get details that might've been cut off.

Re: 12 Factor CLI Apps

#132

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…

Powershell made 2 things gospel and I'm just sad it's going to take 20 years for other operating systems to realize that's the way to do it and something that replaces linux to see it in practice (i.e. it just won't) 1. Auto-complete is by-design part of the language/shell 1. Pre-approved Verb list that prefix commands helps discoverability and usability no end. Still learning? Get- will literally never cause a probl…

I find PS tab complete to be sub par compared to fish. It’s too aggressive when there are multiple completions.

Re: 12 Factor CLI Apps

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

Re: 12 Factor CLI Apps

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

Correct, and if stdin is not a tty it should error out instead of prompting

Re: 12 Factor CLI Apps

#135
post #110

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…

I think that the solution is clear, make a language server for the command line. Each and every single command line interface is its own language so they all need their own language server that can provide meaningful completions. Then bash and other shells can add support for language servers and we have the problem solved.

I imagine this to be a little bit over the top in most cases. A standard flag like --complete-rahyeiB1 (with a sufficiently long random string to avoid collisions with existing flags) which takes the already written argument list as an argument and prints possible completions would be nice though.

Re: 12 Factor CLI Apps

#136

Also on Color. Don't got go all pschadelic. I've found that some programs using 256-color is unreadable with my terminal colors. Also unix commands tend to have illegible colors in Powershell on Windows. (Ripgrep for example). Powershell defaults to a blue background.

Can you suggest a better default color configuration for ripgrep? We actually already have different default colors for Windows as opposed to unix.[1]

[1] - https://github.com/BurntSushi/ripgrep/blob/acf226c39d7926425...

Re: 12 Factor CLI Apps

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

As you're getting mostly replies agreeing - I never read man pages. I look up the odd parameter every now and then though.

Re: 12 Factor CLI Apps

#138

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.

Correct, and if stdin is not a tty it should error out instead of prompting

The one thing missing from the example is a little more contextual help. Not only should it prompt you for the stage, it should say “use --stage [development|staging|production] on the command line to skip this prompt” or some such. (Could be as terse as the prompt reading “please specify --stage”.)

Re: 12 Factor CLI Apps

#139

Earlier quoted context omitted.

How do you search for a word inside the whole info documentation of a program (say, gcc), and cycle through all appearances of that word? I never managed to do that (which is trivial for manpages).

Don't know how it works in regular info browser; in Emacs's info browser, incremental search can cover the entire manual (or even all info pages) if it fails to find a phrase on the page you're currently viewing.

It does, see `info '(info) Search Text'`.

Re: 12 Factor CLI Apps

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

> I don't know where this is coming from

From people who don't know how to use man pages.

Post reply on HN