Daß ich das nur in sehr eng umrissenen Grenzen "gut" finde, ist aber auch nichts Neues ... aber ich will die alte Diskussion um binäre Dateien ohne irgendwelche Signaturen der jeweiligen Autoren gar nicht erneut aufwärmen; manchmal geht es eben wirklich nicht anders.
Aber so, wie die Installation von Java für den FBEditor notwendig ist, braucht es eben auch für diese PHP-Lösung eine Basis ... meinetwegen auch eine als "portable". Daran, daß es eben keine "Bordmittel" sind (und ich betone ja, daß es Jammern auf hohem Niveau ist), ändert das nichts.
Ich hätte es eben besser gefunden, wenn das auf der Basis von PowerShell o.ä. für Windows-Benutzer verfügbar wäre, weil die dann eben keine PHP-Executables von irgendwo laden müßten und sie ggf. sogar auf ihrem PC liegen lassen (wenn man sie schon mal geladen hat) und dann beim Aufruf auch noch "immer mit diesem Programm öffnen" auswählen ... das sind auch keine ausschließlich theoretischen Überlegungen, das sind Ergebnisse von eigenen Beobachtungen "im Freiland".
Bleibt dann am Ende so eine "portable PHP version" einfach unbeachtet auf einem PC stehen (auch die Internet-Suche nach "portable PHP windows" ist nicht ganz uninteressant, weil man dann recht schnell feststellt, daß es eigentlich gar keine "standalone"-Version einer portablen PHP-Installation gibt) und taucht irgendwann in PHP ein neues Loch auf, welches sich auch in einer solchen "Nicht-Installation" ausnutzen ließe, dann denkt da kein Mensch mehr daran, daß irgendwann mal PHP-Files auf den PC kopiert wurden und (im Extremfall) auch jetzt noch die Erweiterung "php" bei einer Text-Datei zum Aufruf dieser Reste führt.
Da es dafür auch keine regulären Updates gibt, ist so etwas immer eine potentielle Schwachstelle (hier liegt auch der Unterschied zu den von mir bevorzugten "Bordmitteln", weil die eben i.d.R. gepflegt und aktualisiert werden) und wenn man tatsächlich so eine portable Version anbietet (und als Nutzer verwendet), dann sollte man die auch nur für die Dauer der tatsächlichen Verwendung bereithalten. Das macht dann wieder einen höheren Aufwand, wenn man "fb_tools" mehr als einmal verwenden will.
Die Idee bei den "portablen Apps" ist es sicherlich weniger gewesen, so viele Programme wie möglich in unterschiedlichsten (auch älteren) Versionen irgendwo auch einem Rechner auch ohne Installation speichern und ausführen zu können ... beim ursprünglichen Zweck stellt sich das von mir gesehene Problem dann wieder vollkommen anders dar, denn dann verläßt die PHP-"Installation" den USB-Stick gar nicht erst und somit können auch keine Rudimente auf dem Rechner verbleiben, wenn der Stick wieder abgezogen wurde.
Daß auf einen PC keine PHP-Installation gehört, wenn man sie nicht wirklich braucht und daß man eine installierte Version auch aktuell halten muß (hat PHP7 einen Autoupdate-Mechanismus? ich weiß es nicht), ist sicherlich "Basiswissen", was aber leider nur allzu oft von Benutzern ignoriert wird und daher bin ich eben prinzipiell gegen die Installation von Zusatzsoftware (die sich nicht selbst um ihre Aktualisierung kümmert, was hier die "fb_tools" schon fast vorbildlich machen, aber m.E. (so tief habe ich auch nicht hineingesehen) nicht für die PHP-Installation, das wäre auch recht viel verlangt), wenn es andere Wege gibt.
Und auch wenn man es kaum glauben mag ... es gibt sogar Linux-Installationen ohne PHP (bei mir sogar grundsätzlich, PHP kommt nur für Tests in User-Verzeichnissen in Frage, es gibt keine "Site-Installation").
Zum Abschluß auch noch einmal ganz deutlich die Feststellung, daß ich das sehr schön gelöst finde ... insbesondere der Automatismus mit dem Import der verschlüsselten Daten als Benutzernamen für "cfgtakeover" hat was und auch die vorhandene Update-Prüfung stellt ohne großes Brimborium sicher, daß der Benutzer immer mit einer halbwegs aktuellen Version arbeiten kann (wenn er Interesse daran hat).
Das ändert aber nichts daran, daß ich es weiterhin schade finde, wenn dazu PHP benötigt wird. Das ist eben kein Programm, was der Durchschnittsbenutzer auf seinem PC hat (wenn das im MacOS X automatisch vorhanden ist, sorgen dort aber immerhin andere Mechanismen dafür, daß ein PHP-File nicht einfach so aufgerufen wird) und damit ist da m.E. fast noch die ruKernelTool-Lösung mit integriertem Interpreter vorzuziehen (wenn die nicht einigen AV-Lösungen quer liegen würde), weil die damit auch ständig den Interpreter aktualisiert.
Man mag es ja finden, wie man will ... ich würde hier sogar wieder ein "richtiges" C-Programm (wenn das portabel zu machen ist, was bei CLI eigentlich nicht soo schwer ist und auf MacOS X und Linux ist normalerweise sogar der dazu benötigte C-Compiler bereits vorhanden und bei Windows ebenfalls kostenlos benutzbar) besser finden, weil es zwar ebenso schwer für die meisten zu verifizieren und zu installieren sein würde, wie die PHP-basierte Lösung, aber weil damit eben auch nicht das Loch einer (auf dem Client! - auf dem Server ist das wieder etwas vollkommen anderes) eher ungewöhnlichen Interpreter-Umgebung gerissen wird, um das sich nach aller Erfahrung hinterher niemand mehr kümmert.
Auch Javascript (als lokale Lösung in einem Browser-Fenster) wäre eine Möglichkeit und sicher noch vieles andere mehr - wenn hier jemand mit einer Lösung in REXX auftauchen würde und man dafür erst einmal "Regina" zum Laufen kriegen müßte (und das ist durch den einfachen Ruf "Regina, komm mal her." wohl eher nicht erledigt), würde ich genauso argumentieren.
Also laß mir einfach den Wermutstropfen ...
