export befehl ist nicht dauerhaft

[SwordMaster]

Hab einen neuen Java Compiler

wollte ihn in %PATH mit export eintragen

wenn ich jedoch den Rechner neustarte, steht plötzlich nichts mehr in $PATH

könnt ihr mir helfen?

MFG SworMaster

[SystemError]

Original geschrieben von SwordMaster

...wollte ihn in %PATH mit export eintragen...$PATH....

$PATH ?

Du solltest Deine ".profile" Datei editieren, evtl. heisst die auch ".bash_profile" (auf LinuxSystemen mit der Shell Bash), liegt in Deinem HomeVerzeichnis.

Das dieses Ding mit einem Punkt beginnt, siehst Du sie aber nur mit einem "ls -la" oder ähnlichem...

Da sollte eine Zeile stehen, ala:

"

PATH=$PATH:$HOME/bin

"

Da machst Du dann draus:

"

PATH=$PATH:$HOME/bin:/mein/ganz/schrecklich/langer/pfad

"

Musst eben den entsprechenden Pfad dorthin angeben wo sich Dein JavaCompiler auch immer versteckt.

Der "export PATH" darf natuerlich im Profil Deines Benutzers auch nicht fehlen.

Solltest Du keine ProfilDatei haben kannst Du Dir auch eine anlegen.

Dann neu anmelden, und gut.

Bye

SystemError

[SwordMaster]

so einfach gehs doch nicht...

will nämlich nicht nur ein teil zum $PATH hinzufügen

sondern auch einen teil rauskriegen (sonst nimmt er weiterhin den alten compiler) wenn der auch in $Path drinnensteht....

abs schon ausprobiert wenn ich mit export den alten compiler aus $Path nehm und den neuen pfad des compilers dazuschreib dann funktionierts

nur die änderungen sind nach dem nächsten neustart nicht mehr vorhanden!

am besten wärs wenn ich export einfach irgendwie dauerhaft machen könnt

ist das möglich??

außerdem find ich für root keine ".profile" datei ((

auch keine "bash_profile"

Edit: zum anlegen: wo soll ich als root eine .profile anlegen? im home verzeichnis hab ich ja dnan keinen ordner

[SystemError]

Hey,

a.)

Frage: Welches Unix Derivat bzw. welche Linux Distribution ?

b.)

Welches JDK // SDK in welcher Version hattest Du schon installiert und welches sollte jetzt neu verwendet werden ?

c.)

>>> sondern auch einen teil rauskriegen

OK. Auch das sollte kein Problem sein.

d.)

Wenn Du mit "export" auf der Shell eine Variable setzt dann bleibt dieses solange für genau diese Shell (und alle von ihr gestarteten Prozesse) gültig bis diese Shell (bzw die gestarteten Prozesse) beendet ist / sind.

Natürlich geht somit deine modifizierte Pfadvariable flöten wenn Du bootest.

e.)

Wenn Du also die permanent PfadVariable setzen willst (das gelingt Dir ja anscheinend per "export" interaktiv auf der Shell) empfehle ich Dir dies in der ProfilDatei des entsprechenden Benutzers zu tun.

Sollte diese noch nicht existieren dann kann man die auch anlegen.

Ich zitiere jetzt mal mein Post von gerade eben:

>>> Solltest Du keine ProfilDatei haben kannst Du Dir auch eine anlegen.

f.)

Dazu:

--> Anmelden als entsprechender Benutzer

--> Wechseln ins entsprechende HomeDir mit "cd ~" oder einfach nur "cd"

--> Welche Shell hat der Benutzer ? "echo $SHELL"

--> Nun editieren wir das Profil: "vi .bash_profile" oder welchen Editor Du auch immer haben willst...

--> Wenn Du eine andere Shell als die gute, alte Bash verwendest dann wird die Datei (wahrscheinlich) nur ".profile" heissen müssen.

--> Die Datei entsprechend abspeichern

--> Die DateiRechte auf 0644 setzen

--> Neu anmelden und gut

Anbei nur ein kleines BEISPIEL (!), so sieht es halt auf meiner LinuxBüxe (RedHat 8.0) hier aus:

"

[root@carthage root]# ls -l ~/.bash_profile

-rw-r--r-- 1 root root 234 Jul 5 2001 /root/.bash_profile

[root@carthage root]# cat .bash_profile

# .bash_profile

# Get the aliases and functions

if [ -f ~/.bashrc ]; then

. ~/.bashrc

fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

BASH_ENV=$HOME/.bashrc

USERNAME="root"

export USERNAME BASH_ENV PATH

[root@carthage root]#

"

Ansonsten wäre es jetzt wirklich hilfreich zu Wissen mit welchem Unix Derivat oder welcher Linux Distribution Du arbeitest....

...SystemErrors Glaskugel ist nämlich gerade beim TÜV....

Abschliessend sei noch bemerkt dass Du beim Editieren des RootProfils grosse Vorsicht walten lassen solltest...

...und Dir im klaren darüber sein solltest was Du da tust...

...ansonsten könnte das fatale Konsequenzen für Dein System haben...

Aber womit unterscheidet sich dann diese Aktion von jeder anderen die Du als root ausführst ?

;-)

Bye

SystemError

PS:

Ich frage jetzt lieber nicht warum Dein rootBenutzer was mit Java machen will, oder ?

PPS:

Halt !!! Wo steht denn Dein altes Java ?

Bitte unbedingt die Ausgabe von "type java" und "which java" posten bevor Du irgendwas machst !

[SwordMaster]

1. da ich selten unter linux arbeite (is nur mein zweitrechner) bin ich zu 90% immer unter root drin, => programmier auch unter root....

und: ja ich weiß dass ich das nciht tun soll, aber wenn ich doch nun mal das root pw hab :-P außerdem is eh nichts soo wichtiges drauf was ich kaput machen könnt...

2. ich habs gelesen dass du das in der ersten post schon geschrieben hast, dass WENN eine .profile datei nicht vorhanden ist, man die erstellen soll

aber ich hab dir dann als anwort geschrieben dass ich nicht weiß wo ich eine .profile datei für root anlegen soll

3. ich hab jetzt mit export $PATH so umstrukturiert dass alles geht...

einfach den alten compiler (glaub war 1.1.3 oder so) rausgetan und den neuen pfad reingeschrieben => alles funktioniert genauso wie ich will...

4. also bräucht ich eignetlich NUR wissen wo cih eine .profile datei für root anlegen muß...

hab nämlcih keine gefunden als ich mit locate danach gesucht hab....

5. kann mir nicht vorstellen was daran "gefährlich" sein sollte wenn ich den 1.3er aus $Path raustu und dafür 1.4er reintu....

$HOME_JAVA müßt ich übrigens dann natürlich auch ändern....

kann ich das auch in ".profile"??

MFG SwordMaster

[SystemError]

Hey,

1.)

OK, in der von Dir beschriebenen Umgebung ist es denke ich einfach nur eine Frage des Geschmacks ob Du mir dem rootBenutzer arbeiten willst...

3.)

Sehr gut.

2.) & 4.)

>>> aber ich hab dir dann als anwort geschrieben dass ich nicht weiß wo ich eine .profile datei für root anlegen soll

Sorry, im HomeVerzeichnis von root...

---> "echo $HOME"

>>> also bräucht ich eignetlich NUR wissen wo

Da Du eine LinuxKiste hast (-> ".bash_profile") tippe ich jetzt mal auf genau dorthin: $HOME/.bash_profile

Bsp:

"

[root@carthage root]# ls -l $HOME/.bash_profile

-rw-r--r-- 1 root root 234 Jul 5 2001 /root/.bash_profile

"

5.)

>>> $HOME_JAVA

>>> kann ich das auch in ".profile"??

Yep, genau richtig.

(-> ".bash_profile")

Gilt für alle Umgebungsvariablen.

>>>...kann mir nicht vorstellen was daran "gefährlich" sein...

:-|

Nun ja:

Beim tippen meiner Antwort ist eben aufgefallen dass ich viele Dinge raten musste (Unix/Linux ?) und nicht wirklich wusst wie der Inhalt Deiner Pfadvariablen vorher // nachher aussah....

... und mir sind z.B. auch schon JDKs untergekommen, die irgendwelche Links von /usr/bin oder /usr/local/bin zum eigentliechen JavaBinary gesetzt hatten...

Wäre z.B. relativ uncool gewesen /usr/bin aus dem Pfad von root zu nehmen...

Hätte Dir zumindest die root Umgebung verbogen, wenn auch nicht wirklich was kaputt gemacht...

Auf alle Fälle aber ein Zustand der einen ganz schön in den Wahnsinn treiben kann...

Bye

SystemError

[SwordMaster]

habs jetzt hinbekommen

war die

$HOME/.profile

also bei root

"/root/.profile"

hab die export befehle reingeschrieben und schon funktionierts

thanks

MFG SwordMaster

[nic_power]

Hallo,

Original geschrieben von SystemError

OK, in der von Dir beschriebenen Umgebung ist es denke ich einfach nur eine Frage des Geschmacks ob Du mir dem rootBenutzer arbeiten willst...

Nein, das ist keine Frage des Geschmacks sondern grob fahrlässig! Regel 1: "Arbeite nur dann als root, wenn es sich nicht vermeiden läßt". Nicht umsonst gibt es unterschiedliche Nutzer mit unterschiedlichen Rechten und man sollte es sich gar nicht erst angewöhnen, standardmäßig als root zu arbeiten (egal, ob es sich nun "nur" um ein Test-System handelt. Schlechte Angewohnheiten nimmt man gerne mit auf Wirksysteme).

Nic

[SystemError]

Hey,

>>>Nein, das ist keine Frage des Geschmacks sondern grob fahrlässig!

Das hast Du eigentlich recht, ABER:

Was SwordMaster auf seiner EntwicklerWorkstation treibt, ist in erster Linie sein Problem.

Und wenn er sich durch diese Fahrlässigkeit in Schwierigkeiten bringt ist es auch sein Problem, dann muss er eben die Konsequenzen tragen...

Und er schient er die Daten auf seiner Workstation nicht gerade als sonderlich wichtig anzusehen:

>>> nichts soo wichtiges drauf was ich kaput machen könnt...

>>> Schlechte Angewohnheiten nimmt man gerne mit auf Wirksysteme

Auch wieder wahr.

Ich für meinen Teil würde das auch nimmer (ganz egal auf welcher Kiste) so machen wollen, aber hey:

Es ist schliesslich immer noch jedem selbst überlassen was er auf seinen Rechnern treibt, wir sind schliesslich alle große Jungs & Mädels.

Bye

SystemError

[Oortael]

Hab das gleiche Problem. Würde gerne den Tomcat 5.5.7 beim start des System automatisch hochfahren. Da Java aber für mehre Dinge als nur den Tomcat benötigt wird frag ich mich, ob es eine Möglichkeit gibt die Umgebungsvariablen Global für die Dienste bereit zu stellen? Ohne, dass die Anmeldung eines Benutzers ans System erforderlich ist.

Google schlägt mir auch nur einen eintrag in die /etc/profile.local vor.

Ab wann wird die ausgewertet? Erst wenn sich ein Benutzer anmeldet?

[Schlaubi]

In der Man-Page von bash steht unter INVOCATION genau das, was du wissen willst

[Oortael]

Äh nein. Invocation sagt mir nur, wie ich die shell zu starten habe. die bash startet aber nicht, bevor ich mich am rechner anmelde.

[Wurstwasser]

kommt zwa rauf die distri an, schau aber mal in die /etc/profile

[Schlaubi]

Äh nein. Invocation sagt mir nur, wie ich die shell zu starten habe.

Dann hast Du nicht richtig nachgelesen:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and

executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile,

~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

The --noprofile option may be used when the shell is started to inhibit this behavior.

die bash startet aber nicht, bevor ich mich am rechner anmelde.

Und Du meinst der Tomcat-Prozess wird nicht innerhalb einer Shell gestartet?

[Oortael]

Nein, ich meine, dass Suse ~/.bash_profile,

~/.bash_login, ~/.profile und /etc/profile nicht auswertet bis sich ein benutzer anmeldet. Zumindest verhält es sich bei meinem SLES8 so.

Ich lasse mir vom Start-Script in /etc/init.d die in /etc/profile und /etc/profile.local festgelegten Variablen ausgeben. Diese Variablen beinhalten aber nur die Pfade, wenn ich mich als Benutzer anmelde. Ansonsten bleibe sie leer.

Sorry, dass ich mich vorher etwas unverständlich ausgedrückt habe.

[Schlaubi]

Ich glaube Du hast ein Verständnisproblem - warum sprichst Du immer von Benutzerlogin? Eine Shell kann doch auch nicht-interaktiv sein???

[Oortael]

Aber warum wertet er die Dateien nicht aus? /etc/profile.local ist doch User-unabhängig, oder?

[DevilDawn]

Das steht doch in der manpage.

bash wertet die /etc/profile (die dann /etc/profile.local sourced) nur aus wenn sie als interaktive Shell oder mit --login gestartet wurde.

Ein Shellscript-Aufruf fällt unter non-interactive und wertet die profile daher nicht aus.

Du solltest im Initscript die Environment also gesondert setzen.

[Oortael]

bash wertet die /etc/profile (die dann /etc/profile.local sourced) nur aus wenn sie als interaktive Shell oder mit --login gestartet wurde.

Sag ich doch die ganze zeit. Gibt es trotdem die Möglichkeit so etwas global zu setzen?

[DevilDawn]

IMHO nicht. Alle rc-Scripte werden von init Ausgeführt und bekommen eine minimale Environment. Meiner Meinung nach auch sinnvoll - was sollen Mailer/Webserver mit dem Pfad zur JRE oder zum javac? Wenn mehrere Services es brauchen leg dir eine /etc/profile.java an und source die aus der profile.local und in den init-scripten die es brauchen.

ENVIRONMENT

Init sets the following environment variables for all its children:

PATH /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin

INIT_VERSION

As the name says. Useful to determine if a script runs directly

from init.

RUNLEVEL

The current system runlevel.

PREVLEVEL

The previous runlevel (useful after a runlevel switch).

CONSOLE

The system console. This is really inherited from the kernel;

however if it is not set init will set it to /dev/console by

default.