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

211–220 of 253 posts

Re: 12 Factor CLI Apps

#211

Post by dickeytk »

boomlinde wrote: post #201
jessaustin wrote: post #191

Earlier quoted context omitted.

Anyone who doesn't test cron jobs before saving them deserves whatever she gets. There are scores of ways for cronjobs to fail. b^)

Well, this is not a cronjob that failed, it's just waiting for input. Let's say that I did test the cronjob but that it starts "failing" after an update to the tool. My fault, I know, but at least I get mail when it fails while I won't if it's just waiting for input.

This scenario would only happen if a flag became required. Prompting or not it would still be an issue. (And it wouldn't prompt as this is a non-tty environment)

Re: 12 Factor CLI Apps

#212

Post by dickeytk »

iainmerrick wrote: post #138
dickeytk wrote: post #134

Earlier quoted context omitted.

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

Like for the confirmation example? I agree. It would help clear this up. The points people are raising here with prompting are definitely not issues, they're just misunderstanding my point.

Re: 12 Factor CLI Apps

#213

Post by JdeBP »

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.

It's an argument that Daniel J. Bernstein made when proposing slashdoc. So M. Dickey is not alone.

* https://cr.yp.to/slashdoc.html

I myself write doco in Docbook XML

* https://news.ycombinator.com/item?id=15779321

generate HTML from that that can be read directly

    xdg-open /usr/local/share/doc/nosh/machineenv.html
or on the WWW

* http://jdebp.eu./Softwares/nosh/guide/machineenv.html

and generate roff for man pages from it as well

    man machineenv
Whereas --help output is auto-generated from the option definitions given to the command-line parser, much like libpopt does.

Re: 12 Factor CLI Apps

#214

Post by Klathmon »

JdeBP wrote: post #193
Klathmon wrote: post #174

Earlier quoted context omitted.

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

I didn't mean to imply that it was a PS creation, or that it was impossible to change, only that it's how PS handles tab completion, and that I dislike it.

Being able to change defaults is nice, but the power of PS or bash is that they are ubiquitous. So anything that has to change defaults to be usable makes it kind of pointless in a lot of ways (at least to me). Because if I need to change defaults on every system i'm on, then why not just use that time to install a different shell? (which is pretty much what I end up doing on windows machines)

Re: 12 Factor CLI Apps

#215

Post by bigpicture »

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

A) PowerShell was inspired by OpenVMS DCL. B) OpenVMS on x86 is due to be released in 2019 (it's in private beta right now).

Re: 12 Factor CLI Apps

#216

Post by Klathmon »

lzybkr wrote: post #185
Klathmon wrote: post #174

Earlier quoted context omitted.

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…

With PSReadLine, you can change that: Set-PSReadLineOption -EditMode Emacs Or Set-PSReadLineKeyHandler -Key Tab -Function Complete

The first one seems to change it how I want, but the second doesn't. And it doesn't stick around after closing the powershell prompt.

And while I'm sure there's a way to make it persist, a shell's power is in it's ubiquity. If i have to change settings on every machine I work with, i'm probably going to want to use that time to install a different shell.

I know that's an attitude that is pretty impossible for any new shell to solve for, but it's the truth. I'm not choosing the most powerful or "best" shell, i'm choosing the one that gets in my way the least. And for me, that's bash in 99% of cases. And until another comes along that really improves discoverability and makes it easy to learn and adjust to, i'm not going to switch.

I have a ton of knowledge built up over the years about bash and I'm not in a position where I'd be able to dump it all and painfully try to learn everything new from scratch by reading manuals, trying out syntaxes, searching around for if what I want to do is possible, figuring out the "right" way to do things, and more.

Even if it is better in the end, if I can't get over the initial hump, it's not very useful to me. Maybe this is just me getting old...

Re: 12 Factor CLI Apps

#217

Post by TeMPOraL »

dotancohen wrote: post #155
ISO-morphism wrote: post #21

These are all good points, and I wish more clis were like this. My own pet peeve is un-disablable stdout logging. > It’s important that each row of your output is a single ‘entry’ of data. It felt weird to me to use `ls` as an example as it's not immediately obvious it adheres to the advice from the printed output. I suppose they were also trying to highlight the earlier point of differing output format depending on…

> My own pet peeve is un-disablable stdout logging. I really think that we need a stdmeta file descriptor. See my comments at the link below, I would appreciate your feedback: https://unix.stackexchange.com/questions/197809/propose-addi...

I like the idea in Common Lisp - beyond stdin, stdout and stderr, it also specifies bidirectional streams for general interactivity (querying users for data and accepting their input), interactive debugging and an output stream for tracing&timing code. See: http://www.lispworks.com/documentation/lw61/CLHS/Body/v_debu....

Unfortunately, if using CL to deploy a CLI app for modern systems, all of this has to be shoehorned into the usual stdin/stdout/stderr split.

Re: 12 Factor CLI Apps

#218

Post by twic »

hornetblack wrote: post #50

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.

I am one of the handful of people to use a white background in my terminals. A significant amount of coloured output is illegible to me.

I would suggest these rules for using default coloured output:

1. Don't.

2. Really, don't. Bold is fine, though!

3. (experts only) Make sure the colour scheme works with white-on-black, black-on-white, white-on-navy (for powershell), and Monokai/Solarized/whatever the flavour of the month for insecure hipsters is.

If you use colours, by default or not, make it really easy to configure the colours, so people can make it work with their terminal's colour scheme.

Re: 12 Factor CLI Apps

#219

Post by ajross »

twic wrote: post #207
ajross wrote: post #196

Earlier quoted context omitted.

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.

I think detecting whether stdin is a TTY is a huge antipattern. Most of the time, it works, but now and then, you either want to run an interactive session in a situation where stdin appears not to be a TTY, or a batch session in a situation where it appears to be. Plus, it means there's twice as much surface area to learn. EDIT: remove rogue 'not'

> you either want to run an interactive session in a situation where stdin appears not to be a TTY

Um... why? That is literally the situation for which the pseudotty device was created.

There is a spectrum between "interactive" and "scripted" utilities, and the command line interfaces we're talking about sit balanced on the interface. There's no way to make everyone happy, more or less by definition. So I think "huge antipattern" is maybe spinning a bit too hard.

Re: 12 Factor CLI Apps

#220

Post by twic »

> 8. Use tables

> By keeping each row to a single entry, you can do things like pipe to wc to get the count of lines, or grep to filter each line

> Allow output in csv or json.

Yes please. Default to readable-but-shellable tabular output, and support other formats.

libxo from the BSD world is a really smart idea - it provides an API that programs can use to emit data, with implementations for text, XML, JSON, and HTML:

http://juniper.github.io/libxo/libxo-manual.html

I personally love CSV output. Something like libxo means that CSV output could be added to every program in the system in one fell swoop.

Post reply on HN