Hacker News Reader

Comment by bravetraveler | Hacker News Reader

Not to deride this (too much), but the 'robustness' of deployments with shell scripts is tempting bait. Things are until they aren't, 'nobody rides for free' - decide what you're willing to pay.

Example: this interprets the output of 'ls'. Reliability is dependent on good quoting/never introducing a project with spaces

Ansible is a nice middle ground, personally. I write the state that differs, use a library of scripting.

View on HN

Parsing ls is an anti-pattern, but the author says it works for years - we all do mistakes and as long as it works you don't notice.

And it's an easy fix:

    - for project in $(ls go-cicd); do
    + cd go-cicd || exit 1; for project in \*; do

I would suggest not to mess with the current working directory and instead do something like this:

  for project in go-cicd/*; do
    project="${project#*/}"

Indeed, thank you for mentioning that - I was going to suggest similar.

That said, if you do (ie: scratch files, things outside of control, whatever), consider the directory stack:

https://www.gnu.org/software/bash/manual/html_node/Directory...

Using 'pushd' and 'popd' can save your fingers/brain from getting lost in context.

I like using subshells for this:

  (
      cd dir
      for f in ./*; [..]
  )

There's a few scenarios where this won't work (mainly if you want to set a variable from the "outer scope"), but 99% of the time it works nicely.

Ah, that's a nice/neat thought - thank you for sharing! Makes total sense, temporary/disposable shell for such things

Putting

  SAVEIFS=$IFS
  IFS=$(echo -en "\n\b")

or something similar at the top of the script might not come across as comparable to adopting Ansible to some people.

I knew giving specific examples would lead this way, that's not my point.

This case has been handled. Others?

There isn't anything really insightful here. Someone pleased with a script has not yet grown beyond the needs of it. Yay.

The more portable/maintainable version of this is a playbook or whatever. Someone wrote and tested a better version of whatever Work Unit as a module.

Wheel enthusiast is pleased with their finely polished, but not particularly traveled, wheel. It's great, but they're commodities and not seeing much.

I would have done the same thing with 'ansible-pull' and zero code, in even less time/effort... but I also already know Ansible and bash.

Configuration management tools are excellent at managing applications and configs. Who knew.

Something else to suggest: systemd timers. At a glance info for scheduling of the job, instead of inferred from logs that may or may not have been recorded. You can also then actually declare your deployment needs networking.

Eyeroll.jpg. This is great because the bar is so low. They'll generate a ton of useless logs if they lose networking, as-is. Long enough and the disk will fill: this is trying every minute.

OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration.

When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.

Let's take a step back from names for a second - I feel we're getting a little distracted by that.

My gripe isn't with the tech, or even the solution. It's perfectly fine. I know I'm being overly critical, but I think they opened themselves to some judgement by making a post!

I would do something very similar. Sure, the tool wouldn't have the exact same name, but the mechanism would be ~the same~ very similar.

If the goal is to minimize surprises, the amount of effort put into something, etc - is it not best to follow the beaten path?

They're to be commended for making a solution that works well for them, and echoing the KISS methodology, I just don't think a shell script is it. Anecdotes are funny, I guess.

It's worked well for them - but I'm here because similar things have gone terribly for me. Small decisions can have big influence

Pretty sure bash and Perl and C (and make and autotools and probably something I'm forgetting) are the beaten path in this context, i.e. software building and deployment on Unix.

Ansible has surprised me way more often than bash has. The latter is upfront about being weird and a little bit insane, Ansible tries to have a better image. In my experience that is true also for Puppet and some other similar tools, which I'd never use without payment, at least until I can afford personal medium iron somewhere and need to provision and handle hundreds of more or less ephemeral virtual machines.

In part because I enjoy having pets rather than herds in my personal projects, but also because when using the shell or POSIX there's very little overhead, like venv and python libs and so on that will inevitably irritate me a few times a year even if I rarely use them directly.

Bash/Perl/C being precursors don't disqualify Python/Ansible, though. Otherwise my retort would be this: assembly.

While I empathize, your experience isn't [widely] representative. A reproducible Python environment is just as attainable as any other - anyone struggling with it has accepted it, in my opinion.

Most of my peers/community uses the distribution packages. They don't even need to care about venv/pip at all.

Pro tip: unsetting IFS has the same effect as saving and restoring the old value.

Ah, nice, thanks.

I've been cargo-culting this for ages without thinking much about it.

Or a project name that overlaps an init.d script they'd prefer to have kept

It also doesn't fail immediately if many of the commands fail (instead blindly moves on to the next statement). Consider using bash and these options: https://github.com/kvz/bash3boilerplate/blob/main/main.sh#L1... for most scripts.

Reply on news.ycombinator.com