Projekt: Installations Skript zur Vorbereitung des FF zur Nutzung von JavaScript. [erledigt]

Zitat von BrokenHeart

Es geht meines Erachtens nur um die initiale Entscheidung User-JS zu nutzen, nicht um die fehlende Fähigkeit per Anleitung Dateien zu kopieren.

Für die Entscheidung ist die Methode unerheblich. Die Aufgabe des Scripts ist es, das Kopieren und Einfügen abzunehmen. So steht das auch in Beitrag #1 beschrieben und darum dreht sich der bisher gezeigte Code. Meinetwegen können wir sagen, dass das zu vereinfacht dargestellt ist, weil der Download noch inbegriffen ist. Aber wenn das Ziel ist, diese wirklich simplen Aufgaben noch einfacher zu machen (und das hast du selbst ja als Ziel bestätigt), folgt daraus doch, dass eine Alternative zum Download, Copy & Paste gesucht wird, weil das offensichtlich selbst nach wirklich sehr einfach zu verstehender Anleitung immer noch zu kompliziert für manche Anwender zu sein scheint.

Zitat von BrokenHeart

Je einfacher etwas erledigt werden kann,

Grundsätzlich ist das ein erstrebenswertes Ziel. Aber es fängt ja schon damit an, dass vermutlich die meisten Anwender gar nicht wissen, was ein Shell-Script ist und was damit anzustellen ist. Das muss also auch erst erklärt werden. Wenn man Linux- oder macOS-Nutzer fragt, wissen das vermutlich die meisten, aber ausgerechnet für diese Nutzer ist das Script überhaupt nicht. Auf Windows kommen Endanwender eher selten bis gar nicht mit so etwas in Berührung. Und dann besitzt das Script auch noch Variablen, die ggf. anzupassen sind, und der Anwender muss herausfinden, was die korrekten Werte sind. Und das soll für einen Anwender, vor allem für einen aus der oben genannten Zielgruppe, wirklich einfacher sein? Das sehe ich einfach überhaupt nicht.

Zitat von BrokenHeart

dass sich das auch Leute einmal anschauen, die nach Hinweisen auf die Anleitung meinen: "..das ist mir alles zu kompliziert und zu viel Aufwand" , auch wenn das objektiv gar nicht der Fall ist.

Woher kommt die Annahme, dass ausgerechnet die Nutzer, die vor Copy & Paste schon zurückschrecken, vor einem Shell-Script nicht erst recht zurückschrecken? Das ist ja noch viel weiter von dem entfernt, womit absolute Computer-Anfänger, von denen wir hier sprechen, im Alltag in Berührung kommen. Das heißt, da schaltet man tendenziell eher noch mehr in den Modus, sich nicht darauf einlassen zu wollen. Ich denke nicht, dass es abseits einer tatsächlichen Vollautomatisierung möglich ist, Dinge einfacher zugänglich zu machen, als durch Copy & Paste auf Basis einer sehr guten Anleitung.

Zitat von BrokenHeart

Und es wurde nicht unerheblich viel Zeit aufgewendet, um herauszubekommen, ob Skripte bei dem entsprechenden User allgemein nicht laufen oder etwas an einem bestimmten Skript hakt. Wenn es ein funktionierendes PS-Skript dafür gibt, wäre das sicher ein Fortschritt.

Dieses Script ersetzt die Ersteinrichtung. Da kann bei dieser Methode genauso einiges schief gehen, weil es eben nicht vollautomatisiert alles erkennt und Fehler verhindert, sondern von der korrekten Konfiguration und Verwendung durch den Anwender abhängig ist.

---

Letzteres ist für mich der entscheidende Punkt: Eine ausführbare Datei (und kein Shell-Script), welche Firefox-Installationen und Profile auch ohne Konfiguration erkennt und Fehlerquellen ausschließt, ist natürlich sehr viel schwieriger umzusetzen, wäre aber notwendig, um tatsächlich die Vorteile zu liefern, die man sich offensichtlich verspricht.

Die Frage nach dem Anwendungsfall ist für mich damit aber beantwortet, Danke dafür. Ich habe nun ein Bild von den Erwartungen, auch wenn meine Erwartungen davon abweichend sind.

Zitat von Sören Hentzschel

Und dann besitzt das Script auch noch Variablen, die ggf. anzupassen sind, und der Anwender muss herausfinden, was die korrekten Werte sind.

Habe ich da was übersehen, welche wären das? Es geht ja am Anfang nur um eine Standardinstallation, wie sie wohl bei den allermeisten (Windows)-Usern(>95%?) in Verwendung ist. Sollte diese abweichen, sollte das Skript mit Hinweis stoppen. Alle variablen Werte sollten doch per Skript auslesbar sein, oder? Wie gesagt, ich kenne mich mit dem PS-Scripting nicht aus, aber das ist doch sicherlich machbar....

Zitat von Sören Hentzschel

Letzteres ist für mich der entscheidende Punkt: Eine ausführbare Datei (und kein Shell-Script), welche Firefox-Installationen und Profile auch ohne Konfiguration erkennt und Fehlerquellen ausschließt, ist natürlich sehr viel schwieriger umzusetzen, wäre aber notwendig, um tatsächlich die Vorteile zu liefern, die man sich offensichtlich verspricht.

Da gebe ich dir recht. Aber ich habe auch in dem CSS-Thread erklärt, warum das in der Praxis kaum machbar ist. Es geht dabei um Transparenz! Einen Script-Code kann veröffentlicht jeder lesen und dann ausführen. Irgendein 'Schmu' würde sicher sofort auffliegen. Bei einer ausführbaren Datei ist es fast unmöglich einen Vertrauensbeweis zu liefern. Quellen mitliefern bringt nichts, da sie ja nicht mit der angebotenen .exe Datei übereinstimmen müssen und Virenscanner nutzen da auch nichts. Und die Vorstellung, Leute mit make- oder Projektdateien zu nötigen, sich erst einmal das eigentliche Programm zu bauen, ist natürlich abstrus.

Ehrlich gesagt würde ich von keinem User hier im Forum eine angebotene ausführbare Datei starten. Mit vielleicht einer Ausnahme und das wärst du. Nicht weil ich dich prinzipiell für vertrauenswürdiger halte, aber du bist meines Wissens der einzige hier im Forum, der mit seinem richtigen Namen (und seiner Anschrift) auftritt. Dich könnte ich dann einfacher verklagen...

Noch eine Frage an Sören Hentzschel und 2002Andreas :

Wäre der Thread nicht besser in 'Individuelle Anpassungen' aufgehoben? Der Bezug zum Firefox ist ja mehr als eindeutig und interessieren würden sich für den Thread wahrscheinlich auch nur User mit individuellem Anpassungsbedarf.

Powershell ist nur mit Krampf dazu zu bewegen, was ihr wünscht. Und man muss es wirklich können, nicht GPT und Trial&Error - das muss sitzen. Ist leider eine Kröte, die manch einer schlucken muss.

Als Basis: https://nsis.sourceforge.io/
Und das ZIP (siehe Anhang, all inc.)

Eine profiles.ini abzuarbeiten ist nicht schwer. Die Optionen, die sich jedoch dahinter verbergen - reichlich. Wenn ich hier 3000 Zeilen benötige inklusive UI, ist das mit Powershell nahezu unmöglich nachzubauen.

Das Problem, was ich hier im PS-Script sehe: kein Konzept. Tipp: Kodiert nicht aufs Geratewohl drauf zu.
Papier ist geduldig, und nicht nur Netzwerke werden auf dem Papier zu 95% erstellt.

Powershell kann viel, ist u.a. auch für Linux verfügbar. Nur dieses Powershell ist anders als das Powershell, was Windows ab Installation integriert hat. 7.5.x ist weitaus mächtiger, und viele Befehle sind komplett anders. Wenn ich also eure Scripte in PS 7.5 einfüge, dürfte ich mit hoher Wahrscheinlichkeit Fehlermeldungen bekommen. Das ist schon dasselbe Problem mit Webseiten, die für bestimmte Aktionen "Powershell" schreiben, aber nicht, welche Version.

Zu Nullsoft. Das ist eine höhere Script-Sprache speziell für Installationen. Das angehängte Script ist für alle 2.x und 3.x nutzbar. Was mit PS mehrere Zeilen benötigt, ist hier ein Klacks - wenn man es denn kennt.

Next Level wäre, eine Firefox-Installation aus der Registry auszulesen, ggf auch noch Forks - oder nach dem Zielverzeichnis zu fragen, falls nicht gefunden. Und ob eine Instanz grad läuft.

Eine INI abzufragen sind zwei Zeilen. Daraus aber was Brauchbares abzuleiten, Fehler zu erkennen und abzufangen, ist genau die Kunst, die man lernen und wissen muss.

Wird überarbeitet.

Deswegen liegt das NSI vorm Compilieren bei, und die EXE als Ergebnis. Quelloffener gehts nicht.
Am Ergebnis kann ich nicht viel machen, weil der Compiler seine - die offiziellen - Bibliotheken nutzt.

Auch wenn der NSIS-Compiler später auch nur Zeile für Zeile abarbeitet, ist es dennoch schneller, als wenn ich ein PS2EXE nutze. Da ich sowas nicht nutze, könnte ich mir nur vorstellen, dass eine PS2EXE auch nur das Script entpackt und startet. So groß ist der Unterschied dabei nun nicht. Nur wurde NSIS genau für solche Fälle geschrieben und hat erhebliche Vorteile: es kann ebenso viel, ist aber leichter zu lernen und kann Bibliotheken (DLL) einbinden für bestimmte Aktionen. Und bietet ein nutzer-freundliches UI an.

Ich hab kein Problem zu sagen, dass ich mit PS Null Verbindung habe. Nur gibt es Lösungen, die für solche Zwecke schlichtweg einfacher sind, und einfacher zu lernen sind - vor allem unter Windows, weil es das für Linux (aktuell) nicht gibt.

Doch, kannst du. Kann dir nur empfehlen, in die NSIS.chm reinzuschauen, welche Anweisungen was bewirken.

Was du suchst:

File /r ".\firefox-anpassungen\*.*"

Und darin befindet sich der Inhalt von Endor von vor wenigen Stunden. Schau ins ZIP.

Was du hier an Powershell leistest, entzieht sich meinem Wissen und damit jeglicher Wertung.

Was das Papier angeht -> Flowchart. Powershell kann Funktionen, damit kann man Spaghetti-Code abwenden. call(xy) -> return-code, einfach ausgedrückt. Damit lässt sich PS in einem gewissen Maß strukturieren. Nichts anderes mach ich mit Nullsoft, oder anderem.

Was will ich? Was kommt zuerst? Wo will ich hin? Kann ich das vereinfachen?
Das liesse sich nicht nur auf Papier festhalten, sondern auch im Code, Version 0.1, 0.2, usw. Es gibt einen Header - als Einleitung. Und dann einen Ablaufplan, mit oder ohne Funktionen. Nichts anderes ist das Script, was du oben zitiert hast. Ein Header/Kopf für den Compiler, dann ein Ablauf an Befehlen. instfiles ruft "Section "" auf. Dann ist alles schon vorbei.

Wobei ich auch nur deine Ansätze zum Zielordner in seiner einfachen Form aufgegriffen habe. Wie geschrieben kann man das ziemlich erweitern.

Um den Gedanken von Sören aufzugreifen. Powershell mit den (aus diesem Thema) bekannten Befehlen ist so nur für Windows gültig. Und dann muss man bedenken, wie viele Nutzer die auch Endor auf github kennen und damit Userscripte nutzen. Das dürfte ausserhalb dieses Forums verschwindend gering sein. Und daher muss man sich wirklich überlegen, ob man eine proprietäre Lösung (nur für Windows) präsentiert, oder ob Download und Extraktion nicht die wirklich einfachere Option erscheint. Und gerade für Linux muss man wirklich anders denken, weil zB SNAP keinen Zugriff auf den Firefox-Ordner zulässt. Hatte ich schon beim Relaunch zu MozBackup geäussert.

Alles, was ich mir rund um mein Biotop an Rechner ausdenke und so umsetze, bleibt seit vielen Jahren auch hier. Der Aufwand, einen Programmiercode auf wirklich viele oder gar alle Eventualitäten zu verwirklichen, sprengt jegliche Freizeit, wenn es nicht als Vollzeit eingeplant wurde. Und falls Vollzeit, muss man auch bereit sein, mehr als nur das zu investieren. Ich bin kein Rentner, ich gehe noch richtig knechten. Deswegen ist auch mein Aufwand für obiges sehr begrenzt, auch wenn ich Vorlagen habe, die das ZIP von Endor direkt herunterladen und nutzen könnten. Bei sowas springen aber auch meistens Antivirus-Programme an, und damit hat man dann wieder nichts gewonnen, sondern nur verloren. Und das gilt auch für PS2EXE. So ein Aufwand ist möglich und machbar, der Nutzen könnte sich in Grenzen halten. Und das hat Sören auch bereits mitgeteilt.

Es gibt so wahnsinnig viel Aspekte, die für einen selbst total untergeordnet sind, aber eben nicht bei anderen in anderen Biotopen.

Dafür braucht es keine VM. Nicht mal eine Sandbox wie zB Sandboxie. Da es Firefox auch als ZIP gibt, und nicht mal das ist von Nöten, wenn ich deine bisherige Ausführung überdenke - eine einfache Null-Byte-Datei firefox.exe sollte reichen.

Sollte es dann aber um Profile gehen, sind Backups eh sinnvoll, und/oder ein Testprofil.

Dein Script dürfte jedoch vermutlich interessanter sein. Solltest du vorhaben, es selektiv über private Nachrichten zu verteilen, bin ich eh raus. Was soll den großartig passieren?

Zitat von BrokenHeart

Noch etwas: Wir hatten schon oft den Fall, dass die Vorbereitungen für die User-Skripte nicht richtig durchgeführt wurden. Woran das jetzt lag ist unerheblich. Und es wurde teilweise viel Zeit aufgewendet, um herauszubekommen, ob Skripte bei dem entsprechenden User allgemein nicht laufen oder etwas an einem bestimmten Skript hakt. Wenn es ein funktionierendes PS-Skript dafür gibt, wäre das sicher ein Fortschritt. Außerdem lässt sich das Skript dazu nutzen, sowohl 'userChrome.css', 'userContent.css' und die Shadow-Geschichte bereits zu integrieren. Außerdem kann man das Skript später einmal so erweitern, dass bestimmte Sachen "standardisiert" werden, wie z.B. ein einheitliches Verzeichnis für Image/Icon-Dateien.

Wall of text, Sent from my iPhone?

Was ich hier sehe, ist eine Komprimierung von potentiellen Fehlerquellen in ein Konstrukt mit hohem Aufwand für Troubleshooting.

Wenn man jetzt noch bedenkt, daß dieses Konzept einen weiten Bereich von konstant weiterentwickeltem Firefox Code einschliesst, systemübergreifend funktionieren müsste, und jemand die Geschichte permanent warten und anpassen müsste...

Viele weniger engagierte User haben generell schon Schwierigkeiten damit eine Problembeschreibung sinnvoll zu formulieren, und schleppen oft redundanten und/oder alten Code mit; wo setzt man an wenn sich die Quelle nicht mal eingrenzen lässt?
Wir reden hier ja über die Manipulation von einem global integriertem Internet Browser.

Ich bin da eher mit Sören Hentzschel ; Aufwand gering halten, um möglichst vielen Usern den Zugang zu ermöglichen; aber auch ein Minimum an Initiative voraussetzen.

Das kann m.E. Komplexität drastisch reduzieren, für User die Code erstellen oder Probleme zu lösen versuchen, und für User die nach Problemlösungen suchen.
Meine eigenen bescheidenen Bemühungen sind oft dominiert von möglichst einfacher Bedienbarkeit, deshalb unnötig kompliziert für andere User - und anfälliger für Fehler und Code Updates.

Es gibt ja auch eine Unzahl von Erweiterungen und Themes via Mozilla, niemand ist gezwungen für Fx Modifikationen diesen letzten Schritt zu gehen.

Eine low-tech Alternative wäre evtl. ein erweitertes, standardisiertes ReadMe , wie zB du und 2002Andreas es schon in den gepinnten Threads anbieten.

Ganz ehrlich: ich verstehe nicht, warum man die ganze Sache so furchtbar dramatisieren muss und warum alles schon wieder "zerredet" wird, bevor überhaupt eine Zeile Code existiert? Es handelt sich (für den Anfang) nur um ein simples Skript um Dateien herunterzuladen und in die richtigen Verzeichnisse zu kopieren. Was man später daraus macht bzw. machen kann, wird sich zeigen.

Zitat von Horstmann

Wenn man jetzt noch bedenkt, daß dieses Konzept einen weiten Bereich von konstant weiterentwickeltem Firefox Code einschliesst, systemübergreifend funktionieren müsste, und jemand die Geschichte permanent warten und anpassen müsste...

Wie oft wurde denn das ReadMe inhaltlich angepasst? Ja, es mussten Dateien angepasst werden, die in der Zip-Datei bei Endor liegen, sonst nichts (der Hinweis für FF139 betrifft nur paar wenige User-Skripte und hat nichts mit den Installationsdateien zu tun). Genauso würde es mit einem Skript laufen. Ich behaupte mal, dass fast jedes User-Skript viel stärker in den Firefox-Code eingreift, als so ein simples PS-Skript es auf Dateiebene je könnte. Und mit einem nicht mehr funktionierenden User-Skript haben wir nach fast jedem Update zu tun.

Warum nicht auch mal was ausprobieren und neue Wege gehen? Bedenken sind ja gut und sie zu äußern natürlich legitim, aber in diesem Fall ist könnte man ja auch abwarten, bis überhaupt etwas Greifbares vorliegt. Nur von der Idee auf das fertige Skript und seine Vor- und Nachteile zu schließen, halte ich für verfrüht. Es wird doch kein Mensch genötigt, dass zu testen oder gar zu benutzen!? Spricht auch kein Mensch davon, das "ReadMe" zu entfernen. Alles bleibt so wie es ist, keinem wird was weggenommen, alles optional, keiner muss Angst haben...

Wenn allgemein die Meinung vorherrscht, dass so ein Skript nicht in dieses Forum gehört, dann soll Sören Hentzschel das sagen und wir begraben das oder machen mit einer "Koalition der Willigen" auf einem anderen Weg weiter.