Show HN: Useful scripts and environment setup for coding in VPS | Hacker News Reader

Show HN: Useful scripts and environment setup for coding in VPS

github.com

44 pointsbrowsergrip30 comments

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.

(Also, why is this published on Npm?)

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

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

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!

I love tramp. I can even edit config files on a teeny openwrt router without resorting to busybox vi. Even commands like m-x grep work remotely

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

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

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 :)

I hope I remember this tomorrow, I'll try to convert you ;) haha

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.

Oh, I wasn't faulting you, most of these comments in rc files typically come all the way from some random flame in 1998 or something.

> You can have people who like colors and those who don't.

I absolutely agree, which is why I'd remove any opinion from the comment. "Default is off". End of story.

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 :)

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.

[1] https://i.cpimg.sh/9k3PlfHt1Spg.png

[2] https://no-color.org/

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

It does complicated matters if you're capturing command output in logfiles or an editor.

In my scripts, I just check for unset term and/or use tput to get the sequences (which honors TERM=dumb)

one example:

  col_ok=`tput bold; tput setaf 7; tput setab 2`
  col_fail=`tput bold; tput setaf 7; tput setab 1`
  col_end=`tput sgr0`

  echo "${col_fail} ERROR: it failed ${col_end}"

so running the script gives me colorized output (xterm-256color), but running it like this:

  TERM=dumb <script>

gives plain text

This is so specialized, I really can't think of a use for this other than for the one who wrote it.

Thanks for sharing though, it's always interesting to me to get to know the workflows of other people!

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

I wonder if you could do the same with Ansible ?

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.

Good to know, thanks for sharing !

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.

> echo "echo 3 > /proc/sys/vm/drop_caches" | sudo sh

khm

    sudo sysctl vm.drop_caches=3

Okay good catch. Care to submit some PRs? :) I could use your help

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.

Got it, this really helpful. Lots of useful tips here, thanks!

OP might want to look up NixOS, which would make this many times easier. Or consider setting up a pre-configured image.

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? :)

Reply on news.ycombinator.com