FreeBSD: hooks/reload fails because bash path is nonexistent

[gonium]

I'm running acmetool on Freebsd:

# freebsd-version
10.2-RELEASE-p12

The reload hook fails:

# /usr/libexec/acme/hooks/reload
/usr/libexec/acme/hooks/reload: Command not found.

because the script looks for /bin/bash in the shebang line:

#!/bin/bash
## This file was installed by acmetool. Any updates to this script will
## overwrite changes you make. If you don't want acmetool to manage
## this file, remove the following line.

Since bash is only available as a port (in /usr/local/bin/bash) I would recommend to use /bin/sh. A quick test revealed that the script seems to be working using #!/bin/sh. I am not aware of the consequences on other systems.

[hlandau]

This was introduced in #79. @denisbr claims that /bin/sh breaks on Ubuntu. ...

[denisbr]

It does!

[hlandau]

What kind of error output do you get? Can you pin it down to any difference in the capabilities of sh/bash? Is sh symlinked to something else on Ubuntu?

[gonium]

Tricky ;-) On my Ubuntu workstation (Ubuntu 14.04 LTS), there is a /bin/sh. However, the following happens:

/bin/sh ./reload 
./reload: 9: [: unexpected operator

Apparently the test command is not aliased to [ by Ubuntu's /bin/sh.

[hlandau]

@gonium: Is /bin/sh symlinked to something? I seem to recall something about switching to dash by default some time ago, since dash is faster.

[gonium]

@hlandau It seems so:

$ ls -latr /bin | grep sh
lrwxrwxrwx  1 root root      22 Oct  1  2013 rzsh -> /etc/alternatives/rzsh
-rwxr-xr-x  1 root root  612624 Oct 10  2013 zsh5
lrwxrwxrwx  1 root root       7 Nov 14  2013 static-sh -> busybox
lrwxrwxrwx  1 root root       4 Feb 19  2014 sh -> dash
-rwxr-xr-x  1 root root  112204 Feb 19  2014 dash
lrwxrwxrwx  1 root root      21 Jul 21  2014 zsh -> /etc/alternatives/zsh
lrwxrwxrwx  1 root root       4 Oct  7  2014 rbash -> bash
-rwxr-xr-x  1 root root  986672 Oct  7  2014 bash

[hlandau]

sh appears to be provided by dash: http://packages.ubuntu.com/xenial/dash

[hlandau]

Testing with dash.

[hlandau]

It looks like the issue is that I used the operator == in [ tests, when this is actually a nonstandard extension. For POSIX conformance, = should be used. After this revision, the script works with bash or dash. I'll fix this and change the shell back to /bin/sh.

[hlandau]

Fixed in v0.0.45.

[gonium]

Thanks!

[denisbr]

Sorry about the lack of verbose error, this indeed is a better fix for the original problem.

[marcusandre]

I'm just curious, but what speaks against the usage of #!/usr/bin/env sh in this case. It may actually be even better supported. What do you think? :)

[hlandau]

I don't think there's any platform on which having sh in path, but not at /bin/sh is a sane configuration. I use that strategy for Python scripts, but most shell scripts just use #!/bin/sh or #!/bin/bash...

At one point when debugging this I was worried I was going to have to do

#!/bin/sh
[ -z "$BASH_VERSION" ] && which bash >/dev/null 2>/dev/null && { exec bash "$0" "$@"; }
...

So unless you can find a concrete example of where it's necessary, I think I'll leave it as it is, since the script now seems to be appropriately POSIX-conformant.

[marcusandre]

since the script now seems to be appropriately POSIX-conformant.

Okay, this makes sense. It all adds up! :)