Init-Skripte und Umgebungsvariablen

Hallo Leute!

Hab mal wieder (immer noch unter HP-UX) ein paar kleinere Probleme.

Und zwar betreffen die zum einen init-Skripte und zum andren Umgebungsvariablen.

Und zwar habe ich ein init-Skript geschrieben dass in den rcX.d-Verzeichnissen gelinkt wird. Funktioniert auch gut, nur werden Umgebungsvariablen die ich dortdrinnen setze und mit export bekannt mache nicht in den Shell an dem sich der User dann anmeldet übernommen, das habe ich nur über die Shell-Initialisierungs-Skripte profile/bashrc zusammengebracht.

Standardmässig verwendet HP-UX da sh als Shell, ich habe bash installiert, für root als Standard-Shell eingerichtet und lasse das init-Skript auch über #!/sbin/bash im bash ausführen.

Deswegen ist mir nicht ganz klar ob ich da einen Fehler mache, oder ob das aus irgendwelchen Gründen gar nicht geht. Kenne mich da nicht aus, welche Instanz des bash diese init-Skripte dann ausführt bzw. welche Instanz dann dem User zur Verfügung gestellt wird. Und wo überhaupt definiert ist welcher Shell für die init-Skripte verwendet wird.

Ich hoffe das kann mir jemand erklären, hab im Netz leider nichts aussagekräftiges gefunden.

Eine andre Frage habe ich noch, und zwar, ist es möglich, dass ich aus einem Shell-Skript ein anderes Shell-Skript so aufrufen, sodass die Variablen die im aufgerufenen Skript über export bekannt gemacht werden auch im aufrufenden Skript zur Verfügung stehen?

Danke für eure Mühen und schöne Grüße,
Robert

Und zwar habe ich ein init-Skript geschrieben dass in den
rcX.d-Verzeichnissen gelinkt wird. Funktioniert auch gut, nur
werden Umgebungsvariablen die ich dortdrinnen setze und mit
export bekannt mache nicht in den Shell an dem sich der User
dann anmeldet übernommen, das habe ich nur über die
Shell-Initialisierungs-Skripte profile/bashrc
zusammengebracht.

das ist klar, exportierte variablen werden an childs dieser shell weitergegeben, sonst niemanden.

Standardmässig verwendet HP-UX da sh als Shell, ich habe bash
installiert, für root als Standard-Shell eingerichtet

das ist _gar_ keine gute idee! wenn du irgendwann mal probleme auf der kiste hast, und im single user mode arbeiten musst, wird dich die bash klaeglich im stich lassen…

und
lasse das init-Skript auch über #!/sbin/bash im bash
ausführen.

was macht die in sbin? ist die statisch gelinkt?

Deswegen ist mir nicht ganz klar ob ich da einen Fehler mache,

du machst…

oder ob das aus irgendwelchen Gründen gar nicht geht.

es geht nicht.

Kenne
mich da nicht aus, welche Instanz des bash diese init-Skripte
dann ausführt

ich glaube keine, aber ich weiss es nicht…
hast du denn was bash-spezifisches verwendet?

Eine andre Frage habe ich noch, und zwar, ist es möglich, dass
ich aus einem Shell-Skript ein anderes Shell-Skript so
aufrufen, sodass die Variablen die im aufgerufenen Skript über
export bekannt gemacht werden auch im aufrufenden Skript zur
Verfügung stehen?

no way. da muss man sich was ueberlegen, seien es exitcodes, signale oder einfache files…

joachim

das ist klar, exportierte variablen werden an childs dieser
shell weitergegeben, sonst niemanden.

Hmmm, verstehe. D. h. wenn ich in einem Skript ein andres aufrufe wird eine neue Instanz des Shells erzeugt?

Hab inzwischen was gleichwertiges gefunden, und zwar „source“ bzw. „.“, wenn man das dem Aufruf voranstellt entspricht das in etwa einer C-include-Direktive, damit erzeugt er dann offensichtlich keine neue Instanz und kennt damit auch die Variablen.

das ist _gar_ keine gute idee! wenn du irgendwann mal probleme
auf der kiste hast, und im single user mode arbeiten musst,
wird dich die bash klaeglich im stich lassen…

Wieso?

was macht die in sbin? ist die statisch gelinkt?

Ich hab sie in sbin kopiert, da der Shell der von root verwendet wird scheinbar auf der /-Partition liegen muss, vorher hats nicht funktioniert. Scheinbar auch statisch gelinkt, sonst hätte ihm das reine kopieren in /sbin wohl nicht gereicht.

Daher meine Annahme, dass er den Shell von root für das Ausführen der init-Skripte verwendet.

ich glaube keine, aber ich weiss es nicht…
hast du denn was bash-spezifisches verwendet?

Du meinst es wird von sh ausgeführt? Irgendwas muß er mit bash auf jeden Fall beim starten machen, nachdem ich es als Standard-Shell für root eingerichtet habe, s. o. er hat danach verlangt. :o)

Hab eigentlich nichts bash-spezifisches verwendet.

no way. da muss man sich was ueberlegen, seien es exitcodes,
signale oder einfache files…

Hmmm, wie gesagt mit dem „source“/"." gehts. Hoffe diese Vorgehensweise hat keine Haken, aber momentan. :o)

Grüße, Robert

das ist klar, exportierte variablen werden an childs dieser
shell weitergegeben, sonst niemanden.

Hmmm, verstehe. D. h. wenn ich in einem Skript ein andres
aufrufe wird eine neue Instanz des Shells erzeugt?

exakt

Hab inzwischen was gleichwertiges gefunden, und zwar „source“
bzw. „.“, wenn man das dem Aufruf voranstellt entspricht das
in etwa einer C-include-Direktive, damit erzeugt er dann
offensichtlich keine neue Instanz und kennt damit auch die
Variablen.

richtig. aber dann ist das gesourcte streng genommen kein eigenes skript mehr…

das ist _gar_ keine gute idee! wenn du irgendwann mal probleme
auf der kiste hast, und im single user mode arbeiten musst,
wird dich die bash klaeglich im stich lassen…

Wieso?

erfahrung. du waerst nicht der erste, der sich ne andere shell als /sbin/sh als root shell einstellt, und dann, wenn irgendwas dummes passiert, in den single user mode booten will und nicht mehr reinkommt - viel spass beim neuinstallieren…

was macht die in sbin? ist die statisch gelinkt?

Ich hab sie in sbin kopiert, da der Shell der von root
verwendet wird scheinbar auf der /-Partition liegen muss,
vorher hats nicht funktioniert. Scheinbar auch statisch
gelinkt, sonst hätte ihm das reine kopieren in /sbin wohl
nicht gereicht.

erm, da waere ich mir nicht so sicher. ich wuerde mal testweise single booten (hpux -iS /stand/vmunix im ISL)

erhellend ist auch folgendes:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0…

Daher meine Annahme, dass er den Shell von root für das
Ausführen der init-Skripte verwendet.

anzunehmen, hoffentlich ist die bash auch so posix kompatibel, wie sie tut…
die sh unter hpux ist keine echte bourne, sondern eine posix shell.

ich glaube keine, aber ich weiss es nicht…
hast du denn was bash-spezifisches verwendet?

Du meinst es wird von sh ausgeführt? Irgendwas muß er mit bash
auf jeden Fall beim starten machen, nachdem ich es als
Standard-Shell für root eingerichtet habe, s. o. er hat danach
verlangt. :o)

ich weiss es gerade nicht sicher, aber ich vermute jetzt, er hat tatsaechlich die bash genommen.

no way. da muss man sich was ueberlegen, seien es exitcodes,
signale oder einfache files…

Hmmm, wie gesagt mit dem „source“/"." gehts. Hoffe diese
Vorgehensweise hat keine Haken, aber momentan. :o)

noe, ich kam gar nicht auf die idee, da du ja von zwei skripten sprachst…

joachim

Hallo Joachim!

richtig. aber dann ist das gesourcte streng genommen kein
eigenes skript mehr…

Nein, das nicht. :o)

In meinem Fall ging es einfach darum, dass ich ein paar Umgebungsvariablen habr, die ich 1) in einem init-Skript und 2) in der Shell-Instanz der Benutzer benötige. Und ich wollte die Variablen nicht an zwei Stellen doppelt definieren.

Mit dem „source“ kann ich einfach ein Skript habe, in dem die Variablen deklariert und zugewiesen werden, dieses Skript wird dann im init-Skript und in /etc/profile eingebunden. :smile:

erfahrung. du waerst nicht der erste, der sich ne andere shell
als /sbin/sh als root shell einstellt, und dann, wenn
irgendwas dummes passiert, in den single user mode booten will
und nicht mehr reinkommt - viel spass beim neuinstallieren…

Hmmm, verstehe was du meinst.

Die Argumente gegen einen andren Shell in der Diskussion beschränken sich aber alle darauf, dass 1) nicht auf der Root-Partition und 2) nicht statisch gelinkt.

Bei mir war es so, dass ich beim ersten Versuch /usr/local/bin/bash als Standard-Shell für root eingetragen habe. Das hat ihn dann aber nicht aufgehängt, sondern er ist anscheinend auf eine Art Notfall-Mechanismus zurückgefallen und hat direkt in einen sh-Shell mit eingeloggtem root gebootet.

erm, da waere ich mir nicht so sicher. ich wuerde mal
testweise single booten (hpux -iS /stand/vmunix im ISL)

OK, werde ich nächste Woche gleich ausprobieren. :smile:

Grüße, Robert