hxtools verpfuscht die Umgebungsvariable PATH

[hus]

Nach langem Suchen wieso gewisse Programme nicht mehr gefunden werden habe ich festgestellt, dass das Script "/etc/hxtools_profile.sh" bzw. der Link darauf "/etc/profile.d/Z_hxtools_profile.sh" die PATH-Umgebungsvariable, unbekümmert dessen was andere Scripts bereits in die Umgebungsvariable geschrieben haben, neu erstellt. Da dieses Script ganz am Ende ausgeführt wird werden die PATH-Einträge der anderen Scripts wie z.B. "$HOME/bin", "/opt/cdk4avr/bin", das JAVA-bin Verzeichnis etc einfach entfernt.
Es würde mich an dieser Stelle interessieren, was sich Herr Engelhard bei diesem Vorgehen gedacht hat. Auch wüsste ich gerne, durch welche Abhängigkeit hxtools überhaupt auf den Rechner kam.

Nun meine provisorische Lösung ist, dass ich das Script "/etc/hxtools_profile.sh" so abgeändert habe, dass lediglich der Pfad "/opt/hxtools/bin" an den bestehenden Pfad angefügt wird. Ob dies so sauber ist kann mir sicher ein Profi sagen. Beim nächsten Update wird aber dann wahrscheinlich wieder alles zunichte gemacht und ich muss wieder Hand anlegen.
Ich bin daher der Meinung, dass entweder SUSE oder Herr Engelhard etwas an ihrer Konfiguration ändern sollten.

Zu meinem System: OpenSUSE 10.3 mit Kernel von Herrn Engelhard

 

[jengelh]

Der Herr Engelhardt, den man übrigens mit t am Ende schreibt, hat sich dabei gedacht, all die sinnlosen Verzeichnisse rauszuwerfen -- darunter games, lib/mit und lib/qt3, wie man auf einem unberührtem 11.0 sehen kann:

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin

(und weitere wie /usr/lib/java-1_6_0-sun... zumindest war das mal der Fall.)
Denn die meisten Programme, die sich in diesen Verzeichnissen befinden, wird man selten gebrauchen, und solche, die man tatsächlich doch gebraucht, gibt es in /usr/bin. qt3's qmake, javac, you name it.

Manche Entwickler, besonders mit SysV-Ursprung, werdem dem Poster gar sagen, dass Verzeichnisse in /opt generell nichts im Standard-$PATH zu suchen haben, sondern nur explizit auf Verlangen des Benutzers in dessen ~/.profile o.ä. eingefügt werden müssen. Schließlich sind es ja, nach FHS, optionale Pakete.

Wie diese Software nun auf des Posters System gelang, wird nur der Poster selber sagen können, denn von alleine installiert sich so etwas nicht.

 

[abgdf]

Vielleicht könnte das Skript vor dem Aufräumen irgendwo ein Backup des Inhalts der Variable speichern ...

Mit "rpm -qf Datei" findet man heraus, zu welchem Paket eine Datei gehört.

Gruß

 

[hus]

Herr Engehardt möge mir den Schreibfehler entschuldigen. Auf seiner Homepage habe ich oben nur so etwas kryptisches "[ˈɛŋəlhard]" gefunden und mir dann meinen Reim daraus gemacht.

Ich bin auch nicht glücklich über das Durcheinander in der Path-Variable und kenne die Grundphilosophie von Linux zu wenig. Wenn man selbst aber die eigenen Tools in /opt/ installiert und den Pfad darauf in die PATH-Variable aufnimmt sollte man nicht über andere schimpfen die das Selbe tun und schon gar nicht die Arbeit anderer kaputt machen.
Herr Engelhardt schreibt auch, dass in der PATH-Variable Verzeichnisse stehen die man selten braucht. Und was ist wenn man sie braucht? Kann Herr Engelhardt wissen was ich auf meiner Installation verwende und benötige? Schlimm ist vor allem. dass dies ungefragt im Hintergrund ohne genaue Beschreibung installiert wird.

Wie kam den nun dieses Problemtool überhaupt auf meinen Rechner. (Den Zweck von hxtools ist mir immer noch nicht klar, da ich keine richtige Dokumentation dazu finden konnte)
Da ich noch einen alten Server in Betrieb habe benötige ich noch das smbfs, welches Herr Engelhardt verdankenswerterweise wieder in seinen Kernel aufgenommen hat. Beim ersten Wechsel auf seinen Kernel lief noch alles problemlos. Erst als ich später ein Update auf eine neuere Version (2.6.25.7-jen67) machte und gleichzeitig andere Pakte aus diesem Repository aktualisierte floss hxtools automatisch ein.

Nun, das Problem habe ich vorerst für meine Zwecke gelöst, Aber wohl ist mir dabei nicht und vor einem weiteren Update werde ich vorerst die Finger lassen. Ich muss mit meinem System arbeiten können und zwar auf meine Weise und nicht wie mir dies andere vorgeben möchten. (Sonst hätte ich bei Windows bleiben können )

Aber trotzdem möchte ich an dieser Stelle Herrn Engelhardt für seinen Kernel danken. Er hat mir damit auch viel Arbeit erspart.

Einen schönen Gruss