Hacker News Reader

Comment by sirn | Hacker News Reader

Looks like the problem existed (on their RPM package) since 2016[1], notably, the reason given by their contributor was:

> The /bin/sh stuff is due to Ubuntu symlinking dash to /bin/sh and that reacting badly with both the R shell wrapper and some Microsoft R Server features. I believe we fixed the R shell wrapper features last release by explicitly requesting bash and we will be fixing the R server features next release. 3.3.3 should be updated with these fixes.

[1]: https://github.com/Microsoft/microsoft-r-open/issues/20

View on HN

> The /bin/sh stuff is due to Ubuntu symlinking dash to /bin/sh and that reacting badly with both the R shell wrapper and some Microsoft R Server features.

Which is understandable considering the switch from bash to dash as the default shell has tripped up even open source software.

> I believe we fixed the R shell wrapper features last release by explicitly requesting bash and we will be fixing the R server features next release.

So #!/bin/bash?

Doesn't seem like this was a big deal. Just an oversight fixed quickly.

Sure, but a packager should never be hacking the system to fix an application. That may fix your package, but could easily break everything else on the system.

The fix should have been the simple and obvious one - apply a patch that fixes the application (in this case, literally just fixing the first line of the script).

That shebang isn't portable. Bash isn't always installed in the root file system. Use this instead:

  #!/usr/bin/env bash

"#!/bin/bash" absolutely is portable when writing a Debian package for installation on Debian or Ubuntu systems. bash is guaranteed to be installed in this scenario as it ships in a package marked Essential.

Further, for the purpose of a distribution package, "#!/usr/bin/env bash" is wrong, as it'll prefer /usr/local/bin/bash which could be anything. Since the distribution package uses real package dependencies to express what it needs, it'd be wrong for it to use anything in /usr/local.

No it isn't -- if a user has installed a bash version they prefer, #!/bin/bash will not use it. Better to trust $PATH and use `env`. It's not as if the `env` version is more difficult to write.

> No it isn't -- if a user has installed a bash version they prefer, #!/bin/bash will not use it.

Correct, but irrelevant for an implementation detail for what is used by a system package for maintenance scripts where the user will never see what was used.

> Better to trust $PATH and use `env`.

Wrong, because as we've seen, behaviour can change depending on what /bin/sh points to. Scripts shipped with distribution packages need to deliver particular behaviour. The user's choice of shell at the UI level isn't relevant to this.

> It's not as if the `env` version is more difficult to write.

Irrelevant. The reason for not using it in distribution packages is that it can lead to incorrect behaviour.

You're arguing with pretty much every Debian package maintainer here. Go look at distribution package shebangs if you don't believe me.

They don't have to delete anything for this. They can put the shell they need into a separate directory and prepend it to the PATH so their shell would be found first.

Reply on news.ycombinator.com