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

101–110 of 253 posts

Re: 12 Factor CLI Apps

#101

Post by oblio »

de_watcher wrote: post #64
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…

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

Re: 12 Factor CLI Apps

#102

Post by dkersten »

dickeytk wrote: post #54
jstanley wrote: post #48

> Error: EPERM - Invalid permissions on myfile.out > Cannot write to myfile.out, file does not have write permissions > Fix with: chmod +w myfile.out I actually much prefer: "can't write myfile.out: Permission denied" This shows the same information as the first 2 lines combined from the example, and the 3rd line is not necessarily the correct way to fix the problem anyway (e.g. you might be running it as your user w…

A few things to unpack here. First, this is just an example. A real world scenario would be something domain specific. Maybe I could come up with a better contrived example here. Still, conceivably the app could check the file owner before showing the message. If it was a common enough error, it might be useful to do something like this. There is a difference between an error title and error description. The descript…

Its easier to google a terse one-line error than a multi line error.

Re: 12 Factor CLI Apps

#103

Post by dickeytk »

dkersten wrote: post #102
dickeytk wrote: post #54

Earlier quoted context omitted.

A few things to unpack here. First, this is just an example. A real world scenario would be something domain specific. Maybe I could come up with a better contrived example here. Still, conceivably the app could check the file owner before showing the message. If it was a common enough error, it might be useful to do something like this. There is a difference between an error title and error description. The descript…

Its easier to google a terse one-line error than a multi line error.

That's what the error code is for

Re: 12 Factor CLI Apps

#104

Post by scbrg »

dickeytk wrote: post #46
stepvhen wrote: post #9

> I would skip man pages are they just aren’t used that often anymore. I understand that man pages might represent a minority, but I cannot express enough how wonderful it is to get the full manual of a program without interfacing with the web. Not to mention how powerful that is, since most apps have short names that are difficult to search for, but how accessible that makes the application.

For people that like man pages (there appears to be lots of you) do you think that man pages are more important than web or in-cli docs? Or just that they should be written in addition to and not missed out on? My (current) position is that they're useful, but not worth the extra effort for most CLIs. It's a cost-benefit thing. I'm genuinely curious as I've never had anyone request man pages in our CLI.

I see no benefit whatsoever to web docs over man pages. man pages are immediately available, where you are (the CLI) without an internet connection or a web browser.

I expect the -h flag to give me a summary of the flags and arguments, to remind me of the particular name of the flag I'm missing. I most certainly don't want the whole documentation there, partly because the whole documentation is (presumably) large enough to scroll my history off screen.

So, yes, man pages are definitely more important than web or in-cli docs.

Re: 12 Factor CLI Apps

#105

Post by scbrg »

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`?

apropos

Re: 12 Factor CLI Apps

#108

Post by superlevure »

kjaer wrote: post #107
superlevure wrote: post #106

Does someone has the name of the terminal app used in the article ? (with the nice colored path)

It looks like zsh with the Oh My Zsh [1] with the Agnoster theme [2]. 1. https://ohmyz.sh/ 2. https://github.com/robbyrussell/oh-my-zsh/wiki/Themes#agnost...

Thank you !

Re: 12 Factor CLI Apps

#110

Post by Meai »

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…

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