Hacker News Reader

Comment by _red | Hacker News Reader

Bash init files may not be particularly feature rich, but they are hardly "complicated".

90% of every file is boilerplate built around: stop, start, status (after all restart is just stop+start).

Proponents of SystemD can make some good points, but trying to claim init.d is complicated comes across as desperate.

You forget that sysvinit also required fun extras like supervisord to run simple executables because it relied on applications demonizing themselves.

Writing systemd unit files for my applications is a breeze compared to the shit I had to do for sysvinit - especially when I factor in apps I DIDN'T write that I need unit files for (teamcity, etc) and there's less surprise with SELinux policy transitions (and unlike most setenforce 0 is not the first thing I run on a server, I work in healthcare and a solid MAC layer is important to me).

> Bash init files may not be particularly feature rich, but they are hardly "complicated".

Are you trying to make the argument that shell scripts are simple, easy to read, and maintainable?

Permit me to disagree.

Yep, they are. Shell is lingua franca for system administrators for whole history of UNIX.

Which one? ash? csh? tcsh? ksh?

I don't think you have as much experience with Unix as you would like us to think you do.

What do you mean which one? It's /bin/sh. /bin/sh has always been the shell used, because it's the only one guaranteed to be on all unixen. No system ships their init scripts written in ash, csh, tcsh, ksh, or anything besides /bin/sh (except Linux, which may have used /bin/bash, since /bin/sh was symlinked to /bin/bash)

You might have made your personal init scripts in some other shell (until you learned about design failures of csh), but I'm willing to bet your Unix distributor did not.

I rarely see a bash script more than five lines long which doesn't have at least one bug.

If you disagree with me then post an example and I'll show you the bug in it.

Also, it's not the 90% that matters; it's the 9% that is difficult and the 1% that is crap.

There's this example for your approval: https://news.ycombinator.com/item?id=13388322

The reply from bazurbat covered it well.

And 90% of that 90% has that tiny modification that is a nightmare to debug.

What he wanted to say: you can debug since context is very local. (not taking sides)

Use `set -x` or `bash -x script.sh` to trace shell script execution. Shell scripts are easy to debug.

I call this to drop into an immediate repl at the point of invocation in a language that doesn't hate me (Ruby):

     require 'pry'; binding.pry

This is, in fact, 2017. One might call it the current year. The stone knives and bearskins of shell scripting have not kept apace with, like...anything else in our industry. You might be comfortable with them, but that doesn't make it easy, it means you have frayed countless synapses learning it.

Reply on news.ycombinator.com