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…
12 Factor CLI Apps
241–250 of 253 posts
Re: 12 Factor CLI Apps
#242Earlier 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.
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
#243Earlier 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.
Re: 12 Factor CLI Apps
#244Earlier 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
Re: 12 Factor CLI Apps
#245Earlier 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.
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
#246Earlier 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.
Re: 12 Factor CLI Apps
#247Earlier 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.
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:
Re: 12 Factor CLI Apps
#248Earlier 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/
Re: 12 Factor CLI Apps
#249Re: 12 Factor CLI Apps
#250Earlier 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)