Installations Skript zur Vorbereitung des FF zur Nutzung von JavaScript. [ps1 verfügbar]

  • 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?

    War doch nur ein Gedanke zum Thema, es steht ja auch in der Rubrik Smalltalk; ich dachte das suggeriert einen Diskussionswunsch. :/

    Hier kann doch jeder coden was er will, also nur zu! :thumbup:

  • Horstmann Das Skript wird definitiv nur für Windows sein!
    Es soll recht einfach sein, d.h. es soll, es muss nichts am Skript geändert werden.
    Einfach anklicken, warten, fertig.
    Danach sollen JS-Dateien einfach genutzt werden können.


    ich dachte das suggeriert einen Diskussionswunsch. :/

    Jain. Codebeispiele, oder auch Anmerkungen zum "Ablaufplan", gerne.

    Mit <3lichem Gruß

    Mira

  • Irgendwer hat deine letzte Anfrage hier reingeschoben, oder das andere gelöscht.

    Ob nun dein Script, oder von jemand anders optimiert, verknüpft etc, ist mir egal. Zwei Ansätze sind ja zu sehen.

    Und dass nicht jeder so eine Lösung braucht, sollte auch im Vorfeld bewusst gewesen zu sein.

    Was mich persönlich nervt, dass du das Handtuch wirfst noch bevor es ausgelegt wurde. Du weisst doch gar nicht, auf welchen fruchtbaren Boden es gefallen wäre. Wenn ich so denken täte, wären die drei Scripte mit ~50 Zeilen bei mir nie entstanden. Es hat mich weder noch gestört, da eine Stunde zu investieren. Wo ich drüber nachgedacht habe, war der Nachmittag heute, wo allein die Suche nach Firefox in der Windows-Registry weitere 400 Zeilen Code mitsamt Fehlersuche benötigt haben. Und genau das wäre der einzige Punkt, den man auch hier anbringen könnte - extrem viel Zeitbedarf für genau einen Zweck, den nur ganz wenige benötigen. Und da ist immer noch nicht die Bearbeitung der profiles.ini drin, das sind auch noch mal 400 +/- Zeilen. Was mich betrifft, für mich sind das letztlich Vorlagen, die ich wiederverwerten kann, muss nicht mal Firefox sein. Und auch der Code hier wurde so ähnlich schon mal geschrieben.

    So und ähnlich sollte man es selbst für Powershell haben. Eine eigene Sammlung an Scripten und Schnipseln für bestimmte Zwecke. Und auch Powershell muss kein Spaghetti-Code sein, es kann auch Funktionen (Unterroutinen).

    In kurz: schade.

    Versuch(t) das mal unter Linux, das hat schon wieder ganz andere Hürden, die meistens bei root enden, oder so für Laien gar nicht umsetzbar sind. Deswegen ist auch Manjaro (ein Arch Linux) heute wieder aus der VM geflogen. Für Linux gibt es hier keinen Almanach, viele sind ähnlich, andere gar nicht. Und bei "gar nicht" höre ich auf zu suchen oder nachzudenken.

    Was mich vielleicht interessieren täte, wäre sowas:

    GitHub - grandchild/linux_installer: Graphical Linux application installer for audiences that are used to Windows installers. Imitates the look-and-feel of NSIS/Wizard97.
    Graphical Linux application installer for audiences that are used to Windows installers. Imitates the look-and-feel of NSIS/Wizard97. -…
    github.com
    GitHub - QuasarApp/CQtDeployer: This project is used to deploy applications written using QML, qt or other С / С++ frameworks.
    This project is used to deploy applications written using QML, qt or other С / С++ frameworks. - QuasarApp/CQtDeployer
    github.com

    Noch gelesen: cmake, autotools. Powershell? Fehlanzeige. Das kommt noch dazu.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 95.

  • ...ach ja, ok, das Video hat es mir gezeigt. Damit wäre das Ergebnis von gestern für die Tonne, benötigt Überarbeitung. Tschuldigung an Mitleser/Tester.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 95.

  • Beitrag von Horstmann (29. April 2025 um 00:13)

    Dieser Beitrag wurde vom Autor gelöscht (29. April 2025 um 01:03).
  • .DeJaVu Magst Du mir auf die Sprünge helfen?

    Die "profiles.ini" auf Default=1 abzufragen, ergibt keinen Sinn.
    Hat der Nutzer keine andere Firefoxversion installiert, gibt es diesen einfach nicht.

    Hat der User z.B. zwei Profile, kann die "profiles.ini" so aussehen:

    Auch hier habe ich das Problem, dass ich nicht weiß, wie ich an das Standardprofil, in diesem Fall "Mira", heran komme.

    Um eine Abfrage, ob es sich um eine "normale" Installation handelt,
    also ohne parallel laufenden Versionen,
    könnte ja auch die "install.ini" abfragen

    Code
    [6F193CCC56814779]
    Default=Profiles/790r9b33.Nightly
    Locked=1
     
    [308046B0AF4A39CB]
    Default=Profiles/Mira
    Locked=1

    und wenn mehr als ein [xxxxxx] vorkommt einfach das Skript mit Meldung stoppen.

    (x seht als Platzhalter)

    Mit <3lichem Gruß

    Mira

  • Das Standardprofil wird eben mit Default=1 markiert. Zudem ist bei dir die Abfrage nach einem Profil aktiviert StartWithLastProfile=0

    Und auch der CityHash* 308046B0AF4A39CB zeigt auf das Profil Testumgebung.
    308046B0AF4A39CB ist der CityHash für %PROGRAMFILES%\Mozilla Firefox

    Für andere Installation wird das hier hinterlegt
    user_pref("app.update.migrated.updateDir3.5F63E1798743DB5F", true);
    In meinem Fall 5F63E1798743DB5F

    Wenn es wie bei dir kein Standardprofil gibt, dann brauchst du ein Auswahlmenü.

    Ob du noch IsRelative verarbeiten möchtest... Denn mit 0 steht im Path ein absoluter Pfad, das kann sonst wo sein.

    *Cityhash ergibt erst dann Sinn, wenn du die Pfade zu Firefox kennst, denn nur dann kann man die Profile einem bestimmten Firefox zuordnen. Ist Firefox regulär installiert, könnte man das auch direkt auslesen. Für nicht installierte muss man es suchen. Der CityHash ist ebenso in der Registry als auch unter %ProgramData%\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates zu finden. Ursache sind die dedizierten Profile. Ist eine Entwicklung von Google (evtl mit Mozilla zusammen), die Mozilla für sich umgesetzt hat. Der portable Firefox von p-apps nutzt das, um seine Spuren zu verwischen, wobei das maximal Makulatur ist, weil das nachträglich passieren muss, nicht vorher, nur Startet der Starter eben vorher, und nicht nachher. Für den Seitenhieb - die Portable schützt ganz und gar nicht die Privatspähre oder vor Einträgen in Windows.

    Im Beispiel für die Standardinstallation, und die installierte ESR hier.

    Das ist genau das, was ich vorher zu dir meinte. Entweder reduziert man sich ganz konkret auf die Standardinstallation und das [Profile0], was ja dein Nutzerprofil wäre. Und gibt Anweisungen mit, wie man Firefox-Pfad und Profilnummer ändert.

    Jetzt hat die INI bei dir schon wieder eine Besonderheit - du hast die bearbeitet. Bei mir ist [Profile1] das "kleine" Profil mit der times.json/parent.lock drin. Deswegen prüfe ich weiter, ob bereits eine prefs.js vorhanden ist, die aufzeigt, dass das Profil schon mal benutzt wurde. (mindestens ein Backup ist). Ließe sich auf beliebige Dateien erweitern.

    Kleinigkeiten blähen das Konstrukt einfach nur erheblich auf. Was hier vorher 50 Zeilen hatte, hatte mit der Firefox-Erkennung schon 450, hat mit den Profilen 650 Zeilen, inklusive einer grafischen Oberfläche (UI) mit Auswahl - und das ist noch nicht fertig.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 95.

    Einmal editiert, zuletzt von .DeJaVu (29. April 2025 um 15:32)

  • Es ist vollbracht!

    Das Skript führt die auf Endors Seite beschriebenen Schritte von alleine durch.

    Das Zip wird heruntergeladen und entpackt.
    Und die entsprechenden Ordner angelegt und die Dateien abgelegt.

    Was mir fehlt, ein guter Name für das Skript:!:
    Ich habe es kurzerhand einfach "Firefox-JavaScript_install.ps1" genannt.
    Danke  .DeJaVu

    Mit <3lichem Gruß

    Mira

    2 Mal editiert, zuletzt von Mira_Belle (29. April 2025 um 20:50)

  • Mira_Belle 29. April 2025 um 20:21

    Hat den Titel des Themas von „Projekt: Installations Skript zur Vorbereitung des FF zur Nutzung von JavaScript. [erledigt]“ zu „Installations Skript zur Vorbereitung des FF zur Nutzung von JavaScript. [ps1 verfügbar]“ geändert.
  • Sieht gut aus, gute Arbeit. Ich hab das grad in VScodium offen.
    Ich hätte mehr auf edv.kleini getippt, aber TK87 auch schon gelesen.

    Was ich umbauen würde sind die Abfragen ab Zeile 76, da beginnt das eigentliche Programm.

    Punkt (2) sollte vor allem anderen stehen. Irgendwas zu ermitteln, um später festzustellen, dass es gar nicht anwendbar wäre?

    Punkt (3) sollte an zweiter Position stehen.

    Und an Punkt (1) sollte eine Abfrage nach HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\Launcher
    Da werden alle Starts hinterlegt, das schreibt Firefox selbst. Wichtig sind auch nur die REG_SZ und das sind die Keys mit |Blocklist

    Und dann erst Punkt (4). Uninstall. Und dort könnte man dann auch schon die Pfade auslesen mit InstallLocation, wenn man schon nach DisplayName sucht. Kann man sich auch komplett schenken, weil jede Installation auch eine TaskBarIDs beschreibt - und das wird schon in Punkt (3) ausgelesen.

    Das Auslesen der installs.ini finde ich klasse, weil damit nur die wirklich aktiven Profile ausgelesen werden können. Damit schenkt man sich den Krampf mit der profiles.ini.

    Firefox bemerkt übrigens unter Umständen, wenn diese beiden Dateien schreibgeschützt sind.

    Nachtrag:,

    Windows 10 Pro, aktueller Patch-Level.
    Das Script will bei mir nicht. Weder mit PS noch mit PS7 (7.5.1).

    Unter (integriertem) PS stört es sich beide Male (Z78/Z96) an Wow6432Node, das gibt es bei mir nicht, da steht auch nichts von Firefox. Ich hatte erst gedacht, dass es an Sandboxie läge, aber das passiert auch ausserhalb. Und PS7 sagt mir, dass Firefox nicht installiert wäre.

    Lasse ich das weg, meckert es weiter

    Code
    Ausnahme beim Aufrufen von "ExtractAssociatedIcon" mit 1 Argument(en):  "E:\Firefox.exe"

    Da fehlt der restliche Teil vom Pfad, da ist kein Firefox -> ${0}.
    PS7 kommt wegen obiger Meldung erst gar nicht so weit.

    Gibt es ein E:\Firefox.exe, bekomme ich folgendes Bild

    Bezeichnung ist richtig, Icon auch (ist die Nightly-EXE). Aber warum doppelt? Ich denke, das kommt durch die entsprechenden Abfragen, die dann nur hinzugefügt werden, da findet keine weitere Kontrolle auf die Pfade statt. Und dann sichtbarer Umlautfehler, das liegt daran, dass das Script ANSI haben will als Kodierung, nicht UTF-8. Ich habe das Script lediglich kopiert und in ein leeres NPP-Dokument eingefügt, und die sind Vorgabe alle in UTF-8. ANSI ändert aber auch nichts an den bereits geschilderten Fehlern.

    Markiere ich die erste Option, nächster Fehler hier:

    Code
    Firefox-Anpassungen werden heruntergeladen... ok.
    Archiv wird entpackt... ok.
    
    Beginne Kopiervorgang für: Mozilla Firefox ESR (x64 de)
    Datei 'config-prefs.js' wird ins Firefox-Verzeichnis kopiert... Ein Teil des Pfades "E:\defaults\pref" konnte nicht gefunden werden.

    "Ein Teil von..." kommt von PS. Kann auch nichts finden, weil das ZIP hier nicht gibt entgegen der Meldung. Das lief auch zu schnell durch hier. Eine Suche unter \Users\, \Windows\ und auch E: hatte keine Ergebnisse für das ZIP, oder Dateien daraus.

    Keine Ahnung, woran es klemmt, weil keine Ahnung von PS. Ich kann zwar maximal halbwegs Befehle erkennen und wegen der Dokumentation einordnen, mehr auch nicht. Ich werde das Script gleich nochmal unter Windows 11 testen.

    Ach ja, manchmal reicht eine Taste, dann wieder nur Escape.

    Weiter - Windows 11 Pro. PS7 (7.5.1) kommt bis zur Extraktion, dann Ende. PS von Windows 11 macht irgendwas, und beendet sich ganz schnell wieder. Nix mit Taste drücken. Firefox 138 ist im Standard-Verzeichnis, Profil gibt es, Admin-Rechte, leider kein Erfolg. Und wieder alles mit E:, obwohl Firefox auf C: liegt. Das Script liegt auf E:

    Das ist ernüchternd, wenn gleich zwei meiner Systeme streiken. Vielleicht hat da noch jemand eine Idee.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 95.

    3 Mal editiert, zuletzt von .DeJaVu (29. April 2025 um 23:51)

  • Moin,

    Punkt (2) sollte vor allem anderen stehen. Irgendwas zu ermitteln, um später festzustellen, dass es gar nicht anwendbar wäre?

    nunja, imho wird umgekehrt eher ein Schuh draus. Den Benutzer erst dazu auffordern, Administratorrechte zu bestätigen, um dann festzustellen, dass Firefox gar nicht installiert ist?

    Zitat

    Und dann erst Punkt (4). Uninstall. Und dort könnte man dann auch schon die Pfade auslesen mit InstallLocation, wenn man schon nach DisplayName sucht. Kann man sich auch komplett schenken, weil jede Installation auch eine TaskBarIDs beschreibt - und das wird schon in Punkt (3) ausgelesen.

    Löscht denn eine Deinstallation von Firefox automatisch die TaskBarID aus der Registry? Andernfalls könnte es ja verwaiste Einträge geben.

    Zitat

    Unter (integriertem) PS stört es sich beide Male (Z78/Z96) an Wow6432Node, das gibt es bei mir nicht, da steht auch nichts von Firefox.

    Unter Wow6432Node werden die 32bit-Programme gespeichert. Denn Pfad HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall aus Zeile 78 sollte es eigentlich in jedem Fall geben - der Mozilla-Ordner aus Zeile 96 kann natürlich tatsächlich nicht existent sein, falls keine 32bit-Version installiert ist.

    Man könnte natürlich in beiden Zeilen hinter Get-ItemProperty -EA SilentlyContinue ergänzen, um das zu ignorieren. Damit erpasrt man sich, erst mit Test-Path überprüfen zu müssen, ob der Ordner existiert.


    Lasse ich das weg, meckert es weiter

    Code
    Ausnahme beim Aufrufen von "ExtractAssociatedIcon" mit 1 Argument(en):  "E:\Firefox.exe"

    Da fehlt der restliche Teil vom Pfad, da ist kein Firefox -> ${0}.

    {0} wird durch die InstallLocation-Eigenschaft aus den Registry-Einträgen ersetzt. Aus irgendeinem Grund scheint diese hier zu fehlen, oder nur auf E:\ zu zeigen.

    Zitat

    Bezeichnung ist richtig, Icon auch (ist die Nightly-EXE). Aber warum doppelt?

    Bei mir ist das nicht doppelt. Es wird für jeden Registry-Eintrag unterhalb des Uninstall-Ordners jeweils ein Eintrag hinzugefügt.

    Wie genau hast du das WOW6432Node oben weggelassen? Komplett entfernt, oder einfach nur die Zeichenkette geleert? Bei letzterem würde er die Einträge im 64bit Pfad natürlich 2mal abrufen. In dem Fall einfach mal wie oben erwähnt so abändern.

    Code
      $FFs = '','Wow6432Node\'|%{gp -EA SilentlyContinue "HKLM:\Software\${_}Microsoft\Windows\CurrentVersion\Uninstall\*"} |?{$_.Publisher -eq 'Mozilla' -and $_.DisplayName -match 'Firefox|Nightly'}

    Falls das Problem nach wie vor besteht, könnte es auch an verwaisten Registryeinträgen aus früheren Installationen liegen.

    Wie sieht bei dir die Ausgabe von folgendem Befehl aus?

    Code
    gp HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*|? {$_.Publisher -eq 'Mozilla' -and $_.DisplayName -match 'Firefox|Nightly'} | Select DisplayName,InstallLocation

    Gruß Thomas

  • Jup, Gedankenfehler, hatte InstallLocation nicht drin. Wobei es mich gewundert hat, dass es in der Sandbox anfänglich auch nicht funktioniert hat, obwohl dort eine Installation vorhanden war, dito unter Windows, aber so in echt.

    Wegen "weglassen" - ganz einfach so:

    $FFs = '',''|%{gp "HKLM:\Software\${_}Microsoft\Windows\CurrentVersion\Uninstall\*"} |?{$_.Publisher -eq 'Mozilla' -and $_.DisplayName -match 'Firefox|Nightly'}

    Da ich die Registry kenne und auch weiss, was Wow6432Node bedeutet als Subsystem, wird ${_} nicht mehr gefüllt.

    Aber ich bekomme immer noch eine doppelte Anzeige. Kannst du selbst testen, auch ohne Firefox installiert zu haben, es reicht eine firefox.exe mit Symbol, und wenn du notepad umbenennst.

    Code
    [308046B0AF4A39CB]
    Default=Profiles/tb9jnkkc.default-release
    Locked=1
    
    [5F63E1798743DB5F]
    Default=Profiles/4ik7am01.default-esr
    Locked=1

    Und so es sieht mit nem Dummy aus:

    Zur Ausgabe, das ist auch das, was in der Sandbox installiert wurde.

    Code
     gp HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*|? {$_.Publisher -eq 'Mozilla' -and $_.DisplayName -match 'Firefox|Nightly'} | Select DisplayName,InstallLocation
    
    DisplayName                  InstallLocation
    -----------                  ---------------
    Mozilla Firefox ESR (x64 de) C:\Program Files\Mozilla Firefox 115 esr
    Mozilla Firefox (x64 de)     C:\Program Files\Mozilla Firefox

    Also in der Sandbox lädt er wohl das ZIP, kann es aber nicht korrekt entpacken, rote Meldung, dann direkt Fenster zu, da hilft auch kein void als breakpoint. Im Host funktioniert das. Nur am Rande, nicht wirklich wichtig.

    Wegen TaskBarIDs und "nicht vorhanden" nochmal. Wenn es Uninstall gibt, aber nicht Taskbars, ist Firefox noch nie gestartet worden auf dem System, dann kann es auch keine installs.ini geben.
    "nicht vorhanden" dürfte eine PS Meldung sein, nur hilft dem Nutzer das so nicht weiter.

    -EA SilentlyContinue

    -> $FFs = '','Wow6432Node\'|%{gp -EA SilentlyContinue

    Schau mal an:

    So sollte es funktionieren.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 95.