Live data from Hacker News

12 Factor CLI Apps

medium.com

241–250 of 253 posts

Re: 12 Factor CLI Apps

#241
post #185

Earlier quoted context omitted.

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…

Making things like that persist is done through the powershell profile stored at $profile. It is the equivalent of a ~/.bashrc.

Re: 12 Factor CLI Apps

#242

Earlier quoted context omitted.

This is what I prefer as well. Let me use my OS's package manager for managing my packages.

That would still be the case if the packages weren't 1-3 years out of date.

That is true. But there are ways around that. Including documentation on how to build it locally is pretty standard. And hosting prebuilt binaries with package installation for targeted platforms is also pretty common as well.

With interpreted languages with language-specific package managers, you have to:

1) Install the language

1a) Possibly have to install a language version manager (rbenv, pyenv, etc)

2) Install the language's package manager

3) Install the CLI utility via the language's package manager

Here's the order I think CLI maintainers should strive to making their utilities available:

1) Install via OS package manager

2) Install via prebuilt release with OS-specific package, from hosting site (GitHub, etc).

3) Install from source

4) Install via language-specific package manager

5) Install via curl | sh :)

Re: 12 Factor CLI Apps

#243
post #35

Earlier quoted context omitted.

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.

This can be done using the mas-cli. It's not official, but works decently well.

https://github.com/mas-cli/mas

Re: 12 Factor CLI Apps

#244

Earlier quoted context omitted.

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

This can be done using the mas-cli. It's not official, but works decently well. https://github.com/mas-cli/mas

mas-cli uses private API to do this, so it's not like this is something that Apple encourages or provides ready access to.

Re: 12 Factor CLI Apps

#245
post #164

Earlier quoted context omitted.

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/p…

Command line is not the only HCI that can use text. Also, no one (except immense mental inertia) stops developers from producing serializable graphical interfaces.

I think the macro language of WordPerfect 5.1 was one of the most awesome serializable interfaces ever.

And they scrapped it in WP6 for some shitty object oriented version that lacked all the "serializable workflow" of the previous one.

Re: 12 Factor CLI Apps

#246

Earlier quoted context omitted.

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"

IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.

The problem is, its much easier to support one language package manager, then it is to support 10 different OS package managers, not to mention, some, like debian, are near impossible to push things too.

Re: 12 Factor CLI Apps

#247
post #166

Earlier quoted context omitted.

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.

Yes. IOW, GUI's are not as easily scriptable as CLI programs, to compose operations from combinations of other operations, even though some tools to do stuff like that do exist, e.g. AutoHotKey and others like it.

A classic CLI command composition (a.k.a. pipeline) example:

More shell, less egg:

http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

After reading that post, I wrote about it here:

https://jugad2.blogspot.com/2012/07/the-bentley-knuth-proble...

with a couple of solutions in Unix shell and Python.

Related:

Why you should learn just a little Awk (2010) (gregable.com)

https://news.ycombinator.com/item?id=17322412

A comment by me there:

https://news.ycombinator.com/item?id=17324572

Re: 12 Factor CLI Apps

#248
post #168

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.

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/

How can you say it's less universal when it doesn't work on windows?

Re: 12 Factor CLI Apps

#249
post #197

Earlier quoted context omitted.

'man' has no regex functionality; on most Unix systems, it just uses 'less' as its pager.

sure, which means that it inherits regex support via less. You either have it on both, or neither.

[deleted]

Re: 12 Factor CLI Apps

#250
post #71

Earlier quoted context omitted.

A problem with color is that people end up optimizing the aesthetics for their own terminal setup. There is a wild number of different color schemes out there and it's really hard to make something that looks good on all of them. In my experience the only safe choice is bold text (i.e. \033[1m) since it stands out in all cases.

red, yellow, green, cyan, and magenta are pretty safe. We've had complaints about others, but these are pretty reliable in my experience. dim is safe too, but doesn't work all the time. (Not working meaning just not dimmed)

I would definitely not call yellow a safe color. I use a terminal with a white background, and yellow text is unreadable unless the text is also given a custom background color.
Post reply on HN