PHP "shebang" (#!/use/bin/php) von Skripten entfernen

[j3nsch]

Für die meisten OPUS 4 Skripte ist es nicht notwendig, dass sie ohne Verwendung von php ausgeführt werden. Für das bin\opus4 Skript ist es sinnvoll, da es häufig verwendet wird und so die Ausführung vereinfacht wird. Bei den anderen Skripten sollte die erste Zeile mit #!/usr/bin/php (shebang) entfernt werden.

In manchen Skripten steht da auch noch "php5", was vermutlich auf den meisten Systemen nicht mehr funktioniert.

[j3nsch]

Nur bin/opus4 enthält noch die Angabe, damit das Skript ohne php davor, direkt ausgeführt werden kann.

[alw-bsz]

Bei uns führt das Entfernen der Shebang dazu, dass beim Updaten der Datenbank (update.sh) die PHP-Files nicht mehr als PHP interpretiert werden und folgende Fehlermeldung auftritt:

Running update scripts ...
Running '015-Add-InC-licence.php' ... 
/opt/opus/test481/opus4/scripts/update/015-Add-InC-licence.php: 1: cannot open ?PHP: No such file
/opt/opus/test481/opus4/scripts/update/015-Add-InC-licence.php: 3: /bin: Permission denied
/opt/opus/test481/opus4/scripts/update/015-Add-InC-licence.php: 4: Syntax error: "(" unexpected
Error (2) running '015-Add-InC-licence.php'! 

ERROR - An error occured during updating!
Error (2) running '015-Add-InC-licence.php'!
Update aborted!

Wenn man die Shebang (#!/usr/bin/env php) wieder in die PHP-Files einfügt, laufen die Scripte korrekt durch.

[j3nsch]

Danke. Ja, ich kann das Problem hier nachvollziehen. Interessant, dass das erst jetzt kommt. Die Änderungen war in OPUS 4.8. Führt niemand das Update-Skript aus bzw. meldet nicht, wenn dabei Probleme entstehen? Nur am Rand, das hätte ein neues Ticket sein sollen bzw. das alte Ticket muss mindestens wieder geöffnet werden, da wir uns sonst "merken müssen", dass es ein offenes Problem gibt. Dafür haben wir ja die Issue-Verwaltung. Wenn wir nur fünf Tickets hätten wäre es nicht so wichtig, aber immer noch richtig. :)

So, zum eigentlichen Problem. Ich denke nicht, dass das Hinzufügen der Shebang, die beste Lösung ist. Beim Beispiel oben ist der Pfad ein anderer als vorher in den Skripten. Es könnte als immer wieder Probleme mit abweichend konfigurierten Systemen geben. Vermutlich hat das auch mal so wie es jetzt ist funktioniert und dann hat sich etwas in Ubuntu bzw. Debian geändert. Das würde auch erklären, warum es im letzten Jahr keine Meldungen gab. Ich denke, der sinnvollere Ansatz ist php gezielt im Code für die Ausführung der Skripte aufzurufen. Evtl. ist das dann auch unabhängig vom Pfad für PHP möglich.

[j3nsch]

Das Problem sollte in OPUS 4.8.0.6 (gerade veröffentlicht) behoben sein.

[alw-bsz]

Jetzt tritt der Fehler nicht mehr auf - danke! Uns ist der Fehler tatsächlich erst vor Kurzem beim Testen von 4.8.1 aufgefallen. Bei den Instanzen, die wir bislang von 4.7.1 auf 4.8 upgedated haben, gab es das Problem nicht. Entweder mussten da keine untergeordneten Update-Scripte in PHP ausgeführt werden, weil es keine Änderungen gab, oder wir hatten sie in den betroffenen Instanzen bereits vorweg genommen.

Ich würde gerne geschlossene Issues wieder öffnen, aber ich kann das nicht (fehlende Berechtigung?) ;-).