BOLO: Bourne Shell Shebangs Outdated

[JesseSteele]

I’ve recently began playing with some legacy Bourne Shell commands, namely the GitHub repo heirloom-sh. I have it installed at /usr/local/bin/sh and nothing links to it. Still, some scripts call it somehow.

I posted an expanded question on the Unix & Linux SE site also.

Background

For most systems, /bin/sh is a link to /bin/bash, letting everything for BASH work in a mis-labaled Bourne Shell script.

For Debian, /bin/sh is a link to /bin/dash (Debian Shell), carrying many Bourne Shell limits. So, Debian/Ubuntu devs might not run into the same problems of BASH scripts still working with #!/bin/sh. This may mostly be a non-Debian dev issue.

Most of our scripts are written for BASH (/bin/bash) and cannot work for Bourne Shell (/bin/sh). But, many coders still put #!/bin/sh for the shebang (#!/...) anyway, then code as if for the BASH #!/bin/bash.

Affecting VSCodium

One of these I’ve found is the vscodium AUR package, and vscodium-bin (which I use). As long as I have the legacy shell installed at /usr/local/bin/sh, some things break.

/opt/vscodium-bin/bin/codium (Where VSCodium is installed to from the AUR)…

had this:

#!/usr/bin/env sh

…which would not start from the GUI, and then from the CLI threw this error:

/opt/vscodium-bin/bin/codium: syntax error at line 20: `YN=$' unexpected

So, I commented and changed the shebang to this:

#!/usr/bin/bash

…then it worked.

Affecting Manjaro specifically

In fact, when I had /bin/sh linked to /usr/local/bin/sh (the legacy Bourne Shell), my Manjaro system wouldn’t even boot. I had to use a Manjaro install USB to get to the OS disk and change /bin/sh to link back to /bin/bash.

That may be an issue that Manjaro devs should know about.

Perhaps any script at all that uses #!/bin/sh or #!/bin/env sh should be fixed in Manjaro, and upstream sources get a bug report.

---

I’m posting this on Manjaro because, while an Arch problem, then want me using Arch or I get ignored. But, this is a wider developer issue.

[Teo]

@JesseSteele

Perhaps any script at all that uses #!/bin/sh or #!/bin/env sh should be fixed in Manjaro, and upstream sources get a bug report.

In the linux world there are many things inherited and abandoned and carried over from some 20-30 years ago. So yes, you are right, but it is a problem with many packages from many developers. It will probably take another 30 years (see how the transition from X to Wayland is going).

@JesseSteele

In fact, when I had /bin/sh linked to /usr/local/bin/sh (the legacy Bourne Shell), my Manjaro system wouldn’t even boot. I had to use a Manjaro install USB to get to the OS disk and change /bin/sh to link back to /bin/bash

Well, in manjaro (and probably in many other distros) the workaround is to link sh to bash. So you effectively replaced bash for many (old) scripts systemwide. Not entirely surprising some function somewhere is not exactly the same between bash and heirloom and some script crashed early in the boot process. Not really a bug i would say.

[linux-aarhus]

@JesseSteele

In fact, when I had /bin/sh linked to /usr/local/bin/sh (the legacy Bourne Shell), my Manjaro system wouldn’t even boot.

One speculates how you ended up with that one - I know - you told me - the thing with the $PATH is that /usr/local/bin comes before /usr/bin so one could say it is a self-inflicted issue that cannot be solved by raising issues upstream.

Arch package rules state that a package should never place anything in /usr/local.

Most packages in AUR has been created for other distributions - vscodium is not an exception.

@JesseSteele

But, many coders still put #!/bin/sh for the shebang (#!/...) anyway, then code as if for the BASH #!/bin/bash.

That is strictly not a distribution problem but more so a human error when a coder don’t know the difference between sh and bash.

I usually use the #!/usr/bin/env bash - and it is learning phase.

I admit that in my early days I didn’t know the difference either but learned by looking at other shell scripts - which quite often had the #!/bin/sh - so until I learned there is a difference … I did it wrong

In fact I didn’t realise until you told me that /bin/sh is symlink to /usr/bin/bash - so thank you for enlightening me on this

@JesseSteele

In fact, when I had /bin/sh linked to /usr/local/bin/sh (the legacy Bourne Shell), my Manjaro system wouldn’t even boot. I had to use a Manjaro install USB to get to the OS disk and change /bin/sh to link back to /bin/bash.

That is likely because - as Arch sh does not exist…

I have tried checking how many scripts there is which are using the sh hashbang

grep -rl '#! /bin/sh' /usr

and variations thereof #!/usr/bin/sh or #!/usr/bin/env sh #!/bin/sh

And while there is some - I can’t say I find it alarming - changes takes time - that is well known…

[xabbu]

If bash is called as sh, it starts in an special POSIX Mode. It is not the same as a normal bash prompt.

Bash POSIX Mode (Bash Reference Manual)

[linux-aarhus]

@xabbu

f bash is called as sh, it starts in an special POSIX Mode. It is not the same as a normal bash prompt.

When I verified that /bin/sh is a symlink to bash - I speculated why the prompt is different when invoking chroot without a command.

I remembered that chroot default to sh

If no command is given, run '"$SHELL" -i' (default: '/bin/sh -i').

chroot /mnt

vs

chroot /mnt /bin/bash

And your comment explain exactly that

[Aragorn]

@xabbu

If bash is called as sh, it starts in an special POSIX Mode. It is not the same as a normal bash prompt.

More specifically, it then starts in a strict Bourne mode, which does not support so-called bash’isms. Technically it’s not strict POSIX mode yet, because for that it would need to be started with the POSIXLY_CORRECT flag.

[linux-aarhus]

There is an excellent reply to your topic on https://unix.stackexchange.com/a/793381