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

91–100 of 253 posts

Re: 12 Factor CLI Apps

#91

Post by majewsky »

dickeytk wrote: post #55
Beowolve wrote: post #51

Earlier quoted context omitted.

So, I understand the basis of your comment. You have the knowledge to know that there are other things that may be "the right way" given your situation. I think what the author is getting at is that there are users who don't have that knowledge. Giving them a hint that is verbose and non arcane can make a world of difference. Speaking from personal experience, there are many developers that I have met who don't have…

yes, exactly. I think being verbose and more human friendly is a much better way to design a tool than being terse and machine friendly. Ultimately all we're doing is trying to save human time anyways.

In practice, "being verbose" is usually the opposite of "human friendly". I much prefer a spot-on one-line error message over dozens of lines of logs with an error somewhere hidden in them. Verbose error messages usually mean that you didn't have time to design succinct ones.

Joel Spolsky's timeless advice applies: "Users can’t read anything, and if they could, they wouldn’t want to." https://www.joelonsoftware.com/2000/04/26/designing-for-peop...

Re: 12 Factor CLI Apps

#92

Post by Already__Taken »

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…

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

Because of the above get-help can automatically create some fairly useful documentation right away and whoever wrote the code didn't need to do anything. They can significantly add to to help though. Because that mechanism is part of the language it's worth doing literally every user is going to access it, not some blog your wrote 5 years ago I hope is still online.

Passing objects rather than string, whatever maybe it's not the best way, I think it's great. But That's not the only thing PS has to learn from.

If anyone uses the cli and doesn't know how the PS help system works, it's certainly a breath of fresh air to learn.

Re: 12 Factor CLI Apps

#93

Post by saagarjha »

Fnoord wrote: post #35
curun1r wrote: post #22

Earlier quoted context omitted.

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…

App Store is the primary package manager on Mac (which can be used from CLI). Homebrew is the defacto standard complimentary package manager on Mac. Whether you like the fact it is the defacto standard or not is irrelevant.

> App Store is the primary package manager on Mac (which can be used from CLI)

How so? I’m not aware of anything built-in that allows for this.

Re: 12 Factor CLI Apps

#94

Post by [deleted] »

majewsky wrote: post #91
dickeytk wrote: post #55

Earlier quoted context omitted.

yes, exactly. I think being verbose and more human friendly is a much better way to design a tool than being terse and machine friendly. Ultimately all we're doing is trying to save human time anyways.

In practice, "being verbose" is usually the opposite of "human friendly". I much prefer a spot-on one-line error message over dozens of lines of logs with an error somewhere hidden in them. Verbose error messages usually mean that you didn't have time to design succinct ones. Joel Spolsky's timeless advice applies: "Users can’t read anything, and if they could, they wouldn’t want to." https://www.joelonsoftware.com/2…

[deleted]

Re: 12 Factor CLI Apps

#95

Post by majewsky »

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 also prefer manpages over web searches for multiple reasons:

- works without internet: very important when you want to use a long train ride to write some code (I also have the entire rust-doc and all IETF RFCs on my disk for quick referencing)

- quick and reliable access to known items: `man ascii` is way quicker than finding an ASCII table on the web (probably on Wikipedia). And finding the syntax for an obscure bash feature is way easier when your search is confined to `man bash` rather than to the entire web.

- Don't know how to label this, but I like that the manpage is a complete documentation of one tool, unlike a disconnected set of Stack Overflow questions. That allows one to cursory read through the manpage to learn the scope of what that tool can accomplish.

Re: 12 Factor CLI Apps

#96

Post by stunthamsterio »

henkdevries wrote: post #31

Man I wish OpenVMS was still a thing. All the commands worked the same due to the DCL enforcing it. https://en.m.wikipedia.org/wiki/DIGITAL_Command_Language

Me and you both. OpenVMS got so much right back in the day. Good error conventions, versioned file system... I still fondly run an OpenVMS workstation under my desk so I can revisit the good old days sometimes.

Then realise my skills have atrophied to the point I can barely remember how to use edit.

Re: 12 Factor CLI Apps

#97

Post by majewsky »

cyphar wrote: post #61
dickeytk wrote: post #46

Earlier quoted context omitted.

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.

> do you think that man pages are more important than web or in-cli docs? Yes. * Web docs are a problem because I don't always have access to the internet when trying to do something on my computer, and usually there are so many kinds of web doc generators that you have to figure out how the information you want is laid out. Web docs are useful as a quick-start guide or a very lengthy reference guide -- but not for t…

> I still add support for "--help" for my projects (because it is handy, I will admit)

Some applications (e.g. Git) make "--help" redirect to man. What do you think of that?

Re: 12 Factor CLI Apps

#98

Post by ynezz »

colemickens wrote: post #52
ynezz wrote: post #33

Earlier quoted context omitted.

> hype that brew, buildkit, linuxkit, etc all seem to get I'm not that much in devops/containers guy, bit I'm not aware about linuxkit alternative in the Linux world, care to elaborate?

As my comment implies, nix and nixpkgs can do what `linuxkit` does (in terms of image building, at least) but better and in a more powerful manner. I can create nix derivations that look like a linuxkit yaml, but instead of having a bunch of opaque sha256 hashes to some container in them, it has symbolic references to packages that are defined in my nixpkgs repository. This nixpkgs repository includes package definit…

Great, thanks!

Re: 12 Factor CLI Apps

#99

Post by justinrlle »

> I also suggest sending the version string as the User-Agent so you can debug server-side issues. (Assuming your CLI uses an API of some sort)

Isn't it some kind of disguised tracking? I know it doesn't give as much info as the user agent of a browser, but still, you could track the OS, even the linux distribution, and surely more, while still being a reproducible build.

Re: 12 Factor CLI Apps

#100

Post by czechdeveloper »

I have recently created single CLI program to put in all actions I need to automate. It's so fast to make new action, that I make anything that saves me just few seconds a day. Even stuff like "invoice" will open me timescheduling app, invoicing app and creates canned email to clipboard. "Clockout" will open timescheduling app and copy expected date and times to clipboard just to paste to app.

I've of course spent some time on automating Help, flags parsing etc, so I essentially just say what data I need and then what to perform.

It was best idea in a long time. I'm thinking that I'll publish framework for this as opensource (it's C# project).

Post reply on HN