Hacker News Reader

Comment by nailer | Hacker News Reader

For anyone packaging software on Linux, this now means every major distro - Debian, RHEL/CentOS, Arch and now Ubuntu - supports .service files.

No need for bash scripts, custom watchdog and daemonise tools, etc.

View on HN

> No need for bash scripts

Friends don't let friends write shell scripts targeting bash.

For context: Bash is not available|installed everywhere, and has some inter-version weirdness.

Write clean, posix-compliant shell scripts (i.e. target /bin/sh commonly referred to as bourne shell) and you're in a much better position.

On Debian your script will be run by Dash, on OS X it will be run by Bash, on Ubuntu or RedHat it could be different again, but the point is, they are specifically running in POSIX mode, so that you get reliable, reproducible results across systems and even across Bash versions.

You're getting downvoted to oblivion, but I'm old enough to remember not being able to take bash for granted. The default shell on some modern systems (OpenBSD for example) comes to mind as well. I feel this battle has mostly been lost, however.

HN coolkids downvoting advice that makes software more portable and reliable. What a fucking shock.

They use bash as a service. It's integrated in node.js 2041.4.1.

> HN coolkids downvoting advice that makes software more portable and reliable. What a fucking shock.

A little more verbosity on the advice might have helped. I wouldn't have properly understood you were saying without @peatmoss's reply. So without the context, your original comment just seemed like knee-jerk bash-bashing.

Unless you've actually tested it with a shell other than bash, you should be marking it as bash. Otherwise it's likely it will not actually be portable between shells, and you will have made your software less reliable.

I've encountered many scripts written by developers on Fedora that totally fail over when run on Ubuntu specifically due to using #!/bin/sh when they really required #!/bin/bash.

Unless you've tested it as a shell script you should be marking it as a recipe for a banana cream pie.

I specifically said "Write clean, posix-compliant shell scripts"

Do the same developers write Java code in a .cpp file and wonder why it doesn't work? Or put <?php tags in a .erb template?

Yes, you need to test to make sure that you wrote the correct things.

Default on debian is dash.

But bash is installed by default if I'm not terribly mistaken, and it's classified as an essential package. If you put in a bash shebang, it should work.

I have seen several people use #!/bin/sh and write bash code. This is going to break on debian machines when you do ./foo

If more people used #!/usr/bin/env bash, it wouldn't be that big of a deal.

And they would have non portable code.

If they wrote posix compatible shell scripts it wouldn't be any big deal because they'd just work.

There's like five comments from you in this thread and you seem very adamant about people not writing bash scripts. Have you considered that not everyone has the same requirements? Maybe they don't care about targeting systems that don't have bash installed. In that case, they can use the myriad of enhancements that bash offers to improve their productivity and happiness.

And, this page being news about Ubuntu, one should note that this has been true for Ubuntu for fast approaching a decade, now; Debian having followed in the footsteps of Ubuntu, in this regard.

* https://wiki.ubuntu.com/DashAsBinSh

* https://wiki.ubuntu.com/DashAsBinSh/Spec

* https://lists.debian.org/debian-release/2007/07/msg00027.htm...

Everything old is new again - distros targeted at running inside docker containers (like Alpine) are shipping without bash. Not taking bash for granted is still a good plan.

And test them on a shell that isn't bash. Even with the --posix option bash accepts non-standard bashisms, particularly the execrable 'extension' of '>&'.

That's why I always put "#!/usr/bin/env bash" at the top of my scripts. Most were written to be portable, but unless it's been well tested, it's best to consider it not portable. Fail early and predictably rather than in strange ways.

That.. Isn't the solution. The point is that bash is not a good target for shell scripts, not that you should use env to detect the location of bash.

If you only use *nix platforms the default to bash, why not write bash scripts?

Depends on the use case. There are cases where I don't know how I'd live without arrays/associative arrays. Performant regex matching is also quite nice.

> For context: Bash is not available|installed everywhere, and has some inter-version weirdness.

Can you cite some sources here? No one knows what you're talking about.

Non-OSX BSDs don't include bash, some things like the ... operator don't work on older versions of bash.

Many people, especially Solaris and BSD folk, don't like bash scripts, and want you to write shell scripts in Bourne shell instead.

Many other people, who code on OS X and deploy on Linux, enjoy the extras bash adds, and only deploy on platforms that include bash.

I think your last point is important. I don't think shell script writers should be concerned about Solaris/BSD if they are confident that they will use their scripts only in environments where bash is available.

The bash COMPAT page? http://tiswww.case.edu/php/chet/bash/COMPAT

Also, just because you may not know what I'm talking about, don't assume no-one else does.

Sorry, I meant "no one who replied to you knows what you're talking about". Still, that list don't tell much about potential breakages. Are you actually complaining about bash having too many features or are there actual breakages? Please illustrate with examples, not links to tedious changelogs and ad-hominems.

Could you, please, explain what .service files are and how they eliminate the need for bash scripts etc? Couldn't find anything in search results.

systemd services, that replace traditional init.d scripts and provide watchdog options, daemonising, etc.

https://www.freedesktop.org/software/systemd/man/systemd.ser...

http://0pointer.de/blog/projects/systemd-for-admins-3.html

This site's down, 80/443 both closed.

Then read the Ubuntu doco.

* http://manpages.ubuntu.com/manpages/wily/en/man5/systemd.ser...

* http://manpages.ubuntu.com/manpages/wily/en/man5/systemd.uni...

* https://wiki.ubuntu.com/SystemdForUpstartUsers

* http://askubuntu.com/questions/636899/

* http://askubuntu.com/a/613814/43344

Google cache: http://webcache.googleusercontent.com/search?q=cache:ADZV5sJ...

This is pretty much the only reason I've been waiting for 16.04 – to get rid of upstart scripts and standardize on systemd. Still going to wait for a couple months while people iron out initial bugs but definitely excited about this release.

> to wait for a couple months while people iron out initial bugs

There's going to be a 16.04.1 release just 3 months away from the initial LTS release; I believe it is just for that.

https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule - this schedule is for 14.04, but I believe it's been the same for quite a few years already.

Great, thanks. I will probably install this on internal servers (non-production, non-critical, CI, etc) first because I'm also impatient. :)

I wonder how big the installation of Amazon Linux is? They are still not on systemd. Also, CentOS 6 still has support for 4 more years so probably can't throw away all the bash yet.

Very good points. Amazon linux is pretty popular within AWS, and LTS CentOS and RHEL have huge install bases for larger corporate environments.

For that matter, Ubuntu 14.04 is still supported for another two years, and that's still upstart.

Three more years: https://wiki.ubuntu.com/LTS

Upstart provided comparable service for years. There was no reason to use bash scripts and watchdogs / restarters before.

Yes, there was a reason: Having to support other distros.

The big deal now is that all the major distributions support the same mechanism.

Which of course still leaves OS X, *bsd, Solaris AFAIK. But it should cut down on the internal Linux incompatibilities a bit. I'm not a fan of systemd, but having one broken standard is much better than having four broken standards :-)

> Which of course still leaves OS X, bsd, Solaris AFAIK.

AFAIUI OS X has launchd, and Solaris has OMF[1]?

... so basically the BSDs are the ones left behind?

[1] I think that is the acronym for Solaris' XML-based standardized system service files? (I don't care that they're XML. It care that they're standardized.)

Solaris 10 and 11 have SMF

Ah, SMF, that was it! Thanks

Thinking that the BSDs have been left behind is to erroneously presume that the BSDs ran System 5 rc in the first place. They did not. Most of them use Mewburn rc (or their own reinvented version thereof), which was invented almost a decade after van Smoorenburg rc, which itself was invented about half a decade after System 5 rc.

Here's a "portable" script for van Smoorenburg rc that ports to 4 Linux families, complete with the sort of case statements that I described in https://news.ycombinator.com/item?id=10357589 :

* http://conman.googlecode.com/svn/trunk/etc/conman.init.in

Here's a Mewburn rc script:

* http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/etc/rc.d/...

I'm talking about the time when other distros were already on systemd, but ubuntu wasn't. Of course we needed shell scripts before that.

Except upstart actually allowed shell code in its configuration files[1]. Now, it did have the "exec" stanza which was far cleaner, but if you look through what Ubuntu actually did in practice, I think you'll find quite a lot of "script" stanzas in there.

[1] http://upstart.ubuntu.com/cookbook/#script

That was always an option. It's the same for systemd - you can always configure: `ExecStart=/etc/init.d/something start`. But the context of the comment was - you as a developer writing the config. And you can do it the modern/proper way instead with both upstart and systemd.

> It's the same for systemd - you can always configure: `ExecStart=/etc/init.d/something start`.

Yes, but you cannot embed shell script directly in the job/service definition... thus making the "good path" simpler and more natural, which is a Big Deal(TM) in software usability. (As evidenced by the fact that many many upstart jobs on Ubuntu at least used "script" sections.)

Reply on news.ycombinator.com