Hallo. Ich wollte gerade eine WM testweise unter /opt installieren. Damit auch das Verzeichnis /opt/<WM>/bin in $PATH auftaucht, wollte ich unter /etc/bash.bashrc die Pfad hinzufügen. Aber weder in der /etc/bash.bashrc noch in der /etc/profile habe ich den Ursprung gefunden. In der /etc/profile stehen zwar die Grund-Pfade (/bin, /usr/bin, etc.). Aber nicht alle. Gerade die unter /opt stehen nicht dort. Bin ich auf der falschen Spur? Wo muss ich suchen, bzw. den zusätzlichen Pfad eintragen? Gruß Marcus
Am Sonntag, 25. April 2004 13:27 schrieb Marcus Habermehl:
Hallo.
Ich wollte gerade eine WM testweise unter /opt installieren. Damit auch das Verzeichnis /opt/<WM>/bin in $PATH auftaucht, wollte ich unter /etc/bash.bashrc die Pfad hinzufügen.
Aber weder in der /etc/bash.bashrc noch in der /etc/profile habe ich den Ursprung gefunden.
In der /etc/profile stehen zwar die Grund-Pfade (/bin, /usr/bin, etc.). Aber nicht alle. Gerade die unter /opt stehen nicht dort.
Also bei meiner SuSE 8.2 sind die genau in /etc/profile drin. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am So, 2004-04-25 um 20.06 schrieb Manfred Tremmel:
Am Sonntag, 25. April 2004 13:27 schrieb Marcus Habermehl:
Hallo.
Ich wollte gerade eine WM testweise unter /opt installieren. Damit auch das Verzeichnis /opt/<WM>/bin in $PATH auftaucht, wollte ich unter /etc/bash.bashrc die Pfad hinzufügen.
Aber weder in der /etc/bash.bashrc noch in der /etc/profile habe ich den Ursprung gefunden.
In der /etc/profile stehen zwar die Grund-Pfade (/bin, /usr/bin, etc.). Aber nicht alle. Gerade die unter /opt stehen nicht dort.
Also bei meiner SuSE 8.2 sind die genau in /etc/profile drin.
Glaub ich dir. Bei meiner 9.0 auch. Ich habe mich blöd ausgedrückt. Bzw. das, worauf es mir ankommt weggelassen. Ich suche die Einträge für die [s]bin Verzeichnisse unter /opt. Wenn die [s]bin Verzeichnisse unter / und /usr in der /etc/profile zusammenfasst werden, wird es ja auch ein Gegenstück zu denen unter /opt geben. Oder? Gruß Marcus
Am Sonntag, 25. April 2004 22:33 schrieb Marcus Habermehl:
Am So, 2004-04-25 um 20.06 schrieb Manfred Tremmel:
Also bei meiner SuSE 8.2 sind die genau in /etc/profile drin.
Glaub ich dir. Bei meiner 9.0 auch.
Ich habe mich blöd ausgedrückt. Bzw. das, worauf es mir ankommt weggelassen.
Ich suche die Einträge für die [s]bin Verzeichnisse unter /opt.
Versteh ich jetzt nicht, folgendes findet sich in /etc/profile meiner 8.2, hab gerade bei 9.0 nachgeschaut, da ist es ähnlich: for dir in /var/lib/dosemu \ /usr/games \ /opt/bin \ /opt/gnome2/bin \ /opt/gnome/bin \ /opt/kde3/bin \ /opt/kde2/bin \ /opt/kde/bin \ /usr/openwin/bin \ /opt/cross/bin do test -d $dir && PATH=$PATH:$dir done
Wenn die [s]bin Verzeichnisse unter / und /usr in der /etc/profile zusammenfasst werden, wird es ja auch ein Gegenstück zu denen unter /opt geben.
Das sind doch die. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am So, 2004-04-25 um 23.13 schrieb Manfred Tremmel:
Am Sonntag, 25. April 2004 22:33 schrieb Marcus Habermehl:
Am So, 2004-04-25 um 20.06 schrieb Manfred Tremmel:
Also bei meiner SuSE 8.2 sind die genau in /etc/profile drin.
Glaub ich dir. Bei meiner 9.0 auch.
Ich habe mich blöd ausgedrückt. Bzw. das, worauf es mir ankommt weggelassen.
Ich suche die Einträge für die [s]bin Verzeichnisse unter /opt.
Versteh ich jetzt nicht, folgendes findet sich in /etc/profile meiner 8.2, hab gerade bei 9.0 nachgeschaut, da ist es ähnlich:
[...] Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-( Da ich mit grep PATH /etc/profile gesucht habe, wurde mir die einzelnen Pfade natürlich nicht angezeigt. Ich bin einfach davon ausgegangen, dass die alle in einer Zeile aufgelistet werden. Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann. Gruß Marcus
Hallo, Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann.
==== portabel ==== cat <<EOF >> /etc/profile.local PATH="\$PATH:/mein/neuer/pfad/bin" export PATH EOF ==== Beachte das '\' bei '\$PATH'! ==== Alternativ ==== cat <<'EOF' >> /etc/profile.local PATH="$PATH:/mein/neuer/pfad/bin" export PATH EOF ==== Beachte die "''" beim 'EOF'. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Am Mo, 2004-04-26 um 21.13 schrieb David Haller:
Hallo,
Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Äh, funktioniert bei mir nicht. Wenn das eine Variante von grep -C 10 PATH /etc/profile sein soll, dann funktioniert beides nicht. Außer ich verstehe den Hilfe-Text falsch.
Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann.
==== portabel ==== cat <<EOF >> /etc/profile.local
PATH="\$PATH:/mein/neuer/pfad/bin" export PATH EOF ====
Beachte das '\' bei '\$PATH'!
==== Alternativ ==== cat <<'EOF' >> /etc/profile.local
PATH="$PATH:/mein/neuer/pfad/bin" export PATH EOF ====
Beachte die "''" beim 'EOF'.
Auch eine Lösung. Wäre der echo Befehl aber nicht einfacher? Ich habe es so gelöst: mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp Ob es eine soo tolle Lösung ist weiß ich nicht, aber es hat auf Anhieb geklappt. Gruß Marcus
Hallo, Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Mo, 2004-04-26 um 21.13 schrieb David Haller:
Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Äh, funktioniert bei mir nicht. Wenn das eine Variante von
grep -C 10 PATH /etc/profile
sein soll, dann funktioniert beides nicht. Außer ich verstehe den Hilfe-Text falsch.
-B, --before-context=NUM print NUM lines of leading context -A, --after-context=NUM print NUM lines of trailing context -NUM same as both -B NUM and -A NUM -C, --context same as -2 Noch Fragen?
==== Alternativ ==== cat <<'EOF' >> /etc/profile.local
PATH="$PATH:/mein/neuer/pfad/bin" export PATH EOF ====
Beachte die "''" beim 'EOF'.
Auch eine Lösung. Wäre der echo Befehl aber nicht einfacher?
Nein.
Ich habe es so gelöst:
mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp
Schlecht. Dazu ist doch gerade die profile.local da. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Am Di, 2004-04-27 um 19.38 schrieb David Haller:
Hallo,
Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Mo, 2004-04-26 um 21.13 schrieb David Haller:
Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Äh, funktioniert bei mir nicht. Wenn das eine Variante von
grep -C 10 PATH /etc/profile
sein soll, dann funktioniert beides nicht. Außer ich verstehe den Hilfe-Text falsch.
-B, --before-context=NUM print NUM lines of leading context -A, --after-context=NUM print NUM lines of trailing context -NUM same as both -B NUM and -A NUM -C, --context same as -2
Noch Fragen?
Ja. Übersetzt mir das bitte mal in ein verständliches Deutsch. Ich habe die deutsche Ausgabe schon nicht verstanden. Bzw. was ist mit Kontext gemeint? Fünf Zeilen davor und danach?
==== Alternativ ==== cat <<'EOF' >> /etc/profile.local
PATH="$PATH:/mein/neuer/pfad/bin" export PATH EOF ====
Beachte die "''" beim 'EOF'.
Auch eine Lösung. Wäre der echo Befehl aber nicht einfacher?
Nein.
Gut, man könnte bei der Umleitung ein > vergessen und schon hätte man ein Problem.
Ich habe es so gelöst:
mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp
Schlecht. Dazu ist doch gerade die profile.local da.
Ich muss zugeben, dass ich auf meinen Systemen nur einmal eine /etc/profile.local gesehen habe. Aber welche Distri das jetzt war, kann ich nicht mehr sagen. Hier auf meiner SuSE 9.0 ist die Datei nicht vorhanden. Deshalb habe ich auch immer nur direkt mit der /etc/profile gearbeitet. Ich finde diese .local immer verwirrend. Für mich heißt das immer so viel, wie "nur auf dem Rechner". Daher ergeben diesen Dateien auch keinen Sinn für mich. Auch wenn ich weiß, dass das .local anders gemeint ist. Will mir aber nicht in die Birne. Kann man die /etc/profile.local, bzw. alle .local unter allen Distris verwenden? Oder müssen die vorher irgendwo definiert werden? Gruß Marcus
Hallo, Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 19.38 schrieb David Haller:
Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Mo, 2004-04-26 um 21.13 schrieb David Haller:
Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Äh, funktioniert bei mir nicht. Wenn das eine Variante von
grep -C 10 PATH /etc/profile
sein soll, dann funktioniert beides nicht. Außer ich verstehe den Hilfe-Text falsch.
-B, --before-context=NUM print NUM lines of leading context -A, --after-context=NUM print NUM lines of trailing context -NUM same as both -B NUM and -A NUM -C, --context same as -2
Noch Fragen?
Ja. Übersetzt mir das bitte mal in ein verständliches Deutsch. Ich habe die deutsche Ausgabe schon nicht verstanden. Bzw. was ist mit Kontext gemeint? Fünf Zeilen davor und danach?
Aber gern: -B NUMMER, --before-context=NUMMER gebe NUMMER Zeilen vor jeder Fundstelle aus -A NUMMER, --after-context=NUMMER gebe NUMMER Zeilen vor jeder Fundstelle aus -NUMMER wie -A NUMMER und -B NUMMER zusammen -C, --context wie -2, also wie -A 2 -B 2 also "gebe je 2 Zeilen _vor_ und _nach_ jeder Fundstelle aus. Sich ueberschneidender Kontext / Zusammenhang wird dabei zusammengefasst, so dass keine doppelten Zeilen ausgegeben werden. Am Beispiel wird das ganze (wie so oft) dann leichter verstaendlich (aus Platzgruenden bringe ich die "Zeilen" hier per "| xargs echo" auf eine Zeile, durch Leerzeichen getrennt): dh@slarty$ STR="`seq 1 10`"; echo "$STR" 1 2 : 10 dh@slarty$ echo "$STR" | grep -B1 5 | xargs echo 4 5 dh@slarty$ echo "$STR" | grep -A1 5 | xargs echo 5 6 dh@slarty$ echo "$STR" | grep -B1 -A1 5 | xargs echo 4 5 6 dh@slarty$ echo "$STR" | grep -1 5 | xargs echo 4 5 6 dh@slarty$ echo "$STR" | grep -B2 -A2 5 | xargs echo 3 4 5 6 7 dh@slarty$ echo "$STR" | grep -2 5 | xargs echo 3 4 5 6 7 dh@slarty$ echo "$STR" | grep -C 5 | xargs echo 3 4 5 6 7 dh@slarty$ echo "$STR" | grep -3 5 | xargs echo 2 3 4 5 6 7 8 dh@slarty$ echo "$STR" | grep -B1 -A5 5 | xargs echo 4 5 6 7 8 9 10 Immer noch Fragen?
==== Alternativ ==== cat <<'EOF' >> /etc/profile.local
PATH="$PATH:/mein/neuer/pfad/bin" export PATH EOF ==== [..] Gut, man könnte bei der Umleitung ein > vergessen und schon hätte man ein Problem.
Das Problem hat man auch beim echo und (leicht anders) beim sed.
Ich habe es so gelöst:
mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp
Schlecht. Dazu ist doch gerade die profile.local da.
Ich muss zugeben, dass ich auf meinen Systemen nur einmal eine /etc/profile.local gesehen habe. Aber welche Distri das jetzt war, kann ich nicht mehr sagen.
Hier auf meiner SuSE 9.0 ist die Datei nicht vorhanden. Deshalb habe ich auch immer nur direkt mit der /etc/profile gearbeitet.
*hrmpf* /etc/profile.local gibt's IIRC seit mindestens SuSE 5.3. dh@slarty$ grep '\.local' /etc/profile test -e /etc/profile.local && . /etc/profile.local (und das ist auf meiner SuSE 6.2). Und das gibt's auch bei der SuSE 9.1 noch. AFAIK verwenden die meisten Distributionen sowas. Vgl. /etc/ppp/ip-{up,down}.local.
Ich finde diese .local immer verwirrend. Für mich heißt das immer so viel, wie "nur auf dem Rechner".
Jo mei, ist /etc/profile denn nicht auch Rechnerspezifisch?
Daher ergeben diesen Dateien auch keinen Sinn für mich. Auch wenn ich weiß, dass das .local anders gemeint ist. Will mir aber nicht in die Birne.
Die .local sind fuer eigene Anpassungen. Denn die /etc/profile wird u.U. von Yast / SuSEconfig, spaetestens aber beim naechsten Update ueberschrieben. Durch den Mechanismus der profile.local, die von profile gesourced wird, kann man seine eigenen Aenderungen "konsistent" pflegen, ohne das sich die Distri bzw. deren Tools daran vergreifen wird. Denk dir einfach die ".local" als "nicht von der Distri". Und ja, ueblicherweise muss man die .local Dateien selber anlegen.
Kann man die /etc/profile.local, bzw. alle .local unter allen Distris verwenden? Oder müssen die vorher irgendwo definiert werden?
s.o. Es ist ein AFAIK ueblicher Mechanismus, der AFAIK inzwischen auch im LSB festgehalten ist. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Am Di, 2004-04-27 um 23.42 schrieb David Haller:
Hallo,
Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 19.38 schrieb David Haller:
Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Mo, 2004-04-26 um 21.13 schrieb David Haller:
Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Äh, funktioniert bei mir nicht. Wenn das eine Variante von
grep -C 10 PATH /etc/profile
sein soll, dann funktioniert beides nicht. Außer ich verstehe den Hilfe-Text falsch.
-B, --before-context=NUM print NUM lines of leading context -A, --after-context=NUM print NUM lines of trailing context -NUM same as both -B NUM and -A NUM -C, --context same as -2
Noch Fragen?
Ja. Übersetzt mir das bitte mal in ein verständliches Deutsch. Ich habe die deutsche Ausgabe schon nicht verstanden. Bzw. was ist mit Kontext gemeint? Fünf Zeilen davor und danach?
Aber gern:
-B NUMMER, --before-context=NUMMER gebe NUMMER Zeilen vor jeder Fundstelle aus -A NUMMER, --after-context=NUMMER gebe NUMMER Zeilen vor jeder Fundstelle aus -NUMMER wie -A NUMMER und -B NUMMER zusammen -C, --context wie -2, also wie -A 2 -B 2 also "gebe je 2 Zeilen _vor_ und _nach_ jeder Fundstelle aus.
Sich ueberschneidender Kontext / Zusammenhang wird dabei zusammengefasst, so dass keine doppelten Zeilen ausgegeben werden.
[Beispiele mal entfernt]
Immer noch Fragen?
Nöö. Das hab ich jetzt kapiert. Zwar muss ich es mir noch paar mal durchlesen, bis ich es mir merke, aber Fragen gibts erstmal keine mehr dazu. [...]
Ich habe es so gelöst:
mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp
Schlecht. Dazu ist doch gerade die profile.local da.
Ich muss zugeben, dass ich auf meinen Systemen nur einmal eine /etc/profile.local gesehen habe. Aber welche Distri das jetzt war, kann ich nicht mehr sagen.
Hier auf meiner SuSE 9.0 ist die Datei nicht vorhanden. Deshalb habe ich auch immer nur direkt mit der /etc/profile gearbeitet.
*hrmpf*
/etc/profile.local gibt's IIRC seit mindestens SuSE 5.3.
dh@slarty$ grep '\.local' /etc/profile test -e /etc/profile.local && . /etc/profile.local
(und das ist auf meiner SuSE 6.2). Und das gibt's auch bei der SuSE 9.1 noch. AFAIK verwenden die meisten Distributionen sowas.
Vgl. /etc/ppp/ip-{up,down}.local.
Wie gesagt. Bisher habe ich nur ein einziges Mal eine /etc/profile.local gesehen. Deshalb hat mich die auch nicht weiter interessiert. Ich dachte, dass das aus irgendeiner Konstellation heraus entstand. Zumal das noch in einer Zeit war, wo ich mich noch mit der Konsole rum geschlagen und die Finger von /etc/* gelassen habe.
Ich finde diese .local immer verwirrend. Für mich heißt das immer so viel, wie "nur auf dem Rechner".
Jo mei, ist /etc/profile denn nicht auch Rechnerspezifisch?
Ja. Deshalb hat mich das ja verwirrt. Das war für mich einfach unlogisch. Der Name ist es eigentlich immer noch. Verständlicher wäre so was wie .benutzerdefiniert (keine Ahnung, was das auf englisch heißt).
Daher ergeben diesen Dateien auch keinen Sinn für mich. Auch wenn ich weiß, dass das .local anders gemeint ist. Will mir aber nicht in die Birne.
Die .local sind fuer eigene Anpassungen. Denn die /etc/profile wird u.U. von Yast / SuSEconfig, spaetestens aber beim naechsten Update ueberschrieben. Durch den Mechanismus der profile.local, die von profile gesourced wird, kann man seine eigenen Aenderungen "konsistent" pflegen, ohne das sich die Distri bzw. deren Tools daran vergreifen wird.
Denk dir einfach die ".local" als "nicht von der Distri".
Und ja, ueblicherweise muss man die .local Dateien selber anlegen.
Gut zu wissen. Wie werden diese Dateien eigentlich gesourced? Einfach mit . /pfad/zur/datei ?
Kann man die /etc/profile.local, bzw. alle .local unter allen Distris verwenden? Oder müssen die vorher irgendwo definiert werden?
s.o. Es ist ein AFAIK ueblicher Mechanismus, der AFAIK inzwischen auch im LSB festgehalten ist.
Damit sollte ja jede bekanntere/größere Distri diesen Mechanismus verfügen. Das macht einiges leichter. Danke. Gruß Marcus
Hallo, Am Wed, 28 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 23.42 schrieb David Haller: [..] [Beispiele mal entfernt]
Immer noch Fragen?
Nöö. Das hab ich jetzt kapiert. Zwar muss ich es mir noch paar mal durchlesen, bis ich es mir merke, aber Fragen gibts erstmal keine mehr dazu.
Fein. *g* Es ist immer schoen zu wissen, dass sich die Tipperei gelohnt hat. [..]
/etc/profile.local gibt's IIRC seit mindestens SuSE 5.3.
dh@slarty$ grep '\.local' /etc/profile test -e /etc/profile.local && . /etc/profile.local
(und das ist auf meiner SuSE 6.2). Und das gibt's auch bei der SuSE 9.1 noch. AFAIK verwenden die meisten Distributionen sowas.
Vgl. /etc/ppp/ip-{up,down}.local.
Wie gesagt. Bisher habe ich nur ein einziges Mal eine /etc/profile.local gesehen. Deshalb hat mich die auch nicht weiter interessiert. Ich dachte, dass das aus irgendeiner Konstellation heraus entstand.
*g* AFAIR ist das irgendwo auch dokumentiert -- das letzte Handbuch, dass ich aber wirklich gelesen habe, war das zur SuSE 5.3 ;) Und: ==== /etc/profile [SUSE 9.1] ==== # # And now let's see if there is a local profile # (for options defined by your sysadmin, not SuSE Linux) # test -s /etc/profile.local && . /etc/profile.local ==== Steht sinngemaess auch schon in der /etc/profile meiner SuSE 6.2. Generell gilt einfach, dass man die Kommentare in den Config-Dateien lesen sollte. Das gilt fuer /etc/sysconfig/* unter SuSE genauso wie fuer andere Config-Dateien, das gilt sogar fuer die /etc/sendmail.cf ;)
Ich finde diese .local immer verwirrend. Für mich heißt das immer so viel, wie "nur auf dem Rechner".
Jo mei, ist /etc/profile denn nicht auch Rechnerspezifisch?
Ja. Deshalb hat mich das ja verwirrt. Das war für mich einfach unlogisch. Der Name ist es eigentlich immer noch. Verständlicher wäre so was wie .benutzerdefiniert (keine Ahnung, was das auf englisch heißt).
Das waere "userdefined", aber das waere auch irrefuehrend, denn es ist ja eben nicht Benutzerdefiniert, sondern Admin-definiert. Und das ist dann auch doof... Denk dir einfach, bei allen anderen Config-Dateien in /etc/ ein ".dist" hintendran. /etc/profile#.dist => durch die Distribution definiert /etc/profile.local => durch den Admin definiert Jedenfalls: der Mechanismus ist sehr praktisch und wird inzwischen recht haeufig verwendet. Bei SuSE 6.2 war das z.B. noch wesentlich weniger umgesetzt.
Denk dir einfach die ".local" als "nicht von der Distri".
Und ja, ueblicherweise muss man die .local Dateien selber anlegen.
Gut zu wissen. Wie werden diese Dateien eigentlich gesourced? Einfach mit
. /pfad/zur/datei ?
Ja. Der Punkt ist der eigentliche "source"-Befehl, "source" ist die (nicht-portable) GNU Ergaenzung. ==== $ help . source .: . filename Read and execute commands from FILENAME and return. The pathnames in $PATH are used to find the directory containing FILENAME. source: source filename Read and execute commands from FILENAME and return. The pathnames in $PATH are used to find the directory containing FILENAME. ==== Noch Fragen? ;)
s.o. Es ist ein AFAIK ueblicher Mechanismus, der AFAIK inzwischen auch im LSB festgehalten ist.
Damit sollte ja jede bekanntere/größere Distri diesen Mechanismus verfügen. Das macht einiges leichter.
Wie gesagt: ich "weiss" es nicht, ob das im LSB ist. Aber aehnliche Mechanismen werden inzwischen wohl meist verwendet. Da hilft dann ggfs. ein egrep '(^|[[:space:]]+)(\.|source)[[:space:]]' CONFIGDATEI" Das sollte dir auf jeder Distri verraten, ob eine Datei gesourced wird (gilt fuer profile, init-scripte, shell-scripte generell). Fuer andere Config-Dateien (z.B. Apache, modules.conf und modprobe.conf) geht dann: egrep '(^|[[:space:]]+)include[[:space:]]' CONFIGDATEI" usw. Analog anzupassen fuer andere Arten von "includes"... -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo. Am Do, 2004-04-29 um 01.59 schrieb David Haller: [...]
Wie gesagt. Bisher habe ich nur ein einziges Mal eine /etc/profile.local gesehen. Deshalb hat mich die auch nicht weiter interessiert. Ich dachte, dass das aus irgendeiner Konstellation heraus entstand.
*g* AFAIR ist das irgendwo auch dokumentiert -- das letzte Handbuch, dass ich aber wirklich gelesen habe, war das zur SuSE 5.3 ;)
Hmm. Ich habe mir zwar die Handbücher zur 7.0 und 8.0 durchgelesen, aber auch nie komplett. Mit so 'tiefgreifenden' Dingen beschäftige ich mich erst seit der 8.1. Und auch dann suche ich immer nur nach bestimmten Dingen. Wenn ich ein Skript für die Internet-Einwahl schreibe, dann lese ich mir das entsprechende Kapitel im Handbuch durch. Sofern ich das Handbuch finde. Seit meinem Umzug ist das nämlich so eine Sache. ;-) [,,,]
Generell gilt einfach, dass man die Kommentare in den Config-Dateien lesen sollte. Das gilt fuer /etc/sysconfig/* unter SuSE genauso wie fuer andere Config-Dateien, das gilt sogar fuer die /etc/sendmail.cf ;)
Die Kommentare in Konfig-Dateien lese ich eigentlich immer. Na, ja. Zumindest in den Sektionen, in denen ich auch etwas bearbeite. Das dauert dann zwar immer ewig, weil ich mit steak und ding arbeite, ist aber einfacher zu verstehen, als wenn man diese Variante mit einer Manpage praktiziert. /etc/sendmail.cf habe ich mir einmal angeschaut. Danach habe ich das Grauen bekommen und wieder Postfix installiert. *brrr* ;-)
Ich finde diese .local immer verwirrend. Für mich heißt das immer so viel, wie "nur auf dem Rechner".
Jo mei, ist /etc/profile denn nicht auch Rechnerspezifisch?
Ja. Deshalb hat mich das ja verwirrt. Das war für mich einfach unlogisch. Der Name ist es eigentlich immer noch. Verständlicher wäre so was wie .benutzerdefiniert (keine Ahnung, was das auf englisch heißt).
Das waere "userdefined", aber das waere auch irrefuehrend, denn es ist ja eben nicht Benutzerdefiniert, sondern Admin-definiert. Und das ist dann auch doof...
Da haste war! Wie wäre es mit nodist? Beschreibt auch ganz gut deine Erklärung da unten VVVV.
Denk dir einfach, bei allen anderen Config-Dateien in /etc/ ein ".dist" hintendran.
/etc/profile#.dist => durch die Distribution definiert /etc/profile.local => durch den Admin definiert
Jedenfalls: der Mechanismus ist sehr praktisch und wird inzwischen recht haeufig verwendet. Bei SuSE 6.2 war das z.B. noch wesentlich weniger umgesetzt.
[...]
Gut zu wissen. Wie werden diese Dateien eigentlich gesourced? Einfach mit
. /pfad/zur/datei ?
Ja. Der Punkt ist der eigentliche "source"-Befehl, "source" ist die (nicht-portable) GNU Ergaenzung.
Deshalb habe ich so blöd gefragt. Aus der ~/.muttrc, zum Bleistift, kenne ich das auch mit source. Bzw. mit Include aus der /etc/httpd/httpd.conf. Mit dem . habe ich es noch nicht gesehen. [...] Aber man lernt ja nie aus. Selbst wenn man denkt, man wüsste bereits alles. Oder gerade dann? ;-) Gruß Marcus
Hallo Marcus, Am Dienstag, 27. April 2004 23.01 schrieb Marcus Habermehl:
Am Di, 2004-04-27 um 19.38 schrieb David Haller:
Am Tue, 27 Apr 2004, Marcus Habermehl schrieb:
Am Mo, 2004-04-26 um 21.13 schrieb David Haller:
Am Mon, 26 Apr 2004, Marcus Habermehl schrieb:
Vielleicht sollte ich doch wieder anfangen, die Dateien _komplett_ durch zugucken und nicht mit grep arbeiten. :-(
grep -10 PATH /etc/profile
Äh, funktioniert bei mir nicht. Wenn das eine Variante von
grep -C 10 PATH /etc/profile
sein soll, dann funktioniert beides nicht. Außer ich verstehe den Hilfe-Text falsch.
-B, --before-context=NUM print NUM lines of leading context -A, --after-context=NUM print NUM lines of trailing context -NUM same as both -B NUM and -A NUM -C, --context same as -2
Noch Fragen?
Ja. Übersetzt mir das bitte mal in ein verständliches Deutsch. Ich habe die deutsche Ausgabe schon nicht verstanden. Bzw. was ist mit Kontext gemeint? Fünf Zeilen davor und danach?
==== Alternativ ==== cat <<'EOF' >> /etc/profile.local
PATH="$PATH:/mein/neuer/pfad/bin" export PATH EOF ====
Beachte die "''" beim 'EOF'.
Auch eine Lösung. Wäre der echo Befehl aber nicht einfacher?
Nein.
Gut, man könnte bei der Umleitung ein > vergessen und schon hätte man ein Problem.
Ich habe es so gelöst:
mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp
Schlecht. Dazu ist doch gerade die profile.local da.
Ich muss zugeben, dass ich auf meinen Systemen nur einmal eine /etc/profile.local gesehen habe. Aber welche Distri das jetzt war, kann ich nicht mehr sagen.
Hier auf meiner SuSE 9.0 ist die Datei nicht vorhanden. Deshalb habe ich auch immer nur direkt mit der /etc/profile gearbeitet.
Ich finde diese .local immer verwirrend. Für mich heißt das immer so viel, wie "nur auf dem Rechner". Daher ergeben diesen Dateien auch keinen Sinn für mich. Auch wenn ich weiß, dass das .local anders gemeint ist. Will mir aber nicht in die Birne.
Kann man die /etc/profile.local, bzw. alle .local unter allen Distris verwenden? Oder müssen die vorher irgendwo definiert werden?
Ob das alle Distris unterstuetzen weiss ich nicht, aber wie du nachschauen kannst ob es die entsprechende Distri tut. Du musst nur in der Datei /etc/profile schauen ob Zeilen wie die folgenden vorhanden sind. # And now let's see if there is a local profile # (for options defined by your sysadmin, not SuSE Linux) # test -s /etc/profile.local && . /etc/profile.local Es lohnt sich auf alle Faelle die /etc/profile.local zu nutzten. Sollte es eine Distri nicht unterstuetzen, so musst du nur die Zeile mit dem test -s ... in die /etc/profile kopieren. Grüsse Urs
Hallo Marcus, hallo Leute, Am Montag, 26. April 2004 07:23 schrieb Marcus Habermehl: [Wo wird $PATH gesetzt?]
Da ich mit grep PATH /etc/profile gesucht habe, wurde mir die einzelnen Pfade natürlich nicht angezeigt. Ich bin einfach davon ausgegangen, dass die alle in einer Zeile aufgelistet werden.
Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann.
Zeige eine Meldung an, die die User darum bittet ;-) Oder lege schlicht Symlinks in /usr/bin an, die auf Dein Programm verweisen - sollte die sauberste Lösung sein. Notfalls kannst Du auch ein kleines Script in /etc/bash_completion.d/ ablegen, das den Befehl PATH="$PATH:/opt/dein/verzeichnis/bin" ausführt. Meines Wissens werden die Scripte in diesem Verzeichnis beim Starten einer interaktiven Bash ausgeführt. "Sauber" ist diese Lösung allerdings nicht, das Verzeichnis ist eigentlich zum Einrichten von completion-Einträgen gedacht (sprich: was beim Drücken von <tab> gelistet werden soll). BTW: Das scriptgesteuerte "Bearbeiten" einer Datei während der RPM-Installation solltest Du vermeiden. Davon abgesehen, dass es IMHO etwas nervig ist, hast Du hinterher das Problem, bei der Deinstallation Deine Einträge wieder zu löschen... Gruß Christian Boltz -- Nicht das ich frei von Paranoia Schueben waere ;), aber wenn Dir das passiert spiel sofort Lotto, bei dem Glueck bekommst Du bestimmt 4 Wochen den 6er mit Superzahl. [Maik Holtkamp in suse-linux]
Am Mo, 2004-04-26 um 22.40 schrieb Christian Boltz:
Hallo Marcus, hallo Leute,
Am Montag, 26. April 2004 07:23 schrieb Marcus Habermehl: [Wo wird $PATH gesetzt?]
Da ich mit grep PATH /etc/profile gesucht habe, wurde mir die einzelnen Pfade natürlich nicht angezeigt. Ich bin einfach davon ausgegangen, dass die alle in einer Zeile aufgelistet werden.
Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann.
Zeige eine Meldung an, die die User darum bittet ;-)
Bringt nichts, wenn das RPM über ein GUI installiert wird. Außer bei KPackage vielleicht.
Oder lege schlicht Symlinks in /usr/bin an, die auf Dein Programm verweisen - sollte die sauberste Lösung sein.
Habe ich mir am Anfang auch überlegt. Aber irgendwie begeistert mich die Sache nicht.
Notfalls kannst Du auch ein kleines Script in /etc/bash_completion.d/ ablegen, das den Befehl PATH="$PATH:/opt/dein/verzeichnis/bin" ausführt. Meines Wissens werden die Scripte in diesem Verzeichnis beim Starten einer interaktiven Bash ausgeführt. "Sauber" ist diese Lösung allerdings nicht, das Verzeichnis ist eigentlich zum Einrichten von completion-Einträgen gedacht (sprich: was beim Drücken von <tab> gelistet werden soll).
Wenn das nur die Einträge hin gehören, ist die Lösung wirklich alles andere als sauber. Und sagt mir auch irgendwie nicht zu.
BTW: Das scriptgesteuerte "Bearbeiten" einer Datei während der RPM-Installation solltest Du vermeiden. Davon abgesehen, dass es IMHO etwas nervig ist, hast Du hinterher das Problem, bei der Deinstallation Deine Einträge wieder zu löschen...
Warum wäre das nicht so gut, und wäre es nervig? Der User/Admin bekommt davon doch nichts mit. Außer das Skript löscht die Datei, anstatt sie zu bearbeiten. Aber wie in der Antwort auf Davids Mail habe ich eine Lösung gefunden, die bisher funktioniert. mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp Das Verschieben ist vielleicht unnötig. Abe als ich es mal ohne probiert habe, hatte ich dann eine leere Datei. Für das Lösche habe ich mir in %postun folgendes eingetragen. mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/\/opt\/xfce4\/bin/ d' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp Klappt auch wunderbar. Aber danke für die Vorschläge. Gruß Marcus
Hallo Marcus, hallo Leute, Am Dienstag, 27. April 2004 18:33 schrieb Marcus Habermehl:
Am Mo, 2004-04-26 um 22.40 schrieb Christian Boltz:
Am Montag, 26. April 2004 07:23 schrieb Marcus Habermehl: [Wo wird $PATH gesetzt?]
Da ich mit grep PATH /etc/profile gesucht habe, wurde mir die einzelnen Pfade natürlich nicht angezeigt. Ich bin einfach davon ausgegangen, dass die alle in einer Zeile aufgelistet werden.
Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann.
Zeige eine Meldung an, die die User darum bittet ;-)
Bringt nichts, wenn das RPM über ein GUI installiert wird. Außer bei KPackage vielleicht.
In YaST sind mir auch schon Meldungen entgegengekommen...
Oder lege schlicht Symlinks in /usr/bin an, die auf Dein Programm verweisen - sollte die sauberste Lösung sein.
Habe ich mir am Anfang auch überlegt. Aber irgendwie begeistert mich die Sache nicht.
Was spricht dagegen? Anders gefragt: Über wie viele Symlinks reden wir? Einen? Zehn? Hundert?
BTW: Das scriptgesteuerte "Bearbeiten" einer Datei während der RPM-Installation solltest Du vermeiden. Davon abgesehen, dass es IMHO etwas nervig ist, hast Du hinterher das Problem, bei der Deinstallation Deine Einträge wieder zu löschen...
Warum wäre das nicht so gut, und wäre es nervig? Der User/Admin bekommt davon doch nichts mit.
_Genau das_ empfinde ich als nervig ;-)
Außer das Skript löscht die Datei, anstatt sie zu bearbeiten.
Das wäre natürlich der "worst case".
Aber wie in der Antwort auf Davids Mail habe ich eine Lösung gefunden, die bisher funktioniert.
mv /etc/profile /etc/profile.tmp
besser cp, damit die /etc/profile garantiert auch hinterher existiert. Mögliche Gründe für einen Fehler wären beispielsweise: - falls sed nicht installiert sein sollte, auch wenn es unwahrscheinlich ist, wird die Datei nicht wieder zurückkopiert. - falls "zufällig" (man murphy ;-) die Installation an genau dieser Stelle abgebrochen wird, wird die Datei ebenfalls nicht mehr zurückkopiert.
cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile
Erstens: Useless use of cat!
rm /etc/bash.bashrc.tmp /etc/profile.tmp
Zweitens: Besser wäre IMHO, die beiden Befehle mit einer UND-Verknüpfung zu verketten, damit das mv nur ausgeführt wird, wenn sed fehlerfrei lief: sed '[...]' < /etc/profile > /etc/profile.tmp && mv /etc/profile.tmp /etc/profile Dadurch wird der mv-Befehl nur ausgeführt, wenn sed erfolgreich war. Drittens: Der sed-Befehl beinhaltet ein gewisses Risiko. Derzeit kommt "openwin" zwar nur einmal in /etc/profile vor, aber das könnte sich jederzeit ändern und Dein Befehl würde Mist bauen... Viertens: statt /etc/profile.tmp solltest Du einen "unwahrscheinlicheren" Namen verwenden, z. B. /etc/profile.tmp_Name-deines-Pakets_irgendwas-kryptisches (für letzteres sollte das Abstauben der Tastatur reichen ;-) Die Optimallösung wäre übrigens die Verwendung von mktemp. Fünftens: /etc/profile wird bei einem Update von aaa_base überschrieben, Du solltest Dich besser an die /etc/profile.local halten, die wird garantiert nicht angetastet.
Das Verschieben ist vielleicht unnötig. Abe als ich es mal ohne probiert habe, hatte ich dann eine leere Datei.
Glaube mir: Es ist nicht unnötig, das Resultat "leere Datei" kommt fast immer.
Für das Lösche habe ich mir in %postun folgendes eingetragen.
mv /etc/profile /etc/profile.tmp cat /etc/profile.tmp | sed '/\/opt\/xfce4\/bin/ d' > /etc/profile rm /etc/bash.bashrc.tmp /etc/profile.tmp
Grundsätzlich gelten bezüglich des Programmierstils meine obigen Vorschläge. Allerdings stört mich der sed-Befehl: Es werden alle Zeilen gelöscht, die /opt/xfce4/bin enthalten. In der von SuSE gelieferten Datei kommt dieser Text nicht vor, aber mir persönlich wäre das Risiko zu groß, dass zuviel erwischt wird (und wehe, $admin findet heraus, dass Dein Paket schuld war...) Kurzfassung: Ganz so einfach, wie man zuerst denkt, ist es nicht ;-) Ich denke, nach der Lektüre dieser Mail kannst Du Dir denken, warum ich vom ungefragten, scriptgesteuerten Modifizieren einer Datei nichts halte... Gruß Christian Boltz PS: Gegenvorschlag, wenn es unbedingt scriptgesteuert laufen soll: - Installation - echo ' PATH="/opt/xfce4/bin:$PATH" # added by xfce-installation export PATH # added by xfce-installation ' >> /etc/profile.local - Deinstallation - grep -v "# added by xfce-installation" \ /etc/profile.local > /etc/profile.local.tmp && \ mv /etc/profile.local.tmp /etc/profile.local Statt "added by xfce-installation" kannst Du natürlich jeden anderen Kommentar verwenden, aber er sollte lang genug sein, um nicht zufällig an anderer Stelle wieder aufzutauchen. -- never touch a running system ----> for windows: never touch the keyboard of a running system
Am Di, 2004-04-27 um 23.12 schrieb Christian Boltz:
Hallo Marcus, hallo Leute,
Am Dienstag, 27. April 2004 18:33 schrieb Marcus Habermehl:
Am Mo, 2004-04-26 um 22.40 schrieb Christian Boltz:
Am Montag, 26. April 2004 07:23 schrieb Marcus Habermehl: [Wo wird $PATH gesetzt?]
Da ich mit grep PATH /etc/profile gesucht habe, wurde mir die einzelnen Pfade natürlich nicht angezeigt. Ich bin einfach davon ausgegangen, dass die alle in einer Zeile aufgelistet werden.
Jetzt muss ich mir nur noch überlegen, wie ich einen neuen Pfad per RPM hinzufügen kann.
Zeige eine Meldung an, die die User darum bittet ;-)
Bringt nichts, wenn das RPM über ein GUI installiert wird. Außer bei KPackage vielleicht.
In YaST sind mir auch schon Meldungen entgegengekommen...
Ich dachte, dass die speziell in YaST2 eingebunden wurden, oder so ähnlich. Also meinst du, wenn ich ein echo bla bla einsetze, öffnet sich auch bei YaST2 ein Meldungsfenster?
Oder lege schlicht Symlinks in /usr/bin an, die auf Dein Programm verweisen - sollte die sauberste Lösung sein.
Habe ich mir am Anfang auch überlegt. Aber irgendwie begeistert mich die Sache nicht.
Was spricht dagegen? Anders gefragt: Über wie viele Symlinks reden wir? Einen? Zehn? Hundert?
Ich hatte hier einen WM, der hat fast zehn Dateien nach /usr/local/bin installiert. Bei XFce4 wird sich auch einiges ansammeln. Mir geht es halt darum, dass ich gerne einheitliche spec Files hätte. Und bei manchen Paketen wäre das dann zu viele Links. Zumal ich die Variante mit $PATH doch stilvoller finde. Irgendwo.
BTW: Das scriptgesteuerte "Bearbeiten" einer Datei während der RPM-Installation solltest Du vermeiden. Davon abgesehen, dass es IMHO etwas nervig ist, hast Du hinterher das Problem, bei der Deinstallation Deine Einträge wieder zu löschen...
Warum wäre das nicht so gut, und wäre es nervig? Der User/Admin bekommt davon doch nichts mit.
_Genau das_ empfinde ich als nervig ;-)
Dann dürftest du dir aber auch keine SuSE-RPMs installieren. Ich denke mal, dass da auch das Eine oder Andere geändert wird.
Außer das Skript löscht die Datei, anstatt sie zu bearbeiten.
Das wäre natürlich der "worst case".
Ja. Vor allem dann, wenn es die /etc/ld.so.conf trifft. Wie bei mir vorhin.
Aber wie in der Antwort auf Davids Mail habe ich eine Lösung gefunden, die bisher funktioniert.
mv /etc/profile /etc/profile.tmp
besser cp, damit die /etc/profile garantiert auch hinterher existiert.
Mögliche Gründe für einen Fehler wären beispielsweise: - falls sed nicht installiert sein sollte, auch wenn es unwahrscheinlich ist, wird die Datei nicht wieder zurückkopiert. - falls "zufällig" (man murphy ;-) die Installation an genau dieser Stelle abgebrochen wird, wird die Datei ebenfalls nicht mehr zurückkopiert.
Da bin ich gerade dabei, Sicherungen einzubauen. Aber an meiner /etc/ld.so.conf (s. o.) sieht man, dass das noch nicht läuft. ;-)
cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile
Erstens: Useless use of cat!
Jetzt, wo du es sagst. Ich benutze aber immer cat. Auch wenn ich mit grep eine Datei durchsuchen will. Keine Ahnung warum. Ich glaube, dass ich das mal am Anfang irgendwo gelesen habe, und dann hat es sich ins Hirn eingebrannt.
rm /etc/bash.bashrc.tmp /etc/profile.tmp
Zweitens: Besser wäre IMHO, die beiden Befehle mit einer UND-Verknüpfung zu verketten, damit das mv nur ausgeführt wird, wenn sed fehlerfrei lief:
sed '[...]' < /etc/profile > /etc/profile.tmp && mv /etc/profile.tmp /etc/profile
Dadurch wird der mv-Befehl nur ausgeführt, wenn sed erfolgreich war.
Daran habe ich auch schon gedacht. Jetzt, wo ich das alles lese, habe ich das Gefühl, dass ich aus der Shell wieder raus gekommen bin. :-(
Drittens: Der sed-Befehl beinhaltet ein gewisses Risiko. Derzeit kommt "openwin" zwar nur einmal in /etc/profile vor, aber das könnte sich jederzeit ändern und Dein Befehl würde Mist bauen...
Da hast du natürlich auch recht. Allerdings habe ich vor auf die .local Dateien auszuweichen. Aber natürlich könnte auch da etwas mehrfach vorkommen. Man weiß ja nie, was ein gelangweilter Admin rumwerkelt. ;-) Ich habe mir überlegt, einfach nur diese Zeile in die /etc/profile.local einzufügen. export PATH="$PATH:/opt/xfce4/bin" Beim Löschen brauche ich dann nur nach exakt dieser Zeile zu suchen und kann die dann ohne Probleme löschen. Außer ich baue Mist beim Skript.
Viertens: statt /etc/profile.tmp solltest Du einen "unwahrscheinlicheren" Namen verwenden, z. B. /etc/profile.tmp_Name-deines-Pakets_irgendwas-kryptisches (für letzteres sollte das Abstauben der Tastatur reichen ;-) Die Optimallösung wäre übrigens die Verwendung von mktemp.
mktemp habe ich noch nie verwendet. Den ersten Zeilen der Manpage hört sich das aber recht interessant an. Mir ist auch der Gedanke gekommen, die Sicherungen nach /tmp zu kopieren. Da ist die Gefahr noch geringer, dass ich etwas überschreibe.
Fünftens: /etc/profile wird bei einem Update von aaa_base überschrieben, Du solltest Dich besser an die /etc/profile.local halten, die wird garantiert nicht angetastet.
s. o.
Das Verschieben ist vielleicht unnötig. Abe als ich es mal ohne probiert habe, hatte ich dann eine leere Datei.
Glaube mir: Es ist nicht unnötig, das Resultat "leere Datei" kommt fast immer.
Wahr für wahr. *heul* Ich könnt immer noch wegen meiner ld.so.conf schreien. [...]
Ich denke, nach der Lektüre dieser Mail kannst Du Dir denken, warum ich vom ungefragten, scriptgesteuerten Modifizieren einer Datei nichts halte...
Ja. Vor allem die Fehlerquellen sind ja eigentlich gewaltig. Wenn man da nicht wirklich aufpasst, hat man dann ein Windows-Setup. ;-)
PS: Gegenvorschlag, wenn es unbedingt scriptgesteuert laufen soll: - Installation - echo ' PATH="/opt/xfce4/bin:$PATH" # added by xfce-installation export PATH # added by xfce-installation ' >> /etc/profile.local - Deinstallation - grep -v "# added by xfce-installation" \ /etc/profile.local > /etc/profile.local.tmp && \ mv /etc/profile.local.tmp /etc/profile.local Statt "added by xfce-installation" kannst Du natürlich jeden anderen Kommentar verwenden, aber er sollte lang genug sein, um nicht zufällig an anderer Stelle wieder aufzutauchen.
Muss ich mir mal durch den Kopf gehen lassen. Die Idee ist eigentlich alles andere als verkehrt. Gruß Marcus
Hallo, Am Wed, 28 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 23.12 schrieb Christian Boltz:
Am Dienstag, 27. April 2004 18:33 schrieb Marcus Habermehl: [..] Was spricht dagegen? Anders gefragt: Über wie viele Symlinks reden wir? Einen? Zehn? Hundert?
Ich hatte hier einen WM, der hat fast zehn Dateien nach /usr/local/bin installiert. Bei XFce4 wird sich auch einiges ansammeln.
Mir geht es halt darum, dass ich gerne einheitliche spec Files hätte. Und bei manchen Paketen wäre das dann zu viele Links. Zumal ich die Variante mit $PATH doch stilvoller finde.
Irgendwo.
Find ich ok. Man muss halt einen Kompromiss zwischen symlinks und nem aufgeblaehten PATH finden. Ich finde, so ab 15-20 Dateien lohnt sich die Aufnahme in PATH.
Außer das Skript löscht die Datei, anstatt sie zu bearbeiten.
Das wäre natürlich der "worst case".
Ja. Vor allem dann, wenn es die /etc/ld.so.conf trifft. Wie bei mir vorhin.
Die ld.so.conf kann man ja nun wirklich einfach neu erstellen. Oder nachinstallieren. Oder sich eine mailen lassen. Ich arbeite hier uebrigens lieber mit nem wrapper-script, dass dann LD_LIBRARY_PATH setzt, so z.B. fuer mein "sX" script (startX), das dann fuer WindowMaker (meinem normalen WM, sX wird dann als swmaker aufgerufen, oder auch als sX wmaker) folgendes macht: ==== function conf_wmaker() { WMVERSION="0.80" WMROOT="/opt/WMaker" export GNUSTEP_USER_ROOT="~/GNUstep-${WMVERSION}" export GNUSTEP_LOCAL_ROOT="$WMROOT" export GNUSTEP_SYSTEM_ROOT="/opt/WMaker/GNUstep" LD_LIBRARY_PATH="${WMROOT}/lib:$LD_LIBRARY_PATH" LD_LIBRARY_PATH=`echo $LD_LIBRARY_PATH | sed 's/^://;s/:$//'` export LD_LIBRARY_PATH export PATH="${WMROOT}/bin:$PATH" export MANPATH="${WMROOT}/man:$MANPATH" if ! test -d ~/GNUstep || test -L ~/GNUstep; then if test "x`readlink ~/GNUstep`" != "x${HOME}/GNUstep-${WMVERSION}" then rm ~/GNUstep ln -s ~/GNUstep-${WMVERSION} ~/GNUstep fi fi } ==== Analoges mache ich auch mit anderen Sachen, sowas macht z.B. das Mozilla-Startscript, IIRC das startkde-script u.v.a.m...
Aber wie in der Antwort auf Davids Mail habe ich eine Lösung gefunden, die bisher funktioniert.
mv /etc/profile /etc/profile.tmp
besser cp, damit die /etc/profile garantiert auch hinterher existiert.
ACK.
Mögliche Gründe für einen Fehler wären beispielsweise: - falls sed nicht installiert sein sollte, auch wenn es unwahrscheinlich ist, wird die Datei nicht wieder zurückkopiert. - falls "zufällig" (man murphy ;-) die Installation an genau dieser Stelle abgebrochen wird, wird die Datei ebenfalls nicht mehr zurückkopiert.
=> help trap
Da bin ich gerade dabei, Sicherungen einzubauen. Aber an meiner /etc/ld.so.conf (s. o.) sieht man, dass das noch nicht läuft. ;-)
==== CONFIG="/etc/foo" TMPFILE="`mktemp \"/tmp/${CONFIG}.$$.XXXXXX\"`" || exit 1 trap rm -f "${TMPFILE}" 1 2 3 13 14 15 EXIT sed 's/foo/bar/' < "$CONFIG" > "${TMPFILE}" \ && mv "${TMPFILE}" "${CONFIG}" ==== Das sollte hinreichend sicher sein.
cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile
Erstens: Useless use of cat!
Jetzt, wo du es sagst. Ich benutze aber immer cat. Auch wenn ich mit grep eine Datei durchsuchen will. Keine Ahnung warum.
Ich glaube, dass ich das mal am Anfang irgendwo gelesen habe, und dann hat es sich ins Hirn eingebrannt.
*tsk* Ich glaub, wir muessen dich mal einer Gehirnwaesche unterziehen...
Drittens: Der sed-Befehl beinhaltet ein gewisses Risiko. Derzeit kommt "openwin" zwar nur einmal in /etc/profile vor, aber das könnte sich jederzeit ändern und Dein Befehl würde Mist bauen...
ACK. Sowas muss man sehr gut testen. Bzw. das Muster auf die komplette Zeile erweitern, und mittels ^ und $ verankern.
Da hast du natürlich auch recht. Allerdings habe ich vor auf die .local Dateien auszuweichen. Aber natürlich könnte auch da etwas mehrfach vorkommen. Man weiß ja nie, was ein gelangweilter Admin rumwerkelt. ;-)
Solltest du. s.o. und meine anderen Mails.
Ich habe mir überlegt, einfach nur diese Zeile in die /etc/profile.local einzufügen.
export PATH="$PATH:/opt/xfce4/bin"
Beim Löschen brauche ich dann nur nach exakt dieser Zeile zu suchen und kann die dann ohne Probleme löschen. Außer ich baue Mist beim Skript.
Jep. Besser waere aber u.U. ein wrapper-script in /usr/local/bin, das die diversen Variablen setzt und dann xfce aufruft (s.o.).
Viertens: statt /etc/profile.tmp solltest Du einen "unwahrscheinlicheren" Namen verwenden, z. B. /etc/profile.tmp_Name-deines-Pakets_irgendwas-kryptisches (für letzteres sollte das Abstauben der Tastatur reichen ;-) Die Optimallösung wäre übrigens die Verwendung von mktemp.
mktemp habe ich noch nie verwendet. Den ersten Zeilen der Manpage hört sich das aber recht interessant an.
s.o.
Wahr für wahr. *heul* Ich könnt immer noch wegen meiner ld.so.conf schreien.
Naja, die laesst sich ja wirklich einfach leicht wiederherstellen. Zur Not per rpm2cpio glibc-2...rpm | bunzip -c | cpio -i /etc/ld.so.conf (Disclaimer: die Syntax von cpio hab ich jetzt nicht im Kopf!) -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Am Do, 2004-04-29 um 02.31 schrieb David Haller:
Hallo,
Am Wed, 28 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 23.12 schrieb Christian Boltz:
Am Dienstag, 27. April 2004 18:33 schrieb Marcus Habermehl: [..] Was spricht dagegen? Anders gefragt: Über wie viele Symlinks reden wir? Einen? Zehn? Hundert?
Ich hatte hier einen WM, der hat fast zehn Dateien nach /usr/local/bin installiert. Bei XFce4 wird sich auch einiges ansammeln.
Mir geht es halt darum, dass ich gerne einheitliche spec Files hätte. Und bei manchen Paketen wäre das dann zu viele Links. Zumal ich die Variante mit $PATH doch stilvoller finde.
Irgendwo.
Find ich ok. Man muss halt einen Kompromiss zwischen symlinks und nem aufgeblaehten PATH finden. Ich finde, so ab 15-20 Dateien lohnt sich die Aufnahme in PATH.
Na, ja. Ich würde für mich die Zahl runter schrauben. Aber wegen zwei, drei Dateien wäre die Aufnahme in $PATH zu viel Arbeit. Finde ich.
Außer das Skript löscht die Datei, anstatt sie zu bearbeiten.
Das wäre natürlich der "worst case".
Ja. Vor allem dann, wenn es die /etc/ld.so.conf trifft. Wie bei mir vorhin.
Die ld.so.conf kann man ja nun wirklich einfach neu erstellen. Oder nachinstallieren. Oder sich eine mailen lassen.
Klar. In einer Minute war das erledigt. Aber es hätte auch eine andere Datei treffen können. Eine, in der 'ne Menge Konfig-Arbeit steckt.
Ich arbeite hier uebrigens lieber mit nem wrapper-script, dass dann LD_LIBRARY_PATH setzt, so z.B. fuer mein "sX" script (startX), das dann fuer WindowMaker (meinem normalen WM, sX wird dann als swmaker aufgerufen, oder auch als sX wmaker) folgendes macht:
[Skript entfernt]
Analoges mache ich auch mit anderen Sachen, sowas macht z.B. das Mozilla-Startscript, IIRC das startkde-script u.v.a.m...
So etwas in der Richtung steht noch in meiner TODO. Ich will nur nicht mit zu Vielem auf einmal anfangen. Das habe ich schon mal gemacht. Als Ergebnis hatte ich dann Skripte, die nicht so funktionierten, wie sie sollten. [...]
Da bin ich gerade dabei, Sicherungen einzubauen. Aber an meiner /etc/ld.so.conf (s. o.) sieht man, dass das noch nicht läuft. ;-)
==== CONFIG="/etc/foo"
TMPFILE="`mktemp \"/tmp/${CONFIG}.$$.XXXXXX\"`" || exit 1
trap rm -f "${TMPFILE}" 1 2 3 13 14 15 EXIT
sed 's/foo/bar/' < "$CONFIG" > "${TMPFILE}" \ && mv "${TMPFILE}" "${CONFIG}" ====
Das sollte hinreichend sicher sein.
Das muss ich erstmal auseinander nehmen, damit ich es auch wirklich verstehe. So im Überblick scheint das aber 1 A zu sein. Und vor allem kürzer, als meine bisherigen _Versuche_.
cat /etc/profile.tmp | sed '/openwin/ a\ /opt/xfce4/bin \\' > /etc/profile
Erstens: Useless use of cat!
Jetzt, wo du es sagst. Ich benutze aber immer cat. Auch wenn ich mit grep eine Datei durchsuchen will. Keine Ahnung warum.
Ich glaube, dass ich das mal am Anfang irgendwo gelesen habe, und dann hat es sich ins Hirn eingebrannt.
*tsk* Ich glaub, wir muessen dich mal einer Gehirnwaesche unterziehen...
Das wäre nicht schlecht. Habe es vor paar Minuten wieder gemacht. Und jedes mal fällt mir hinterher auf, dass es ja eigentlich doppelte und unnötige Arbeit ist. [...]
Ich habe mir überlegt, einfach nur diese Zeile in die /etc/profile.local einzufügen.
export PATH="$PATH:/opt/xfce4/bin"
Beim Löschen brauche ich dann nur nach exakt dieser Zeile zu suchen und kann die dann ohne Probleme löschen. Außer ich baue Mist beim Skript.
Jep. Besser waere aber u.U. ein wrapper-script in /usr/local/bin, das die diversen Variablen setzt und dann xfce aufruft (s.o.).
Wie oben schon gesagt. Steht noch auf meiner Liste. Nur halt nach und nach. Sonst kann ich nur viel ein wenig, anstatt wenig viel. Letztere Möglichkeit ist mir halt lieber. [...]
Wahr für wahr. *heul* Ich könnt immer noch wegen meiner ld.so.conf schreien.
Naja, die laesst sich ja wirklich einfach leicht wiederherstellen. Zur Not per rpm2cpio glibc-2...rpm | bunzip -c | cpio -i /etc/ld.so.conf
Wieso glibc-2? Wenn ich rpm -q --whatprovides /etc/ld.so.conf absetze, kommt aaa_base (warum heißt das überhaupt aaa?) heraus. Oder hat das eine ganz andere Funktion? Ich habe mir jetzt mit # find / -name lib -type d > /etc/ld.so.conf geholfen. Und dann ein paar unsinnige Verzeichnisse aus der Liste entfernt. Scheint auch okay gewesen zu sein. Bisher habe ich keine Fehlermeldungen oder ähnliches bekommen. Gruß Marcus
Hallo, Am Thu, 29 Apr 2004, Marcus Habermehl schrieb:
Am Do, 2004-04-29 um 02.31 schrieb David Haller:
Am Wed, 28 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 23.12 schrieb Christian Boltz:
Am Dienstag, 27. April 2004 18:33 schrieb Marcus Habermehl: [..] Find ich ok. Man muss halt einen Kompromiss zwischen symlinks und nem aufgeblaehten PATH finden. Ich finde, so ab 15-20 Dateien lohnt sich die Aufnahme in PATH.
Na, ja. Ich würde für mich die Zahl runter schrauben. Aber wegen zwei, drei Dateien wäre die Aufnahme in $PATH zu viel Arbeit. Finde ich.
Genau. V.a. wird der Pfad dann ewig lang.
Die ld.so.conf kann man ja nun wirklich einfach neu erstellen. Oder nachinstallieren. Oder sich eine mailen lassen.
Klar. In einer Minute war das erledigt. Aber es hätte auch eine andere Datei treffen können. Eine, in der 'ne Menge Konfig-Arbeit steckt.
Jep.
Ich arbeite hier uebrigens lieber mit nem wrapper-script, dass dann LD_LIBRARY_PATH setzt, so z.B. fuer mein "sX" script (startX), das dann fuer WindowMaker (meinem normalen WM, sX wird dann als swmaker aufgerufen, oder auch als sX wmaker) folgendes macht:
[Skript entfernt]
Analoges mache ich auch mit anderen Sachen, sowas macht z.B. das Mozilla-Startscript, IIRC das startkde-script u.v.a.m...
So etwas in der Richtung steht noch in meiner TODO. Ich will nur nicht mit zu Vielem auf einmal anfangen. Das habe ich schon mal gemacht. Als Ergebnis hatte ich dann Skripte, die nicht so funktionierten, wie sie sollten.
Hmja, da kommt's halt auf die allgemeinen shell-Kenntnisse an. Ich schreib sowas in ner Minute mal eben hin (wobei das war ja nur das Fragment fuer den (damals von mir kompilierten) neuen Windowmaker)... Fuer nen shell-Anfaenger ist sowas natuerlich eher muehsam. [..script..]]
Das sollte hinreichend sicher sein.
Das muss ich erstmal auseinander nehmen, damit ich es auch wirklich verstehe.
*g*
*tsk* Ich glaub, wir muessen dich mal einer Gehirnwaesche unterziehen...
Das wäre nicht schlecht. Habe es vor paar Minuten wieder gemacht. Und jedes mal fällt mir hinterher auf, dass es ja eigentlich doppelte und unnötige Arbeit ist.
ok *eg*
Jep. Besser waere aber u.U. ein wrapper-script in /usr/local/bin, das die diversen Variablen setzt und dann xfce aufruft (s.o.).
Wie oben schon gesagt. Steht noch auf meiner Liste. Nur halt nach und nach. Sonst kann ich nur viel ein wenig, anstatt wenig viel. Letztere Möglichkeit ist mir halt lieber.
Ich weiss halt nicht, was XFCE ausser PATH und LD_LIBRARY_PATH noch so braucht. Ansonsten ist dann ganz simpel: ==== /usr/local/bin/xfce4 ==== #!/bin/sh PATH="/opt/xfce4/bin:$PATH" LD_LIBRARY_PATH="/opt/xfce4/lib:$LD_LIBRARY_PATH" ### ':' am Anfang und Ende loeschen, ist aber kein "muss" PATH="`echo \"$PATH\" | sed 's/^://;s/:$//' LD_LIBRARY_PATH="`echo \"$LD_LIBRARY_PATH\" | sed 's/^://;s/:$//'" WINDOWMANAGER="/opt/xfce4/bin/xfce" ## oder wie das binary halt heisst export PATH LD_LIBRARY_PATH WINDOWMANAGER exec /usr/X11R6/bin/startx "$WINDOWMANAGER" -- "$@" 2>&1 | tee ~/.X.err ====
Wahr für wahr. *heul* Ich könnt immer noch wegen meiner ld.so.conf schreien.
Naja, die laesst sich ja wirklich einfach leicht wiederherstellen. Zur Not per rpm2cpio glibc-2...rpm | bunzip -c | cpio -i /etc/ld.so.conf
Wieso glibc-2? Wenn ich rpm -q --whatprovides /etc/ld.so.conf absetze,
rpm -qf /etc/ld.so.conf
kommt aaa_base (warum heißt das überhaupt aaa?) heraus.
Ups. Stimmt. Dann halt 'rpm2cpio aaa_base...rpm | ...' Das "aaa" ist AFAIR nur dazu da, dass das weit oben in der Liste steht.
Oder hat das eine ganz andere Funktion?
Noe.
Ich habe mir jetzt mit
# find / -name lib -type d > /etc/ld.so.conf
geholfen. Und dann ein paar unsinnige Verzeichnisse aus der Liste entfernt.
Jo, passt. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo. Am Do, 2004-04-29 um 22.21 schrieb David Haller:
Am Thu, 29 Apr 2004, Marcus Habermehl schrieb:
Am Do, 2004-04-29 um 02.31 schrieb David Haller:
Am Wed, 28 Apr 2004, Marcus Habermehl schrieb:
Am Di, 2004-04-27 um 23.12 schrieb Christian Boltz:
Am Dienstag, 27. April 2004 18:33 schrieb Marcus Habermehl:
[...]
Ich arbeite hier uebrigens lieber mit nem wrapper-script, dass dann LD_LIBRARY_PATH setzt, so z.B. fuer mein "sX" script (startX), das dann fuer WindowMaker (meinem normalen WM, sX wird dann als swmaker aufgerufen, oder auch als sX wmaker) folgendes macht:
[Skript entfernt]
Analoges mache ich auch mit anderen Sachen, sowas macht z.B. das Mozilla-Startscript, IIRC das startkde-script u.v.a.m...
So etwas in der Richtung steht noch in meiner TODO. Ich will nur nicht mit zu Vielem auf einmal anfangen. Das habe ich schon mal gemacht. Als Ergebnis hatte ich dann Skripte, die nicht so funktionierten, wie sie sollten.
Hmja, da kommt's halt auf die allgemeinen shell-Kenntnisse an. Ich schreib sowas in ner Minute mal eben hin (wobei das war ja nur das Fragment fuer den (damals von mir kompilierten) neuen Windowmaker)...
Fuer nen shell-Anfaenger ist sowas natuerlich eher muehsam.
Ich würde mich nicht unbedingt als Anfänger bezeichnen. Aber allzu weit bin ich auch noch nicht. Würde so sagen am Ende vom Anfang, vielleicht. Mit ein paar Minuten wäre es bei mir aber auf gar keinen Fall getan. Eher Stunden. [...]
Jep. Besser waere aber u.U. ein wrapper-script in /usr/local/bin, das die diversen Variablen setzt und dann xfce aufruft (s.o.).
Wie oben schon gesagt. Steht noch auf meiner Liste. Nur halt nach und nach. Sonst kann ich nur viel ein wenig, anstatt wenig viel. Letztere Möglichkeit ist mir halt lieber.
Ich weiss halt nicht, was XFCE ausser PATH und LD_LIBRARY_PATH noch so braucht. Ansonsten ist dann ganz simpel:
XFce4 hätte noch gerne PKG_CONFIG_PATH. Aber das wäre ja dann analog zu Zeile 2 und 3 da unten.
==== /usr/local/bin/xfce4 ==== #!/bin/sh PATH="/opt/xfce4/bin:$PATH" LD_LIBRARY_PATH="/opt/xfce4/lib:$LD_LIBRARY_PATH"
### ':' am Anfang und Ende loeschen, ist aber kein "muss" PATH="`echo \"$PATH\" | sed 's/^://;s/:$//' LD_LIBRARY_PATH="`echo \"$LD_LIBRARY_PATH\" | sed 's/^://;s/:$//'"
WINDOWMANAGER="/opt/xfce4/bin/xfce" ## oder wie das binary halt heisst
export PATH LD_LIBRARY_PATH WINDOWMANAGER
exec /usr/X11R6/bin/startx "$WINDOWMANAGER" -- "$@" 2>&1 | tee ~/.X.err ====
Mit exec und startx hätte ich jetzt nicht gearbeitet. Nach meinem Wissensstand hätte ich nur xfce4 eingetragen. Und die Übergabe der Kommandozeile and startx, bzw. xfce4 hätte ich auch weggelassen. Man merkt halt, dass ich noch nicht so weit bin. Auch wenn meine Skripte bisher funktionierten.
Wahr für wahr. *heul* Ich könnt immer noch wegen meiner ld.so.conf schreien.
Naja, die laesst sich ja wirklich einfach leicht wiederherstellen. Zur Not per rpm2cpio glibc-2...rpm | bunzip -c | cpio -i /etc/ld.so.conf
Wieso glibc-2? Wenn ich rpm -q --whatprovides /etc/ld.so.conf absetze,
rpm -qf /etc/ld.so.conf
kommt aaa_base (warum heißt das überhaupt aaa?) heraus.
Ups. Stimmt. Dann halt 'rpm2cpio aaa_base...rpm | ...'
Das "aaa" ist AFAIR nur dazu da, dass das weit oben in der Liste steht.
Hab ich mir schon gedacht. Bisher stand das Paket nur am Anfang, wenn ich 'rpm -qa | sort' abgesetzt habe. [...] Mittlerweile funktionieren meine %post und %postun Einträge. Allerdings habe ich auch den Prefix Eintrag in meinem spec File entfernt. Mein Problem war die Übertragen von %{prefix} auf $PATH und Co. Ich weiß nämlich nicht, ob das auch hinhauen würde, wenn man das RPM bei der Installation nach z. B. /usr/local installieren würde. Ich denke auch, dass ich mich zu sehr auf die Portierbarkeit konzentriert habe. Was ja eigentlich Schwachsinn ist. Ich erstelle die RPMs ja nur, damit ich nicht unkontrolliert Dateien ins System bringe, die ich dann vielleicht nie wieder vollständig entfernen kann. Im spec File teste ich jetzt nur, ob unter /etc profile[.local], [bash.]bashrc[.local] und ld.so.conf existieren, bevor ich in die Dateien hineinschreibe. Dafür, dass die RPMs eh auf meinem Rechner bleiben, ist das wohl eh noch unnötige Arbeit. Aber so habe ich Vorarbeit geleistet, falls ich die Specs mal an eine andere Distri anpassen will. Gruß Marcus
participants (5)
-
Christian Boltz -
David Haller -
Manfred Tremmel -
Marcus Habermehl -
Urs Schaffner