okay, das mit dem Javascript Code war ein wenig missverständlich ausgedrückt. Sorry.
Wenn die Seite normal, nicht über den Shell-Code aufgerufen wird, funktioniert der Code, d.h. es geht nicht um die grundsätzliche Funktion. Deshalb hab ich ihn nicht hinzugefügt.Dadurch das der Skript-Code nicht abgearbeitet wird, vermute ich, dass die Seite immer noch aus dem Cache geladen wird.
Aber vielleicht liegt das Problem auch nicht am Cache.Ein Onlinebeispiel stellt sich ein wenig schwierig dar, zumindest für einen fast Laien wie mich.
Im groben Zusammengefasst:
Die Html Seite ( mit Javascript) macht keine Probleme beim normalen Aufruf.
Nur wenn ich mit dem oben genannten Shell Skript die Seite aufrufe werden die alten Werte in die Felder geladen. Nach Aktualisierung der Seite passen die Werte wieder.Der mipx-Task (siehe Shell-Skript) übernimmt das suchen und eintragen der jeweiligen config.ini Einträge. (funktioniert einwandfrei)
Ich stückele das jetzt mal mühselig zusammen.
Du hast einerseits ein SHELL-SKRIPT:
/home/mipx
weiter eine statische WEBSEITE:
"/var/www/config-license.htm"
zudem das CGI-SKRIPT mit dem Inhalt:
#!/bin/sh
echo "Cache-Control: no-cache,no-store, max-age=0";
echo "Content-Type: text/html; charset=utf-8"
echo "";
if [ -e /home/mipx ]; then
/home/mipx -pconf "/home/config.ini" "/var/www/config-license.htm"
und außerdem noch eine KONFIGURATIONSDATEI:
/home/config.ini
Ziel ist wohl, dass beim Aufruf des CGI-SKRIPTES dieses das SHELL-SKRIPT aufruft, welches aus der den Daten der KONFIGURATIONSDATEI eine neue statische WEBSEITE erzeugt. Mehr war Deiner Beschreibung nicht zu entnehmen.
Wenn, wie Du darlegst, das SHELL-SKRIPT funktioniert, dann muss natürlich die WEBSEITE vom Browser neu abgeholt werden, denn bekommt von der Änderung so viel mit wie Du, wenn Indien ein Sack Tee umfällt. Das SHELL-SKRIPT ist für uns eine Black-Box. Es kann sein, dass daran jeder Hilfversuch scheitern muss, nämlich dann, wenn in der Käfer krabbeln.
Was passiert, wenn Du das CGI-Skript ausführst wissen wir gar nicht. Wir wissen, was zum Teil passieren könnte. Aber nicht, was auf die Abarbeitung des SHELL-SKRIPTes folgt.
Wenn, wie Du darlegst, das SHELL-SKRIPT funktioniert, sollten aber in jedem Fall nach der tatsächlichen Aktualisierung der WEBSEITE im Browser die neuen Daten auch sichtbar werden. Holt der Browser die WEBSEITE neu ab oder nimmt er die aus dem Cache?
Fehlerquellen:
Gibt denn Dein CGI-Skript irgend etwas aus? Ich sehe nämlich von hier: Es ist nicht vollständig. Da fehlt schon das fi am Ende des IF-Konstruktes. Alle Pfadnamen sehen richtig beschissen aus und sind nicht glaubwürdig.
Die Rechte.
--- Darf denn der Webserver(!) /home/mipx überhaupt ausführen?
--- Hat denn der Webserver das Schreibrecht an /var/www/config-license.htm
- oder verwendest Du außerdem noch setuid- Geschichten?
Cache:
Zweimal Browser - zweimal Cache, zweimal siehst Du nicht, was passiert ist, sondern was irgend wann mal war. Ideal für Kopfschmerzfetischisten!!!
Jetzt ist es Dein Job das zu lesen, zu prüfen und eine nachvollziehbare Beschreibung des "Fehlers" zu verfertigen, die am besten die BEGRIFFE
SHELL-SKRIPT /home/mipx
CGI-SKRIPT (Position unbekannt)
KONFIGURATIONSDATEI /home/config.ini
WEBSEITE /var/www/config-license.htm
verwendet statt auch uns nur noch mehr zu verwirren. Das ist nämlich alles ganz schön "durch die Brust ins Auge" (auch "historisch gewachsen") genannt.
Wir wollen GENAU wissen, was die Dateien
SHELL-SKRIPT /home/mipx
CGI-SKRIPT (Position ###NOCH### unbekannt)
KONFIGURATIONSDATEI /home/config.ini
WEBSEITE /var/www/config-license.htm
für Rechte "haben".
getfacl /home/mipx zeigt die für /home/mipx. Die anderen wollen wir aber auch!
Unter welchem Benutzer läuft Dein Webserver?
Was steht in der CGI-Datei WIRKLICH.
Und wir wollen GENAU wissen, was von wem wie aufgerufen wurde und was das Resultat war- und zwar nicht die im Browser zu sehende Vermutung, sondern in der statischen WEBSEITE. Auch Deine Beschreibungen dazu waren "ideal für Kopfschmerzfetischisten".
Vermutlich fällt Dir dabei, wenn Du gerade SCHRITT FÜR SCHRITT die Funktionen durchgehst um uns eine aussagefähige Fehlerbeschreibung zu geben, auch der konkrete Fehler auf und somit die Lösung ein.
Ohne die verlangten Daten, vollständige Skripte und ohne eine brauchbare Problembeschreibung können wir nur zur Filzbrille raten. Dann wird das Problem wenigstens nicht mehr sichtbar. Es gibt sehr viele, die sind mit solchen Lösungen zufrieden sind. (Zuletzt sogar die berühmte japanische Atomaufsicht!)