A short rant about #!/bin/sh

Lounge
1

I’m really annoyed by it.

If you pick at random a dozen or so shell scripts in your /usr/bin directory that start with the interpreter designation of

#!/bin/sh

you will find at least a few of them that use Bash-specific syntax (“bashisms”). And often, it is something as stupid as using

[[ "$string1" = "$string2" ]]

in situations where a perfectly valid POSIX command like

[ "$string1" = "$string2" ]

would suffice. People who do that deserve to be devoured by a giant frog-monster.

On a typical Arch/EndeavourOS install, there are dozens of such examples of scripting malpractice.

Why does Arch not have a guideline that requires every script that uses /bin/sh as a command interpreter to contain only POSIX-compliant commands?

If you are going to use Bash-specific syntax, just put #!/bin/bash as the first line of your script and there will be no problem!

It’s so simple, just two little characters: ba.

Now, because of such sloppiness, I can’t use Dash and symlink it to /bin/sh like on Debian or 'Buntu (at least not without editing dozens of shell scripts on every update). Really annoying.

:angry:

5 Likes
2

I agree that anything that uses sh as an interpreter should be limited to POSIX compliant syntax for portability. It only works because on Arch sh is a symlink to bash

That being said, if you want your scripts to truly portable it is better to use:

#!/usr/bin/env sh

There is no guarantee that sh is located at /bin/sh

3 Likes
3

Sure, portability is always a nice thing. But this is much worse than not being portable. I’m talking about shell scripts from the Arch repos that invoke sh to run what are actually Bash scripts.

2 Likes
4

Jeez, you’re uncompromising :joy:

image
image900×634 180 KB

And indeed - POSIX compliant shell scripts must be kept pure.

3 Likes
5

I made a short look at almost all EndeavourOS scripts, and none of them used #!/bin/sh, except two files (i3 configs) that were directly copied from elsewhere, and didn’t seem to use any bashisms.

I understand your concern, but I’d say EndeavourOS is not contributing to that sloppiness.

4 Likes
6

Yes, most, if not all of this sloppiness comes from upstream.

I am considering writing a script that runs through the entire output of pacman -Qlq and checks every shell script with checkbashisms tool, and replaces #!/bin/sh with #!/bin/bash on each one that fails the test.

For some inexplicable reason, I have the urge to use Dash as /bin/sh…

1 Like
7

Hopefully do that in a testing VM only… :wink:

1 Like
8

You will have to run it after every update…

Why not identify them and then propose the changes to the package maintainers? I know it is a lot more work but it will fix the problem for everyone.

9

Yes, I would have to run it on every update… Which would probably make updating take a lot longer.

I was considering making a list of the offenders, but I can only identify those which are installed on my machines.

Well, I could go through the Arch repos online and just look for every script, but that’s an incredible amount of work.

10

You should do that on pacman, then on AUR post all affected packages / files on their forum and tell them how they SUCK :rofl:

Perhaps propose necessary change in…script policy :upside_down_face:

11

Use a pacman hook for checking?

12

Isn’t that enough?

13

Of course not! :astonished:

We must parse all GitHub / GitLab / Private gits around the world and tell each one of them how much they suck as well :frog:

But Arch upstream would be good start :laughing:

@Kresimir Sorry, i couldn’t hold myself :joy:

1 Like
14

So… after about an hour of running a script which I quickly put together, this is the result:

core/automake 1.16.2-3
    /usr/share/automake-1.16/config.guess
    /usr/share/automake-1.16/install-sh
core/bash 5.0.018-1
    /usr/bin/bashbug
core/cronie 1.5.5-1
    /etc/cron.hourly/0anacron
extra/dkms 2.8.3-1
    /usr/lib/dkms/dkms_autoinstaller
core/gettext 0.21-1
    /usr/bin/autopoint
    /usr/bin/gettext.sh
    /usr/bin/gettextize
    /usr/share/gettext/projects/GNOME/team-address
    /usr/share/gettext/projects/KDE/team-address
extra/git 2.28.0-1
    /usr/lib/git-core/git-bisect
    /usr/lib/git-core/git-bisect--helper
    /usr/lib/git-core/git-web--browse
    /usr/share/git/git-jump/git-jump
    /usr/share/git/thunderbird-patch-inline/appp.sh
core/groff 1.22.4-3
    /usr/bin/eqn2graph
    /usr/bin/grap2graph
    /usr/bin/pdfroff
    /usr/bin/pic2graph
core/grub 2:2.04-8
    /usr/bin/grub-mkconfig
core/gzip 1.10-3
    /usr/bin/gzexe
    /usr/bin/zdiff
    /usr/bin/zgrep
core/hdparm 9.58-3
    /usr/bin/ultrabayd
extra/hwloc 2.2.0-1
    /usr/bin/hwloc-gather-topology
core/libtool 2.4.6+42+gb88cebd5-14
    /usr/bin/libtool
    /usr/bin/libtoolize
    /usr/bin/libtoolize
    /usr/share/libtool/build-aux/config.guess
    /usr/share/libtool/build-aux/install-sh
    /usr/share/libtool/build-aux/ltmain.sh
    /usr/share/libtool/configure
    /usr/share/libtool/configure.ac
community/lsb-release 1.4-18
    /usr/bin/lsb_release
extra/mjpegtools 2.1.0-5
    /usr/bin/lav2avi.sh
    /usr/bin/lav2mpeg
    /usr/bin/lavtc.sh
extra/mtools 4.0.24-1
    /usr/bin/tgz
    /usr/lib/resolvconf/dnsmasq
core/openresolv 3.11.0-1
    /usr/lib/resolvconf/named
    /usr/lib/resolvconf/pdns_recursor
    /usr/lib/resolvconf/pdnsd
    /usr/lib/resolvconf/unbound
extra/openvpn 2.4.9-2
    /usr/share/openvpn/contrib/pull-resolv-conf/client.down
    /usr/share/openvpn/contrib/pull-resolv-conf/client.up
community/os-prober 1.77-2
    /usr/bin/os-prober
    /usr/lib/linux-boot-probes/50mounted-tests
    /usr/lib/os-probes/50mounted-tests
    /usr/lib/os-probes/init/10filesystems
    /usr/lib/os-probes/mounted/05efi
extra/texlive-core 2020.55416-1
    /usr/share/texmf-dist/context/data/textadept/context/textadept-context.sh
    /usr/share/texmf-dist/web2c/mktexnam
    /usr/share/texmf-dist/web2c/mktexnam.opt
    /usr/share/tlpkg/installer/config.guess
extra/texlive-pictures 2020.55342-1
    /usr/share/texmf-dist/scripts/pgfplots/pgf2pdf.sh
core/usbutils 012-2
    /usr/bin/usb-devices
extra/xdg-utils 1.1.3+19+g9816ebb-1
    /usr/bin/xdg-desktop-icon
    /usr/bin/xdg-desktop-menu
    /usr/bin/xdg-email
    /usr/bin/xdg-icon-resource
    /usr/bin/xdg-mime
    /usr/bin/xdg-open
    /usr/bin/xdg-screensaver
    /usr/bin/xdg-settings
core/xz 5.2.5-1
    /usr/bin/xzdiff

There are some 23 packages on my system, many of these from the “core” repo, which ship some 65 scripts with which are identified as POSIX scripts by the file command (and use sh as the command interpreter), but are identified by the checkbashisms utility to contain POSIX non-compliant commands.

In total, some 823 scripts were checked, so the percentage of offending scripts was around 7.9%.

Ironically, a script from the package bash which is used to report bugs in Bash, is one of those offending scripts.

If anyone else wants to do a similar analysis, I’d be very interested in your results.

3 Likes
15

:rofl: :rofl: :rofl:

1 Like
16

Jesus…Some of the offenders are let’s say…IRONIC :rofl:

1 Like
17

Sigh…I bet some of those aren’t Arch packaging issues but upstream issues with the software itself.

For example, the scripts for os-prober appear to come entirely from the debian package. Reporting it to Arch wouldn’t even help.

Which leads to an interesting question, does Debian also use bash for sh? If not, is it an issue with the checking script?

1 Like
18

This pretty much says no on in arch cares. Or that since it points to bash they don’t want posix compliance

19

Debian uses Dash as the default system shell (and links it to /bin/sh), and requires all scripts with #!/bin/sh to be POSIX compliant. However, Dash will interpret some (very few) non-POSIX commands.

When it comes to os-prober, Dash will run it just fine, even though it contains the command type which is not POSIX-compliant.

Thus os-prober is probably a bad example, and could be tolerated.

20

i will asap change that I do not want to fight with that giant frogalike monster
:frog: :japanese_ogre:

7 Likes