gpg-error-config-test.sh
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	johngh
	Jun 14 2019, 11:12 AM

Description

As in bug 5b42cf74aae3, libgpg-error-1.36/src/gpg-error-config-test.sh is a bash script with a #! line calling /bin/sh

If it is running on a system where #!/bin/sh is not bash then make check fails:

$ make check
Making check in m4
make[1]: Entering directory `/var/tmp/libgpg-error-1.36/m4'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/var/tmp/libgpg-error-1.36/m4'
Making check in src
make[1]: Entering directory `/var/tmp/libgpg-error-1.36/src'
make  check-am
make[2]: Entering directory `/var/tmp/libgpg-error-1.36/src'
make  check-TESTS
make[3]: Entering directory `/var/tmp/libgpg-error-1.36/src'
./gpg-error-config-test.sh: bad substitution
FAIL: gpg-error-config-test.sh
=======================================
1 of 1 test failed
Please report to https://bugs.gnupg.org
=======================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/var/tmp/libgpg-error-1.36/src'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/var/tmp/libgpg-error-1.36/src'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/var/tmp/libgpg-error-1.36/src'
make: *** [check-recursive] Error 1

(Tested on Solaris 10)

When the first line of src/gpg-error-config-test.sh is changed to #!/bin/bash the make check passes successfully.

It is not reasonable to assume (particularly if on a non-Linux system) that /bin/sh will always be bash.

/bin/sh is expected to represent a vanilla Bourne shell compatible shell.
It's OK for an OS to use a shell which provides a superset of Bourne shell functionality as /bin/bash, but not for a script to assume that /bin/sh will support features which are not available in Bourne shell.

The bulk of the script relies on more efficient and easier to work with bash specific syntax features, e.g.:

srcdir=${0%/*} instead of srcdir=`dirname $0`
$(cmd) instead of `cmd`
if ! $CMD instead of $CMD; if [ $? != 1 ];

It would thus be simpler and more useful to declare src/gpg-error-config-test.sh to the shell as what it is (a bash script) rather than porting it to be a Bourne shell script.

Details

Version: libgpg-error-1.36

Revisions and Commits

rE libgpg-error
	rE7a7caf4ba1c4 build: Take care of POSIX shell path.

Related Objects
Search...

		Status	Assigned	Task
		Resolved	• gniibe	T4574 Change #!/bin/sh to #!/bin/bash in libgpg-error-1.36/src/gpg-error-config-test.sh
		Resolved	• werner	T4772 Release libgpg-error 1.37

Event Timeline

johngh created this task.Jun 14 2019, 11:12 AM

This is all valid Bourne shell syntax. In detail:

${0%/*} is "Remove Smallest Suffix Pattern" (POSIX 1003.1, Shell and Utilities, Issue 6, 2.6.2, page 39)

$(cmd) is "Command Substitution" (ibd. 2.6.3, page 40)

if ! $CMD is "Pipeline" and "The if Conditional Construct" (ibd, 2.9.2, page 49 and 2.9.4.4, page 53)

If you don't have a Posix compliant shell installed, please do so. We do not support legacy versions of the Bourne shell.

Thanks for your feedback Werner.

Wow, thanks for the specific references! :-)

I'm certainly not asking you to support legacy versions of Bourne shell.
I'm asking if you could change the #!/bin/sh line to #!/bin/bash

As stated above, this is on Solaris 10 (14 years old now)
It makes no sense for scripts have to be backwards compatible with such an old version of Bourne shell. I would never ask for such a thing.

We certainly do have POSIX compliant shells installed, e.g. as /bin/bash, /bin/ksh /usr/sbin/sh etc, just Solaris 10 doesn't offer a POSIX shell in /bin/sh

We're not running such an old OS for the fun of it!
It's in an enterprise scale corporate environment, running a standard build across a large network of servers, and the dev and test machines need to remain compatible with our production systems, otherwise, it would invalidate our test environments.

In this scenario, we don't have the luxury of being able to upgrade /bin/sh - who knows what other scripts on the system this would break.
There's no way we could possibly fully regression test everything else that needs /bin/sh, and there's no way I could ever justify submitting a request to so drastically upgrade /bin/sh to our change control, for the sake of one little test script.

I'm obviously fine to update our own copy of the script.
I'm just offering the suggestion of the change to make the script more robust and compatible with a larger range of target hosts, so other people don't run into the same problem.

I wrote the script and the intention is supporting old systems using POSIX shell. Our goal here is: Not introducing (additional) dependency to Bash.

I believe that Korn Shell supports POSIX shell, and it works on Solaris 10.
If it is true, use of Korn Shell on Solaris 10 is the right way, because it doesn't add more dependency.

@johng: I understand your problems and recall that Linux systems had a hard to time to replace all bashism with standard Posix. The problems with /bin/sh on Solaris seems to be even more persistent.

@gniibe: What do you think: Can we detect a pre-posix shell installed as /bin/sh and then re-exec us using another installed shell? I mean a simple test and not all the hell autoconf uses to detect different versions of zsh. Say, if we figure out that we are on Solaris and are using /bin/sh we try to use /usr/bin/sh or /usr/bin/ksh - whatever is installed? Testing the suffix pattern feature might be the easiest test and suifficient in our case.

• gniibe added a commit: rE7a7caf4ba1c4: build: Take care of POSIX shell path..Jun 18 2019, 9:51 AM

Fixed in master, by using /usr/xpg4/bin/sh on Solaris.
Perhaps, some old Unix system like Tru64 would need same care.

• gniibe added a subtask: T4772: Release libgpg-error 1.37.Dec 6 2019, 5:25 AM

• werner closed this task as Resolved.Feb 7 2020, 1:47 PM

• werner mentioned this in T4772: Release libgpg-error 1.37.

• werner closed subtask T4772: Release libgpg-error 1.37 as Resolved.

Change #!/bin/sh to #!/bin/bash in libgpg-error-1.36/src/gpg-error-config-test.shClosed, ResolvedPublicActions