FS#57629 - [protege] /usr/bin/protege breaks #! line of run.sh

Attached to Project: Community Packages
Opened by Jens G (Thah) - Sunday, 25 February 2018, 10:50 GMT
Last edited by Morten Linderud (Foxboron) - Sunday, 25 February 2018, 13:12 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Morten Linderud (Foxboron)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Running protege when /bin/sh points to /bin/dash exits with "run.sh: 3: run.sh: Bad substitution" error.

Additional info:
* package version 5.2.0-4
* /usr/bin/sh -> dash instead of bash

Explanation:
The upstream run.sh script takes pains to ensure that it is run under bash using the #! line.
However, /usr/bin/protege calls it using "sh run.sh" which ignores the #! line and runs run.sh
under whichever shell /bin/sh points to. It basically undoes upstream's precaution. See e.g. best
answer of https://stackoverflow.com/questions/20615217/bash-bad-substitution/20616103

Steps to reproduce:
Point /bin/sh to dash and run /usr/bin/protege

Possible fixes:
1. Change /usr/bin/protege's call of run.sh to: CMD_OPTIONS=[...] /bin/bash run.sh "$@"
2. Avoid /bin/$WHATEVERSHELL altogether by using: CMD_OPTIONS=[...] /usr/share/java/protege/run.sh "$@"

Both avoid the call through the /bin/sh link.
#1 enforces /bin/bash (in compliance with upstream) while #2 leaves shell selection to upstream's run.sh.

p.s.: /usr/bin/protege itself is POSIX compliant so its own #!/bin/sh is fine.
This task depends upon

Closed by  Morten Linderud (Foxboron)
Sunday, 25 February 2018, 13:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fix with 5.2.0-5. Went with option two so we can blame upstream more.
Comment by Eli Schwartz (eschwartz) - Sunday, 25 February 2018, 12:56 GMT
I see no reason to hardcode any sort of shell at all, it seems silly to invoke an executable shellscript by first invoking the shell and then invoking the script. Also it appears the upstream script already changes directory as needed. Also it appears that the only thing the upstream script does is add yet more /usr/bin/java arguments, then run protege after dropping all but the first argument.

Also, consider filing a bugreport with upstream, for using a quite ugly method of changing directory to the location of the run.sh file. They seem to have gone to extreme lengths to ensure this still works when the run.sh script is *sourced* rather than *executed*, when they should just use:

```
cd "$(dirname "$(readlink -f -- "$0")")"

./jre/bin/java -opts -more_opts -lots_more_opts "$@"
```

Which is POSIX sh except for the reliance on the GNU extensions to readlink, which will of course be *always* available on Linux.

For their macOS version, I suggest giving up in despair and using `perl -MCwd=abs_path -le 'print abs_path readlink(shift);' "$0"`

Loading...