The install scripts lack `set -e` (or `set -xeuo pipefail`, which is what I've memorized), so if a command fails, the scripts just keep on steamrolling forward.
Then again, these scripts are clearly tailored for OP, since they contain their name and email, so it's... not like these would be usable as-is for anyone else.
I had to deconstruct that since I only use #!/bin/sh -xe
-e : exit immediately if statement has non-zero exit status
-x : echo each command
-u : treat unset variables as an error
-o pipefail : If set, the return value of a pipeline is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands in the pipeline exit successfully.
that is actually much better than -xe, thank you, I learned something
Yeah I should fix that email stuff somehow. But it's just a good place to keep the GitHub noreply emails. And set -e with option to continue manually somehow good idea.
It's surprising how many people have used these, so they are for others... Improving them makes sense. If your wanna submit some changes and ideas please do :)
I would really appreciate it, and whoever gets them from npm might too.
I think I pushed to npm because I mostly do node and I guess I figured it's an easy backup and way to distribute.:)
For the last couple of days, I've been trying to get a static website up using hugo (emacs + ox-hugo), and I've been using tramp to ssh into the machine and do my work.
Tramp is literally magic. It just puts the right text into your buffer, where all the tools you use on your machine are just available by default. Even org exports and the like behave as expected, outputting the resultant file into the correct dir on the remote machine.
I've been using emacs as a <50IQ user for about a year now. I've yet to write a single line of Elisp (apart from use-package declarations). It's awesome!
> # uncomment for a colored prompt, if the terminal has the capability; turned off by default to not distract the user: the focus in a terminal window should be on the output of commands, not on the prompt
:eyeroll:
What a horrible attitude. The point of coloring is precisely to help users focus on the output that matters, rather than forcing them to parse and reparse a chunk of stuff they don't care about. If the prompt is colored, my brain can filter it out much faster than if it isn't.
By all means disable color by default for backward-compatibility purposes or to err on the safe side, but don't lecture people with rubbish arguments...
I mean, it depends on the person and the color scheme.
I appreciate being able to turn off very colorful output if possible, as it does tend to distract me sometimes. The color schemes I pick/design for myself tend to be muted, while a lot of the tools out there in the world are way too colorful for me (and full of distracting emojis).
Ok, I think I copied that from somewhere... Pretty sure it's not my comment. But still... Lecturing people with rubbish arguments and a horrible attitude sounds like what you're doing.
Big world out there. You can have people who like colors and those who don't. Neither have to be pretending they're all that and hate the other. :) Friends?
Please submit a PR with a better comment if you like. I honestly didn't think of that until now, but I think comments are important. Thanks for pointing out really. :)
Personally, I love colours on my terminal — in a minimal way, like this[1] —, but
I understand people that do not, which is why I have this in every script I
write, public or not.
# Color variables to make our output a little easier on the eyes. Respect
# NO_COLOR, in case the user does not want any.
if [[ -t 1 && -z "${NO_COLOR:-}" ]]; then
readonly c_red='\033[0;31m'
readonly c_blue='\033[0;34m'
readonly c_green='\033[0;32m'
readonly c_bold='\033[1m'
readonly c_reset='\033[0m'
fi
I have no idea why I added that readonly command there, though, but by now I am
afraid to remove it.
The NO_COLOR[2] environment variable is not exactly a standard as far as I know, but it is supported by enough command-line software that it feels like one to me.
Ok cool. I see you were just commenting about the comment itself and not me... Sometimes it's hard to separate the two, reading what someone says. You know, I take it like they mean it personally, but I'm working on it :)
I'm nearly certain that is a default message included in a lot of .bashrc files. I've seen it on Debian and Ubuntu. I agree with his criticism but certainly not with how he conveyed it. I love colour :)
I like how color looks for a short time but when working all day in vim I find I think better with just two colors and no syntax. I think I just got used to that in shell .. but then I do like the link/executable highlights... Maybe I'm missing a huge world of color in bash prompt... I just don't know how to do it, or do it well...haha. Wanna spruce up my prompt? ;P :) you're welcome to submit if you want, a change :)
Yeah I regretted it after posting, haha, but I'll stick to my word, I think I might prefer my prompt and get sick of the color so I'll add some optionality.
Thank you, you're welcome :) I think you can use it as a base. Well maybe not you specifically, but someone can customize this... The git commands in particular save me lots of time, and I guess the rest is stuff used enough times i put it here to not have to look it up next time.
I use something similar to configure my entire desktop from a default Debian install using idempotent shell scripts. The repo isn't public since it contains a lot of sensitive information but I'm currently developing something based on that for a server I'm working on: https://github.com/T0astBread/easymark-server-config
Cool, yeah when you do it enough times you just want to script it. I use to have more sensitive stuff in here I think before I obliterated the historical stuff and made it a public repo, but I factored all that before sharing it. Like 2 years ago. It was a good exercise I think, separating secrets from config.
Definitely! What I'm forcing onto Bash is basically what Ansible does normally. For the desktop use case I've certainly noticed that it might be easier to use something that is already idempotent by default (like Ansible). The server thing isn't all that complex though, at least not the parts that you could replace with Ansible.
I’d love to hear more specifics about what kind work you do. I saw Node, so I’m guessing backend Node development? Do you do front end too? If so, what’s your workflow for running a dev web server and accessing it from a browser?
Thanks Roben! :) Yes full stack, and the way I run most dev is to run it in the same server as production, but in another clone of the repo in a different directory, a different branch, and a dev port, like 6667. But keep the same certs TLS, and create a clone or dev version of the db. Then just access the same as normal but on the other port.
Occasionally, for like a larger project with load balancers, I'll run an entire dev single VPS with a subdomain of the production and use a wildcard TLS cert.
Then I can do whatever I like to the dev and production will be fine. Depending on situation, I might set it up blue-green and shift some traffic over from production and monitor and if it's ok, I push that to production. Or for larger projects, mirror the whole stack (two instance pools) and alternate production and dev, so I get continuous monitoring of the latest changes and I can roll back to the last stable version by traffic shifting if need be.
Cool, thanks for the tip about NixOS! I think I like the flexibility of running scripts and picking and choosing... But a Dockerfile in the repo might be a cool way to tie everything together. Submit? :)
Then again, these scripts are clearly tailored for OP, since they contain their name and email, so it's... not like these would be usable as-is for anyone else.
(Also, why is this published on Npm?)