Wo werden Umgebungsvariablen gesetzt / Was sind die eigentlich genau? (7.2 Pro)
Soweit ich das verstanden habe sind Umgebungsvariablen bestimmte Variablen die beim Start eines Betriebssystems bestimmte Werte eingetragen bekommen, damit alles im OS diese nutzen kann um bestimmte Informationen bei Bedarf sofort zur Hand zu haben. So eine Art Laufzeit-"Registry", ähnlich wie z.B. bei Windoze9x. Stimmt das so ungefär? Wo werden diese bei Linux / bzw. SuSE Linux standardmäßig gesetzt? Gibt es da überhaupt Standards? /var vielleicht? Und kann es sein, daß Umgebungsvariablen an verschiedenen Stellen zu verschiedenen Anlässen gesetzt werden? Wie handhabt Ihr das mit den Umgebungsvariablen? (Nur zur Erklärung:Anlaß für diese allgemeine Frage ist u.a. gerade diese Fehlermeldung / Warnung die ich krieg, wenn ich ein Javaprogramm starten will
Warning: JAVA_HOME environment variable not set.)
Moin,
* Phillip Richdale
Soweit ich das verstanden habe sind Umgebungsvariablen bestimmte Variablen die beim Start eines Betriebssystems bestimmte Werte eingetragen bekommen, damit alles im OS diese nutzen kann um bestimmte Informationen bei Bedarf sofort zur Hand zu haben. So eine Art Laufzeit-"Registry", ähnlich wie z.B. bei Windoze9x. Stimmt das so ungefär? Nein. Die Dinger liegen in der 'Umgebung' ('nen besseren Namen kenne ich nicht) und können für jeden Prozeß anders aussehen. Einige Prozesse begrenzen sie sogar absichtlich, such mal in den Manpages nach 'restricted shell'.
Darüber gibt's bestimmt ein Kapitel im Kofler.
Wo werden diese bei Linux / bzw. SuSE Linux standardmäßig gesetzt? In /etc/profiles stehen einige, in Deinen Startdateien (~/.bashrc, ~/.zshrc, ~/.profile) stehen eingige weitere.
Gibt es da überhaupt Standards? Deine Shell hat einige (mehr oder weniger) unveränderliche Startdateien. Siehe 'man <shell>'.
/var vielleicht? Hat damit nichts zu tun.
Und kann es sein, daß Umgebungsvariablen an verschiedenen Stellen zu verschiedenen Anlässen gesetzt werden? Auf jeden Fall.
Wie handhabt Ihr das mit den Umgebungsvariablen? Ganz spitzenmäßig. In welchem Zusammenhang?
(Nur zur Erklärung:Anlaß für diese allgemeine Frage ist u.a. gerade diese Fehlermeldung / Warnung die ich krieg, wenn ich ein Javaprogramm starten will
Warning: JAVA_HOME environment variable not set.) Java kennt keine Umgebungsvariablen. Wahrscheinlich tritt der Fehler im Shellskript auf, da hättest Du mal 'reinsehen sollen.
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Nein. Die Dinger liegen in der 'Umgebung' ('nen besseren Namen kenne ich nicht) und können für jeden Prozeß anders aussehen. Einige Prozesse begrenzen sie sogar absichtlich, such mal in den Manpages nach 'restricted shell'.
Darüber gibt's bestimmt ein Kapitel im Kofler.
Den Koffler hab' ich nicht (mehr). Aber Danke für den 'restricted shell' Tip.
* Thorsten Haude schrieb am 04.Nov.2001:
Java kennt keine Umgebungsvariablen. Wahrscheinlich tritt der Fehler im Shellskript auf, da hättest Du mal 'reinsehen sollen.
Ich kenn mich mit Java nicht so sehr aus, bin mir aber sicher, daß auch Java Umgebungsvariablen kennt. Bei C stehen die Umgebungsvariablen im dritten Argument von main. main ist wie folgt definiert: int main (const int argc, const char **argv, const char **env); Dabei ist argc der Argumentenzähler, argv ist ein Zeiger auf die Argumente, und env ist ein Zeiger auf die Environmentvariablen, sie liegen in der Form "NAME=Wert" vor. Ich schätze mal, bei java ist das nicht anders. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Moin,
* Bernd Brodesser
int main (const int argc, const char **argv, const char **env); Das ist kein ISO-C.
Ich schätze mal, bei java ist das nicht anders. Das ist nicht das einzige, das bei Java anders ist als bei C.
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
* Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:55]: int main (const int argc, const char **argv, const char **env); Das ist kein ISO-C.
Das ist POSIX und es ist auch K&R, wenn man mal von const absieht, das es bei K&R nicht gibt.
Ich schätze mal, bei java ist das nicht anders. Das ist nicht das einzige, das bei Java anders ist als bei C.
Mag sein, aber sicherlich kann man mit Java das Enviroment verändern. Bernd -- Bei Fragen an die Liste erst mal nachschauen, ob es diese Frage nicht schon einmal gegeben hat. Ein Archiv der Liste findest Du auf: http://lists.suse.com/archives/suse-linux |Zufallssignatur 7
Moin,
* Bernd Brodesser
* Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:55]: int main (const int argc, const char **argv, const char **env); Das ist kein ISO-C. Das ist POSIX und es ist auch K&R, wenn man mal von const absieht, das es bei K&R nicht gibt. Schön, daß es immerhin Standards gibt, die es enthalten. Ich verzichte gerne auf nicht-ISO-Features.
Ich schätze mal, bei java ist das nicht anders. Das ist nicht das einzige, das bei Java anders ist als bei C. Mag sein, aber sicherlich kann man mit Java das Enviroment verändern. Ich denke nicht, und wenn doch, dann wär's ein Bug. Wie sollen solche Programme auf Plattformen laufen, die kein Environment haben? (Vermutlich wird aus dem gleichen Grund in ISO-C darauf verzichtet.)
Normalerweise wird die Übersetzung eben in Shellskripten gemacht, mit java -Ddings=$DINGS programm Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
* Thorsten Haude schrieb am 05.Nov.2001:
* Bernd Brodesser
[01-11-04 23:35]: * Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:55]: int main (const int argc, const char **argv, const char **env); Das ist kein ISO-C. Das ist POSIX und es ist auch K&R, wenn man mal von const absieht, das es bei K&R nicht gibt. Schön, daß es immerhin Standards gibt, die es enthalten. Ich verzichte gerne auf nicht-ISO-Features.
Das sind Untemengen von ISO. Alles was POSIX ist ist AFAIK auch ISO. Es gibt keine andere Möglichkeit an die Umgebungsvariablen zu kommen, es sei den, man verwendet Routienen, die ihrerseits das dritte Argument von main auswerten.
Ich schätze mal, bei java ist das nicht anders. Das ist nicht das einzige, das bei Java anders ist als bei C. Mag sein, aber sicherlich kann man mit Java das Enviroment verändern. Ich denke nicht, und wenn doch, dann wär's ein Bug. Wie sollen solche Programme auf Plattformen laufen, die kein Environment haben? (Vermutlich wird aus dem gleichen Grund in ISO-C darauf verzichtet.)
Und wie soll bash programmiert sein? Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Am Mon, 2001-11-05 um 11.14 schrieb Bernd Brodesser:
* Thorsten Haude schrieb am 05.Nov.2001:
* Bernd Brodesser
[01-11-04 23:35]: * Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:55]: int main (const int argc, const char **argv, const char **env); Das ist kein ISO-C. Das ist POSIX und es ist auch K&R, wenn man mal von const absieht, das es bei K&R nicht gibt. Schön, daß es immerhin Standards gibt, die es enthalten. Ich verzichte gerne auf nicht-ISO-Features.
Das sind Untemengen von ISO. Alles was POSIX ist ist AFAIK auch ISO. Es gibt keine andere Möglichkeit an die Umgebungsvariablen zu kommen, es sei den, man verwendet Routienen, die ihrerseits das dritte Argument von main auswerten.
man 3 getenv Beachte: .. CONFORMING TO SVID 3, POSIX, BSD 4.3, ISO 9899 .. Vgl auch man 3 setenv man 5 environ Um aber auf die Ausgangsfrage zurückzukommen, Umgebungsvariablen werden meist vom Start-Upcode eines Programmes, meist in Zusammenarbeit mit der libc des Systems, eines Programmes aus der Umgebung ihres Elternprozesses zusammengesucht ("vererbt") und in ein globales Array eingefügt. Dieses Array wird dann meist als 3. Argument an main() übergeben. getenv|setenv und Co. greifen dann über die libc (getenv etc. sind Teil der libc) auf dieses globale Array zu. Ob und wie die Argumente von main() implementiert sind ist dabei ganz entscheidend vom Startup-Code abhängig. Auf Embedded Systemen z.B. findet man dort oft main( 0, 0, 0 ), main(0,0) oder gar main(). Ralf
Moin,
* Bernd Brodesser
* Thorsten Haude schrieb am 05.Nov.2001:
* Bernd Brodesser
[01-11-04 23:35]: * Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:55]: int main (const int argc, const char **argv, const char **env); Das ist kein ISO-C. Das ist POSIX und es ist auch K&R, wenn man mal von const absieht, das es bei K&R nicht gibt. Schön, daß es immerhin Standards gibt, die es enthalten. Ich verzichte gerne auf nicht-ISO-Features. Das sind Untemengen von ISO. Alles was POSIX ist ist AFAIK auch ISO. Sorry, in 'C:A Reference Manual' steht, daß es kein Bestandteil von ISO-C ist, und ich eher geneigt, den Autoren zu glauben.
Es gibt keine andere Möglichkeit an die Umgebungsvariablen zu kommen, es sei den, man verwendet Routienen, die ihrerseits das dritte Argument von main auswerten. In ISO-C wird man das mit Librarycalls machen. Die sind aber plattformspezifisch, genauso wie Umgebungsvariablen. Wie die Libraries die Umgebungsvariable ermitteln, spielt letztendlich keine Rolle, aber ich wäre überrascht, wenn sie das (ggf. nicht existente) dritte Argument auswerten. Dieses dritte Argument ist nur eine Schnittstelle zur Umgebung.
Ich schätze mal, bei java ist das nicht anders. Das ist nicht das einzige, das bei Java anders ist als bei C. Mag sein, aber sicherlich kann man mit Java das Enviroment verändern. Ich denke nicht, und wenn doch, dann wär's ein Bug. Wie sollen solche Programme auf Plattformen laufen, die kein Environment haben? (Vermutlich wird aus dem gleichen Grund in ISO-C darauf verzichtet.) Und wie soll bash programmiert sein? Was hat das damit zu tun? Das Environment ist halt ein Feature, das man nicht vorraussetzen sollte, wenn man wirklich plattformunabhängig programmieren will. Die Bash läuft dann vielleicht nur auf Plattformen mit Environment, ich weiß es nicht.
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
* Thorsten Haude schrieb am 05.Nov.2001:
* Bernd Brodesser
[01-11-05 11:14]: * Thorsten Haude schrieb am 05.Nov.2001:
Schön, daß es immerhin Standards gibt, die es enthalten. Ich verzichte gerne auf nicht-ISO-Features.
Das sind Untemengen von ISO. Alles was POSIX ist ist AFAIK auch ISO.
Sorry, in 'C:A Reference Manual' steht, daß es kein Bestandteil von ISO-C ist, und ich eher geneigt, den Autoren zu glauben.
Was ist C:A Reference Manual? Was meinst Du, was ist kein Bestandteil von ISO-C? POSIX, oder das dritte Argument von main? Ich kenne nur eine Menge Leute, denen es wichtig ist, daß ihr C-Program POSIX konform ist. Bisher hatten alle Normen, die ich kenne zumindest den Umfang von K&R. Lediglich ein paar Sachen sind veraltert.
Es gibt keine andere Möglichkeit an die Umgebungsvariablen zu kommen, es sei den, man verwendet Routienen, die ihrerseits das dritte Argument von main auswerten.
In ISO-C wird man das mit Librarycalls machen. Die sind aber plattformspezifisch, genauso wie Umgebungsvariablen.
Wie willst Du ein UNIX ohne Umgebungsvariable betreiben?
Wie die Libraries die Umgebungsvariable ermitteln, spielt letztendlich keine Rolle, aber ich wäre überrascht, wenn sie das (ggf. nicht existente) dritte Argument auswerten. Dieses dritte Argument ist nur eine Schnittstelle zur Umgebung.
Wie sollen sie denn sonst an der Umgebung kommen?
Ich denke nicht, und wenn doch, dann wär's ein Bug. Wie sollen solche Programme auf Plattformen laufen, die kein Environment haben? (Vermutlich wird aus dem gleichen Grund in ISO-C darauf verzichtet.)
Und wie soll bash programmiert sein?
Was hat das damit zu tun? Das Environment ist halt ein Feature, das man
Die bash ist doch auch in C programmiert, oder etwa nicht?
nicht vorraussetzen sollte, wenn man wirklich plattformunabhängig programmieren will. Die Bash läuft dann vielleicht nur auf Plattformen mit Environment, ich weiß es nicht.
Welche Plattform hat den kein Enviroment? Ich kenne kein UNIX, daß das nicht hat, und DOS und OS/2 haben soviel ich weiß auch so was wie Umgebungsvariablen. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: http://localhost/doc/sdb/de/html/index.html | mit Apache: http://localhost/doc/sdb/de/html/key_form.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2
Moin,
* Bernd Brodesser
* Thorsten Haude schrieb am 05.Nov.2001:
* Bernd Brodesser
[01-11-05 11:14]: * Thorsten Haude schrieb am 05.Nov.2001:
Schön, daß es immerhin Standards gibt, die es enthalten. Ich verzichte gerne auf nicht-ISO-Features. Das sind Untemengen von ISO. Alles was POSIX ist ist AFAIK auch ISO. Sorry, in 'C:A Reference Manual' steht, daß es kein Bestandteil von ISO-C ist, und ich eher geneigt, den Autoren zu glauben. Was ist C:A Reference Manual? Ein Buch mit mehr Antworten über C als wir beide zusammen jemals brauchen werden.
Was meinst Du, was ist kein Bestandteil von ISO-C? POSIX, oder das dritte Argument von main? Das dritte Argument.
Ich kenne nur eine Menge Leute, denen es wichtig ist, daß ihr C-Program POSIX konform ist. OK. Das ist auch ein großer Markt, in diesem Fall macht die Einschränkung aber Sinn, zur Begründung siehe Java.
Es gibt keine andere Möglichkeit an die Umgebungsvariablen zu kommen, es sei den, man verwendet Routienen, die ihrerseits das dritte Argument von main auswerten. In ISO-C wird man das mit Librarycalls machen. Die sind aber plattformspezifisch, genauso wie Umgebungsvariablen. Wie willst Du ein UNIX ohne Umgebungsvariable betreiben? Ist UNIX die einzige Plattform? Gibt es C nur für UNIX?
Wie die Libraries die Umgebungsvariable ermitteln, spielt letztendlich keine Rolle, aber ich wäre überrascht, wenn sie das (ggf. nicht existente) dritte Argument auswerten. Dieses dritte Argument ist nur eine Schnittstelle zur Umgebung. Wie sollen sie denn sonst an der Umgebung kommen? Keine Ahnung.
Ich denke nicht, und wenn doch, dann wär's ein Bug. Wie sollen solche Programme auf Plattformen laufen, die kein Environment haben? (Vermutlich wird aus dem gleichen Grund in ISO-C darauf verzichtet.) Und wie soll bash programmiert sein? Was hat das damit zu tun? Das Environment ist halt ein Feature, das man Die bash ist doch auch in C programmiert, oder etwa nicht? Vermutlich. Jetzt wäre noch interessant, ob es POSIX oder ISO-C ist.
nicht vorraussetzen sollte, wenn man wirklich plattformunabhängig programmieren will. Die Bash läuft dann vielleicht nur auf Plattformen mit Environment, ich weiß es nicht. Welche Plattform hat den kein Enviroment? PalmOS, AFAIK.
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
On Sunday 04 November 2001 12:21, Phillip Richdale wrote:
Soweit ich das verstanden habe sind Umgebungsvariablen bestimmte Variablen die beim Start eines Betriebssystems bestimmte Werte eingetragen bekommen, damit alles im OS diese nutzen kann um bestimmte Informationen bei Bedarf sofort zur Hand zu haben. So eine Art Laufzeit-"Registry", ähnlich wie z.B. bei Windoze9x. Stimmt das so ungefär?
Auch bei Windows gibt es Umgebungsvariablen, die mit SET [Variable]=[Wert] gesetzt werden koennen. Der Vergleich mit der "Laufgzeit-Registry" hinkt ein wenig.
Wo werden diese bei Linux / bzw. SuSE Linux standardmäßig gesetzt? Gibt es da überhaupt Standards?
Grundsaetzlich haengt dies von der Anwendung der Varaiblen ab. Sollen Varaiblen fuer alle User eines Systems gesetzt werden, kann man in /etc/profile.local die entsprechenden Eintraege setzen. Soll nur ein bestimmter User Variablen erhalten, so sollte man sie in ~/.bashrc setzen, sofern bash eingesetzt wird.
/var vielleicht? Und kann es sein, daß Umgebungsvariablen an verschiedenen Stellen zu verschiedenen Anlässen gesetzt werden?
siehe oben.
Wie handhabt Ihr das mit den Umgebungsvariablen?
(Nur zur Erklärung:Anlaß für diese allgemeine Frage ist u.a. gerade diese Fehlermeldung / Warnung die ich krieg, wenn ich ein Javaprogramm starten will
Warning: JAVA_HOME environment variable not set.)
Diese Varaible traegst Du in die ~/.bashrc ein. Das sollte funktionieren.
Bye,
Steve.
--
Steve Graegert
Moin,
* Steve Graegert
On Sunday 04 November 2001 12:21, Phillip Richdale wrote:
Warning: JAVA_HOME environment variable not set.) Diese Varaible traegst Du in die ~/.bashrc ein. Das sollte funktionieren. Und zwar so: export JAVA_HOME=/dein/pfad/zu/java
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
* Phillip Richdale schrieb am 04.Nov.2001:
Soweit ich das verstanden habe sind Umgebungsvariablen bestimmte Variablen die beim Start eines Betriebssystems bestimmte Werte eingetragen bekommen, damit alles im OS diese nutzen kann um bestimmte Informationen bei Bedarf sofort zur Hand zu haben.
So ungefähr, aber nicht nur beim Start des Systems, sondern auch beim Einloggen, was ja ein großer Unterschied ist. Es können mehere Personen gleichzeitig eigeloggt sein und sie können sich auch wieder ausloggen, ohne den Rechner runter zu fahren. Jeder Prozeß hat Umgebungsvariable. Nach dem Systemstart wird als erster Prozeß vom Kernel der Prozeß init gestartet. Dabei werden schon die ersten Variablen gesetzt. Welche das sind, siehst Du wenn Du less /proc/1/environ sagst, natürlich als root. In /proc/1 steht alles interessante zu Prozeß 1 und das ist immer init. Unter anderem das Enviroment, die Umgebung. Bei den anderen Prozessen ist es ähnlich, die Umgebung findest Du unter /proc/PID/environ, wobei PID für die jeweilige Prozeßnummer steht. So zurück zu init. init führt jetzt verschieden Prozesse nach der /etc/inittab aus. Unter anderem auch die mingettys. Dort wird dann nach dem Login, gemäß der /etc/passwd verschiedene Variablen gesetzt, etwa $HOME. Dann wird /etc/passwd, bei SuSE /etc/passwd.local, ~/.bashrc ausgeführt. Hier kann überall neue Umgebungsvariablen gesetzt werden. Wichtig ist, jeder Prozeß hat wie gesagt seine eigene Umgebungsvariablen. Wenn ein Prozeß einen neuen aufruft, so geschieht dies über ein fork. Ein fork macht eine exakte Kopie vom alten Prozeß, der neue Prozeß bekommt lediglich eine neue PID und als PPID bekommt er die PID des alten Prozeß, der alte Prozeß wird damit zum Elterprozeß des neuen, und der neue wird zu einem Kindprozeß des alten. Die Umgebungsvariablen bleiben gleich, mit gleichem Inhalt. In der Regel führt der neue Prozeß nun ein exec... aus. Dadurch wird er mit einem anderen Programm überschrieben, aber die Umgebungsvariablen bleiben erst mal gleich. Das Programm kann nattürlich neue hinzufügen, oder alte verändern oder auch wegnehmen. Auch die Shell ist ein solches Programm. Wichtig ist, daß ein Prozeß immer nur seine eigene Umgebungsvariablen verändern kann, nie das eines anderen Prozesses. Er kann es lediglich an spätere Kindeprozesse vererben. Nicht aber an solche, die es schon gibt.
So eine Art Laufzeit-"Registry", ähnlich wie z.B. bei Windoze9x.
Glaube ich nicht, aber keine Ahnung von Windows.
Wo werden diese bei Linux / bzw. SuSE Linux standardmäßig gesetzt?
Wie gesagt, bei der bash ist es /etc/profile.local und ~/.bashrc. Bei der 7.2 scheint es auch ein /etc/bashrc oder so zu geben, kann ich nichts zu sagen, da ich die 7.2 nicht habe.
Gibt es da überhaupt Standards? /var vielleicht?
Ganz bestimmt nicht. Wie gesagt, jeder Prozeß hat seine eigene Umgebungsvariablen. Bei Dämonen werden sie in den Startskripten gesetzt.
Und kann es sein, daß Umgebungsvariablen an verschiedenen Stellen zu verschiedenen Anlässen gesetzt werden?
Ja.
Wie handhabt Ihr das mit den Umgebungsvariablen?
(Nur zur Erklärung:Anlaß für diese allgemeine Frage ist u.a. gerade diese Fehlermeldung / Warnung die ich krieg, wenn ich ein Javaprogramm starten will
Warning: JAVA_HOME environment variable not set.)
Du startest dieses Javaprogramm ja aus der bash heraus oder aus X. Wenn Du es aus einer bash heraus startest, dann mußt Du es im ~/.bashrc schreiben und exportieren, sonst wird es keine Umgebungsvariable. Für X gibt es die Datei ~/.xsession wo man Umgebungsvariablen setzen kann. In der crontab kann man Umgebungsvariable für cronprozesse setzen und an vielen andern Orten. Über /proc/PID/environ kann man übrigens nichts setzen, da kann man nur lesen. /proc ist keine echte Datei, sondern hier sind spezielle Inahlte des Hauptspeichers. Bernd -- Bitte die Etikette beachten: http://home.t-online.de/~f.walle/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Bernd Brodesser wrote: : [...]
So zurück zu init. init führt jetzt verschieden Prozesse nach der /etc/inittab aus. Unter anderem auch die mingettys. Dort wird dann nach dem Login, gemäß der /etc/passwd verschiedene Variablen gesetzt, etwa $HOME. Dann wird /etc/passwd, bei SuSE ^^^^^^^^^^^ /etc/passwd.local, ~/.bashrc ausgeführt. Hier kann überall neue ^^^^^^^^^^^^^^^^^ Umgebungsvariablen gesetzt werden.
Das sollte /etc/profile bzw. /etc/profile.local heissen. Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe
* Thomas Hertweck schrieb am 04.Nov.2001:
Bernd Brodesser wrote: : [...]
So zurück zu init. init führt jetzt verschieden Prozesse nach der /etc/inittab aus. Unter anderem auch die mingettys. Dort wird dann nach dem Login, gemäß der /etc/passwd verschiedene Variablen gesetzt, etwa $HOME. Dann wird /etc/passwd, bei SuSE ^^^^^^^^^^^ /etc/passwd.local, ~/.bashrc ausgeführt. Hier kann überall neue ^^^^^^^^^^^^^^^^^ Umgebungsvariablen gesetzt werden.
Das sollte /etc/profile bzw. /etc/profile.local heissen.
Ja. Jetzt ist es passiert. Ich verwechsle das ständig. Fängt beides mit p an, weiß auch nicht warum. Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
Moin,
* Bernd Brodesser
In /proc/1 steht alles interessante zu Prozeß 1 und das ist immer init. Off-topic: Hat init bei OpenBSD auch immer PID 1?
So zurück zu init. init führt jetzt verschieden Prozesse nach der /etc/inittab aus. Unter anderem auch die mingettys. Dort wird dann nach dem Login, gemäß der /etc/passwd verschiedene Variablen gesetzt, etwa $HOME. Dann wird /etc/passwd, bei SuSE /etc/passwd.local, ~/.bashrc ausgeführt. Hier kann überall neue Umgebungsvariablen gesetzt werden. Ich denke doch, daß diese Dinger von der Shell gelesen werden, oder täusche ich mich da?
Wenn Du es aus einer bash heraus startest, dann mußt Du es im ~/.bashrc schreiben und exportieren, sonst wird es keine Umgebungsvariable. 'DINGS=BUMS; javaprogram' sollte auch gehen, oder?
Für X gibt es die Datei ~/.xsession wo man Umgebungsvariablen setzen kann. Huh? Kenne ich nicht, ich benutze die ~/.xinitrc.
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Hallo Thorsten,
From the keyboard of Thorsten,
Moin,
* Bernd Brodesser
[01-11-04 14:33]: In /proc/1 steht alles interessante zu Prozeß 1 und das ist immer init. Off-topic: Hat init bei OpenBSD auch immer PID 1?
Ja. uname -a OpenBSD bsdwall 3.0 GENERIC#80 i386 ps auxw|grep init root 1 0.0 0.2 340 80 ?? Is Thu01AM 0:00.37 /sbin/init bye Waldemar
* Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:33]:
In /proc/1 steht alles interessante zu Prozeß 1 und das ist immer init.
Off-topic: Hat init bei OpenBSD auch immer PID 1?
Ich kenne OpenBSD nicht, würde mich aber schwer wundern, wenn nicht.
So zurück zu init. init führt jetzt verschieden Prozesse nach der /etc/inittab aus. Unter anderem auch die mingettys. Dort wird dann nach dem Login, gemäß der /etc/passwd verschiedene Variablen gesetzt, etwa $HOME. Dann wird /etc/passwd, bei SuSE /etc/passwd.local, ~/.bashrc ausgeführt. Hier kann überall neue Umgebungsvariablen gesetzt werden. Ich denke doch, daß diese Dinger von der Shell gelesen werden, oder täusche ich mich da?
Ich meinte natürlich /etc/profile und /etc/profile.local. Sorry. Allerdings das erste /etc/passwd ist richtig.
Wenn Du es aus einer bash heraus startest, dann mußt Du es im ~/.bashrc schreiben und exportieren, sonst wird es keine Umgebungsvariable.
'DINGS=BUMS; javaprogram' sollte auch gehen, oder?
Wie gesagt, jeder Prozeß hat seine eigene Umgebung.
Für X gibt es die Datei ~/.xsession wo man Umgebungsvariablen setzen kann. Huh? Kenne ich nicht, ich benutze die ~/.xinitrc.
Ehrlich gesagt, mit X kenne ich mich nicht sonderlich gut aus. Weiß jetzt auch nicht, was was aufruft. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Am Son, 04 Nov 2001 schrieb Bernd Brodesser:
* Thorsten Haude schrieb am 04.Nov.2001:
* Bernd Brodesser
[01-11-04 14:33]: Wenn Du es aus einer bash heraus startest, dann mußt Du es im ~/.bashrc schreiben und exportieren, sonst wird es keine Umgebungsvariable.
'DINGS=BUMS; javaprogram' sollte auch gehen, oder?
Wie gesagt, jeder Prozeß hat seine eigene Umgebung.
Ja, aber DINGS=BUMS javaprogram müßte gehen.
Für X gibt es die Datei ~/.xsession wo man Umgebungsvariablen setzen kann. Huh? Kenne ich nicht, ich benutze die ~/.xinitrc.
Ehrlich gesagt, mit X kenne ich mich nicht sonderlich gut aus. Weiß jetzt auch nicht, was was aufruft.
.xsession ruft .xinitrc auf (wird nicht eingelesen, sondern mit exec aufgerufen) In .xinitrc starte ich dann z.B. Programme, die den NumLock anschalten etc. Am Ende von .xinitrc wird $WINDOWMANAGER ausgeführt. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
* Christoph Maurer schrieb am 05.Nov.2001:
Ja, aber DINGS=BUMS javaprogram müßte gehen.
Was ist damit gemeint? Wo soll das stehen? In einem Javaprogram? Da steht doch nicht javaprogram. Oder einfach nur DINGS=BUMS? Nein, das ist denn nur eine einfache Variable, die aber deklariert werden müßte.
.xsession ruft .xinitrc auf (wird nicht eingelesen, sondern mit exec aufgerufen) In .xinitrc starte ich dann z.B. Programme, die den NumLock anschalten etc. Am Ende von .xinitrc wird $WINDOWMANAGER ausgeführt.
Ah, ha. Und da kann man dann auch Umgebungsvariable definieren. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
Am Mon, 05 Nov 2001 schrieb Bernd Brodesser:
* Christoph Maurer schrieb am 05.Nov.2001:
Ja, aber DINGS=BUMS javaprogram müßte gehen.
Was ist damit gemeint? Wo soll das stehen? In einem Javaprogram? Da steht doch nicht javaprogram. Oder einfach nur DINGS=BUMS? Nein, das ist denn nur eine einfache Variable, die aber deklariert werden müßte.
Es geht doch darum, ein Java-Programm mit einer bestimmten Umgebungsvariable auf einen speziellen Wert gesetzt auszuführen, oder? Bin etwas spät in den Thread eingestiegen. Und wenn ich eine Variable für genau einen Programmaufruf definieren will, kann ich das mit Variable=Wert Programm machen. Oder reden wir über verschiedene Dinge...
.xsession ruft .xinitrc auf (wird nicht eingelesen, sondern mit exec aufgerufen) In .xinitrc starte ich dann z.B. Programme, die den NumLock anschalten etc. Am Ende von .xinitrc wird $WINDOWMANAGER ausgeführt.
Ah, ha. Und da kann man dann auch Umgebungsvariable definieren.
Ja. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
* Christoph Maurer schrieb am 05.Nov.2001:
Am Mon, 05 Nov 2001 schrieb Bernd Brodesser:
* Christoph Maurer schrieb am 05.Nov.2001:
Ja, aber DINGS=BUMS javaprogram müßte gehen.
Was ist damit gemeint? Wo soll das stehen? In einem Javaprogram? Da steht doch nicht javaprogram. Oder einfach nur DINGS=BUMS? Nein, das ist denn nur eine einfache Variable, die aber deklariert werden müßte.
Es geht doch darum, ein Java-Programm mit einer bestimmten Umgebungsvariable auf einen speziellen Wert gesetzt auszuführen, oder? Bin etwas spät in den Thread eingestiegen. Und wenn ich eine Variable für genau einen Programmaufruf definieren will, kann ich das mit Variable=Wert Programm machen. Oder reden wir über verschiedene Dinge...
Ich denke, die Rede ist von einem Javaquelltext. Java ist doch eine Objektorientierte Sprache. Da müssen Variable doch einem Objekt zugeordnet werden, oder? Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: http://localhost/doc/sdb/de/html/index.html | mit Apache: http://localhost/doc/sdb/de/html/key_form.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2
Moin,
* Bernd Brodesser
Ich denke, die Rede ist von einem Javaquelltext. Java ist doch eine Objektorientierte Sprache. Da müssen Variable doch einem Objekt zugeordnet werden, oder? Es gibt auch Primitive, aber das hat mit Umgebungsvariablen nichts zu tun. Das Problem ist nur, daß man darauf nicht zugreifen kann.
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Am Mon, 05 Nov 2001 schrieb Bernd Brodesser:
* Christoph Maurer schrieb am 05.Nov.2001:
Am Mon, 05 Nov 2001 schrieb Bernd Brodesser:
* Christoph Maurer schrieb am 05.Nov.2001:
Ja, aber DINGS=BUMS javaprogram müßte gehen.
Was ist damit gemeint? Wo soll das stehen? In einem Javaprogram? Da steht doch nicht javaprogram. Oder einfach nur DINGS=BUMS? Nein, das ist denn nur eine einfache Variable, die aber deklariert werden müßte.
Es geht doch darum, ein Java-Programm mit einer bestimmten Umgebungsvariable auf einen speziellen Wert gesetzt auszuführen, oder? Bin etwas spät in den Thread eingestiegen. Und wenn ich eine Variable für genau einen Programmaufruf definieren will, kann ich das mit Variable=Wert Programm machen. Oder reden wir über verschiedene Dinge...
Ich denke, die Rede ist von einem Javaquelltext. Java ist doch eine Objektorientierte Sprache. Da müssen Variable doch einem Objekt zugeordnet werden, oder?
Okay, dann nehme ich alles zurück und gebe Dir vollkommen recht. Hatte den Kontext falsch verstanden ... -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On 05-Nov-2001 Christoph Maurer wrote:
Und wenn ich eine Variable für genau einen Programmaufruf definieren will, kann ich das mit Variable=Wert Programm machen. Oder reden wir über verschiedene Dinge...
Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und
"export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier
etwas?
Gruss,
Heinz.
--
E-Mail: Heinz W. Pahlke
Moin, * Heinz W. Pahlke[01-11-05 12:02]: >On 05-Nov-2001 Christoph Maurer wrote: >> Und wenn ich eine Variable für genau einen Programmaufruf definieren >> will, kann ich das mit >> Variable=Wert Programm >> machen. Oder reden wir über verschiedene Dinge... >Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und >"export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier >etwas? - Bei KDE wäre ich grundsätzlich vorsichtig. - Da fehlt ein Semikolon: - - - hde@acp1130> echo $SHELL /usr/bin/zsh hde@acp1130> SHELL=/bin/bash echo $SHELL /usr/bin/zsh hde@acp1130> SHELL=/bin/bash; echo $SHELL /bin/bash - - - Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Am Mon, 05 Nov 2001 schrieb Thorsten Haude: > Moin, > > * Heinz W. Pahlke[01-11-05 12:02]: > >On 05-Nov-2001 Christoph Maurer wrote: > >> Und wenn ich eine Variable für genau einen Programmaufruf definieren > >> will, kann ich das mit > >> Variable=Wert Programm > >> machen. Oder reden wir über verschiedene Dinge... > >Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und > >"export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier > >etwas? > - Bei KDE wäre ich grundsätzlich vorsichtig. Nein, dazu besteht kein Grund, nur muß man neben KDEDIR auch QTDIR und evtl KDEHOME umsetzen. > - Da fehlt ein Semikolon: Nein. Teste mal MAIL=/home/hde/Mail xterm Und in dem xterm dann echo $MAIL und MAIL=/home/hde/nsmail xterm Und in dem xterm dann wieder echo $MAIL Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin,
* Christoph Maurer
Teste mal MAIL=/home/hde/Mail xterm Und in dem xterm dann echo $MAIL und MAIL=/home/hde/nsmail xterm Und in dem xterm dann wieder echo $MAIL Hm. 'MAIL=/home/putt/Mail; xterm' funktioniert auch, warum klappt es ohne Semikolon mit $SHELL nicht?
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
On 05-Nov-2001 Christoph Maurer wrote:
Und wenn ich eine Variable für genau einen Programmaufruf definieren will, kann ich das mit Variable=Wert Programm machen. Oder reden wir über verschiedene Dinge...
Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und "export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier etwas?
Im ersten Fall brauchst Du kein export Aber wenn Du ein KDE1-Programm in seiner korrekten Umgebung ausführen willst, dann mache mal QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm Damit werden die Variablen nur für diesen Programmaufruf gesetzt, die Umgebung der Shell, von der Du den Befehl absetzt, bleibt unverändert. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin,
* Christoph Maurer
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und "export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier etwas? Im ersten Fall brauchst Du kein export Ich würde sogar sagen: Es sollte unbedingt vermieden werden.
QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm Warum klappt das bei meinem Shellbeispiel nicht?
Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Am Mon, 05 Nov 2001 schrieb Thorsten Haude:
Moin,
* Christoph Maurer
[01-11-05 17:23]: Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und "export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier etwas? Im ersten Fall brauchst Du kein export Ich würde sogar sagen: Es sollte unbedingt vermieden werden. ACK
QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm Warum klappt das bei meinem Shellbeispiel nicht?
Weil die Variable $SHELL von der SHELL, in der Du den Befehl SHELL=/bin/zsh echo $SHELL aufrufst, längst ausgewertet ist, eigentlich wird da SHELL=/bin/zsh echo /bin/bash ausgeführt. mach mal #ohne Export! MYVARIABLE="A B TEST" SHELL=/bin/zsh echo $MYVARIABLE dann versteht man den Effekt leichter Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin,
* Christoph Maurer
Am Mon, 05 Nov 2001 schrieb Thorsten Haude:
QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm Warum klappt das bei meinem Shellbeispiel nicht? Weil die Variable $SHELL von der SHELL, in der Du den Befehl SHELL=/bin/zsh echo $SHELL aufrufst, längst ausgewertet ist, eigentlich wird da SHELL=/bin/zsh echo /bin/bash ausgeführt. <clap target="forehead"/>
mach mal #ohne Export! MYVARIABLE="A B TEST" SHELL=/bin/zsh echo $MYVARIABLE dann versteht man den Effekt leichter
Suupa! Als erstes habe ich erstmal: >MYVARIABLE="A B TEST" gemacht. Nochmal: Daraus lerne ich auch nichts neues. Was soll mir das 'SHELL=/bin/zsh' sagen? Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Am Mon, 05 Nov 2001 schrieb Thorsten Haude:
Moin,
* Christoph Maurer
[01-11-05 17:55]: Am Mon, 05 Nov 2001 schrieb Thorsten Haude:
QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm Warum klappt das bei meinem Shellbeispiel nicht? Weil die Variable $SHELL von der SHELL, in der Du den Befehl SHELL=/bin/zsh echo $SHELL aufrufst, längst ausgewertet ist, eigentlich wird da SHELL=/bin/zsh echo /bin/bash ausgeführt. <clap target="forehead"/>
mach mal #ohne Export! MYVARIABLE="A B TEST" SHELL=/bin/zsh echo $MYVARIABLE dann versteht man den Effekt leichter
Suupa! Als erstes habe ich erstmal:
MYVARIABLE="A B TEST" gemacht.
Nochmal: Daraus lerne ich auch nichts neues. Was soll mir das 'SHELL=/bin/zsh' sagen?
Nix besonderes, es soll Dir nur zeigen, dass die Variable laengst ausgewertet ist, bevor echo $SHELL durchgefuehrt wird. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On Mon, 05 Nov 2001, Thorsten Haude wrote:
Nochmal: Daraus lerne ich auch nichts neues. Was soll mir das 'SHELL=/bin/zsh' sagen?
Diese Variable wird z.B. gerne von Makefiles und configure-scripts ausgewertet (und verwendet! z.B. als: LIBTOOL='$(SHELL) $(top_builddir)/libtool' greppe nach 'SHELL' in irgendnem 'configure' ;) Ach ja, mach mal: dh@slarty[6]:~ (0) $ echo '/bin/echo "$SHELL"' > /tmp/test.sh dh@slarty[6]:~ (0) $ sh /tmp/test.sh /bin/bash dh@slarty[6]:~ (0) $ SHELL=/usr/bin/zsh sh /tmp/test.sh /usr/bin/zsh dh@slarty[6]:~ (0) $ rm /tmp/test.sh -dnh -- "The computers may suck, and software ... may suck, but it's the people who provide the horror." -- Rebecca Ore, asr
On 05-Nov-2001 Christoph Maurer wrote:
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und "export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier etwas?
Im ersten Fall brauchst Du kein export
Aber wenn Du ein KDE1-Programm in seiner korrekten Umgebung ausführen willst, dann mache mal QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm
Damit werden die Variablen nur für diesen Programmaufruf gesetzt, die Umgebung der Shell, von der Du den Befehl absetzt, bleibt unverändert.
Das ist klar. Aber ich hatte eben gehofft, dass dies ueber einen
Eintrag in /etc/profile.local zu setzen waere.
Wenn ich KDE-Programme ueber die fvwm2-Taskbar starte, rufe ich sie
mit dem jeweiligen KDEDIR auf, aber meistens bin ich fuer das Klicken
zu faul und gehe ueber das xterm. Und dann kann ich fast wetten, dass
KDEDIR wieder mal genau auf die andere Version gesetzt ist.
Aber gut, tragisch ist es nicht, nur laestig. Und _so_ oft verwende ich
KDE-Programme nun auch wieder nicht.
Guten Abend,
Heinz.
--
E-Mail: Heinz W. Pahlke
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
On 05-Nov-2001 Christoph Maurer wrote:
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
Heisst das, man kann z.B. "export KDRDIR=/opt/kde programm1" und "export KDEDIR=/opt/kde" parallel setzen? Oder missverstehe ich hier etwas?
Im ersten Fall brauchst Du kein export
Aber wenn Du ein KDE1-Programm in seiner korrekten Umgebung ausführen willst, dann mache mal QTDIR=/usr/lib/qt KDEDIR=/opt/kde kde1programm
Damit werden die Variablen nur für diesen Programmaufruf gesetzt, die Umgebung der Shell, von der Du den Befehl absetzt, bleibt unverändert.
Das ist klar. Aber ich hatte eben gehofft, dass dies ueber einen Eintrag in /etc/profile.local zu setzen waere.
Wenn ich KDE-Programme ueber die fvwm2-Taskbar starte, rufe ich sie mit dem jeweiligen KDEDIR auf, aber meistens bin ich fuer das Klicken zu faul und gehe ueber das xterm. Und dann kann ich fast wetten, dass KDEDIR wieder mal genau auf die andere Version gesetzt ist.
Aber gut, tragisch ist es nicht, nur laestig. Und _so_ oft verwende ich KDE-Programme nun auch wieder nicht.
Dafür gibt es aber eine einfache Lösung. Definiere Dir ein Wrapper-Skript #!/bin/bash #kde1wrapper, für kde2 sind die Pfade anzupassen QTDIR=/usr/lib/qt KDEDIR=/opt/kde /opt/kde/bin/$0 $@ Jetzt legst Du in einem Verzeichnis in Deinem PATH, dessen Ausführungspriorität höher ist als die des KDE Binary-Verzeichnisses, Links mit dem Programmnamen auf das Wrapperskript an. z.B. mit for i in /opt/kde/bin/*; do ln -s $(basename $i) wrapperskript; done Fertig. Damit kannst Du in einem xterm einfach den Programmnamen einhacken und bekommst trotzdem die Variablen richtig gesetzt. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Mon, 05 Nov 2001 schrieb Christoph Maurer:
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke:
On 05-Nov-2001 Christoph Maurer wrote:
Am Mon, 05 Nov 2001 schrieb Heinz W. Pahlke: [KDEDIR richtig setzen]
Dafür gibt es aber eine einfache Lösung.
Definiere Dir ein Wrapper-Skript #!/bin/bash #kde1wrapper, für kde2 sind die Pfade anzupassen QTDIR=/usr/lib/qt KDEDIR=/opt/kde /opt/kde/bin/$0 $@
Jetzt legst Du in einem Verzeichnis in Deinem PATH, dessen Ausführungspriorität höher ist als die des KDE Binary-Verzeichnisses, Links mit dem Programmnamen auf das Wrapperskript an. z.B. mit for i in /opt/kde/bin/*; do ln -s $(basename $i) wrapperskript; done
Schande über mich: Es muß natürlich heißen for i in /opt/kde/bin/*; do ln -s wrapperskript $(basename $i); done Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
participants (10)
-
B.Brodesser@t-online.de
-
Christoph Maurer
-
David Haller
-
Heinz W. Pahlke
-
Qbert@t-online.de
-
Ralf Corsepius
-
Steve Graegert
-
Thomas Hertweck
-
Thorsten Haude
-
Waldemar Brodkorb