231–240 of 253 posts
Earlier quoted context omitted.
Okay, you have the CLI tool in one or more isolated Docker instances. What then?
No, you start the docker container to run the CLI tool, because the tool is exported as the CMD for the image, like this one [1] [1] https://hub.docker.com/r/mesosphere/aws-cli/
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I am having an impossible time verifying this, but I recall reading that MacOS deletes unaccessed files eventually from `~/Library/Caches/*`. Which would be a compelling reason to use that for cache. (Not being able to verify this I didn't add it to the article) If anyone can verify that I'm either right or wrong here that would be helpful.
OSX does not automatically delete from that directory. See: https://developer.apple.com/library/archive/documentation/Ge... > Your app is responsible for cleaning out cache data files when they are no longer needed. The system does not delete files from this directory. However, many third-party tools delete from that directory with minimal caution if any, so it's a good idea to consider it ephemeral.
Earlier quoted context omitted.
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)
Yes, but in one case the issue would result in a mail because the cron job failed, and in the other case the issue would just cause the the process to hang indefinitely without notice
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…
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…
Earlier quoted context omitted.
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)
> Prompting or not it would still be an issue. Yes, but in one case the issue would result in a mail because the cron job failed, and in the other case the issue would just cause the the process to hang indefinitely without notice
Earlier quoted context omitted.
Then again, on a recent linux system, the non-ability to write to the file might be permissions. Or an immutable attr, or selinux, or apparmor, or setfacl flags or a RO mount where it lies. As soon as you decide to print out the solution to "can't write to: X" you are in for a page full of advice on what to look for. Perhaps the disk was full, perhaps uid was wrong, perhaps the 5% reserved-for-root-only kicked in. Yo…
Also, on an unrelated note, I would never ever suggest novice users to blindly just give `chmod +w` to random locations. This is only marginally better than the `chmod 777 ` that used to be so spread out in many (e.g. PHP-related) tutorials a decade or two ago.
> 12. Follow XDG-spec I'm so glad to see this included. I don't like $HOME being cluttered with . config directories, but worse than that, far too many when releasing on macOS say Oh Library/Application\ Support/ /vom/something is the standard config location on Mac, so I'll respect XDG on Linux but on Mac it should go there. No! Such an unfriendly location for editable config files.
Earlier quoted context omitted.
IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.
This is what I prefer as well. Let me use my OS's package manager for managing my packages.