Ich würde schon bei der Frage beginnen, was das für ein merkwürdiges SheBang in der ersten Zeile sein soll? Welche Version einer "bash" unterstützt denn eine (long-)Option "--shell=<something>"? Ich finde im Internet keine Stelle, wo Du das falsch abgeschrieben haben könntest.
Der Zweck und das Format eines SheBang ist z.B. hier erläutert:
https://wiki.ubuntuusers.de/Shebang_für_Shellskripte/
Mit diesen Kenntnissen gewappnet, würde ich auch die "cgi.assign"-Zeile anders formulieren ... daß es sich um ein CGI-Skript handelt, wird bereits anhand des Pfades, unter dem es gespeichert ist, klar. Hier könnte (nein: sollte) man also ".sh" als "Erweiterung" verwenden (oder meinetwegen auch ".bash") und nur diese dann auf "bash" mappen.
Und in ein "chroot jail" kriegt man eben genau das hinein, was man (vorher) dort untergebracht hat. Wie der Name "change root" ja schon sagt (und auch die man-Page ist da derselben Ansicht), ändert man damit das "root"-Verzeichnis für einen Prozess. Man muß also nur dafür sorgen, daß da alles das enthalten ist, was der aufgerufene Prozess später mal benötigen könnte - das startet dann bei der "bash" als Interpreter für CGI-Skripte und geht bis zu den Kommandos, die von dieser "bash"-Instanz verwendet werden sollen (hier bei Dir betrifft es im Moment die Kommandos "date" und "env").
Die "bash" unterscheidet eben zwischen "builtins" (das sind die Kommandos, die sie bereits selbst kennt) und "external commands" (dazu gehören auch "date" und "env" - am besten liest man auch hier mal die "man page" zur "bash", das sind bei mir nur 3219 Zeilen) - wenn letztere nicht anhand des Suchpfads gefunden werden (wobei auch bei einer leeren PATH-Variablen normalerweise ein paar Verzeichnisse durchsucht werden:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html), kann die Shell sie auch nicht ausführen. Wenn Du hier (z.B. mit einem
exec 2>&1) auch noch STDERR in Deine Ausgabe umleitest (man kann ja auch erst mal "text/plain" verwenden und muß nicht sofort HTML generieren wollen), dann siehst Du auch die Probleme, die Dein Skript noch so hat.
Du müßtest also unterhalb des Verzeichnisses, was Du als "chroot"-Basis verwenden willst, alles andere schon vor dem Start des HTTP-Servers so einrichten, daß da die (i.d.R. notwendigen) Verzeichnisse nach LSB (
https://de.wikipedia.org/wiki/Linux_Standard_Base) existieren und in diesen Verzeichnissen all die Kommandos existieren, die später von den CGI-Skripten benötigt werden ... natürlich inkl. der Bibliotheken und allem Pipapo. Da ist es i.d.R. am einfachsten, man linkt sich die "echten" Verzeichnisse einfach in sein Jail bzw. man verzichtet (wenn man nicht gerade eine Site betreibt, wo die Hacker Schlange stehen bei ihren Angriffsversuchen) einfach erst mal auf "chroot", bis die Site "fertig" ist und man sicher weiß, wie man das Jail aufbauen soll und was da alles drin sein muß.
Schon die Frage, warum es nun unbedingt die "bash" sein soll und warum die "ash" der bereits existierenden BusyBox da nicht ausreicht, würde so manchem sicherlich Kopfzerbrechen bereiten ... und auch die Verwendung von "echo -e" würde man (ich) bei jemandem, der Shell nicht als "tägliches Brot" verwendet, nicht wirklich empfehlen.
Zwar funktioniert das unter "bash" oder "ash" oder "dash" (usw.) tatsächlich in den allermeisten Fällen, aber bei FreeBSD (oder generell bei BSD-Derivaten und damit auch bei MacOS X) scheitert man damit schnell mal:
https://www.freebsd.org/cgi/man.cgi?query=echo und zum Funktionsumfang nach POSIX-Spezifikation gehört letztlich gar keine Option:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html ... aber hier macht es ein "printf" ebenso und das funktioniert dann (wenn man sich an den POSIX-Standard hält) auch überall in derselben Art und Weise und man hat etwas gelernt, was man praktisch ÜBERALL verwenden kann.
Zwar kann man auch "echo" benutzen (und alte Haudegen schwören darauf, weil es zu ihrer Zeit meist noch gar kein "printf" gab - siehe die Bemerkungen in der POSIX-Spezifikation) - aber wer es gleich mit "printf" lernt (was automatisch "cooked" arbeitet und die Escape-Sequenzen verarbeitet), der benutzt dann eben auch später weiterhin "printf" (oder er muß dann erst wieder mühsam "umlernen" und ich kann aus eigener, leidvoller Erfahrung berichten, daß das "ein Prozess" ist) und ist damit auf der sicheren Seite.
Die Frage, wie PATH tatsächlich aussieht, kannst Du also nicht mit einem
$(env) klären, sondern da bietet sich ein
printf "PATH=%s\n" "$PATH" eher an. Ein gänzlich leeres Environment wäre für ein CGI-Skript (oder -Programm) aber auch gänzlich untypisch - da sind wenigstens die Variablen enthalten, die dem Skript Auskunft über die Natur des Requests geben (woher kam er, HTTP oder HTTPS, aufgerufene URL, Servername, Portnummer, etc.) und wenn auch die - angeblich - nicht vorhanden sind, ist es Zeit, die "Anzeige" zu hinterfragen und erst einmal sicherzustellen, daß diese auch funktioniert.
==========================================================================
Aber gehe ich recht in der Annahme, daß Du hier:
den lighttpd-Webserver via FREETZ erfolgreich installiert.
wieder Freetz und Freetz-NG durcheinander geworfen hast? Wenn ja, vergiß alles, was ich geschrieben habe - von Freetz-NG habe ich keine Ahnung.
==========================================================================
EDIT: Eins noch ... wenn Du - wie weiter oben vorgeschlagen - die Ausgabe von STDERR auf STDOUT legst, kannst Du auch ein "-x" noch ins SheBang schreiben (diese Option gibt es dann wirklich) und Du erhältst ein wunderschönes Protokoll all dessen, was Dein Skript da so veranstaltet. Das wäre mein empfohlener Weg (zusammen mit der Ausgabe als "text/plain", bis die Kommandos komplett sind und funktionieren) für die "Programmierung" von CGI-Skripten mit einer Shell. Erst danach kann man dann auf "text/html" umstellen und sich ansehen, was der Browser aus der HTML-Ausgabe macht. Selbst wenn man darin dann noch Fehler hat und irgendwelche Ausgaben des Skripts ändern muß, sollte sich "am Rahmen" bzw. an den ausgeführten Kommandos dadurch nichts mehr ändern.
, meine Meinung.
