Skript ausführen mit dem Kommando source

[oraclin25]

Hallo zusammen,

ich versuche gerade zu verstehen, WARUM bei manschen Konstellationen es sinnvoll ist, Skripte mittels Kommando SOURCE auszuführen. Dazu habe ich ein bisschen gegoogelt und habe folgendes gefunden:

Execute Shell Script Using . ./ (dot space dot slash)
While executing the shell script using “dot space dot slash”, as shown below, it will execute the script in the current shell without forking a sub shell.

$ . ./scriptfile

In other words, this executes the commands specified in the scriptfile in the current shell, and prepares the environment for you.

“dot space dot slash” Usage Example:
Typically we use this method, anytime we change something in the .bashrc or .bash_profile. i.e After changing the .bashrc or .bash_profile we can either logout and login for the changes to take place (or) use “dot space dot slash” to execute .bashrc or .bash_profile for the changes to take effect without logout and login.

Die Ausführung eines Skriptes mit Kommando SOURCE bewirkt also, dass für die Ausführung kein Kind-Shell erzeugt wird. So ist es sichergestellt, dass das Skript die möglicherweise notwendigen Umgebungsvariablen hat(da das Skript ja in der aktuellen Shell ausgeführt wird). Meine Frage:
Ist das denn nicht so, dass Umgebungsvariablen einer Shell sowieso weiter an die Kind-Shells weiter vererbt werden? Eine Kind-Shell bekommt die Umgebungsvariablen vo der Vater-Shell nicht?

Zu der Beispielanwendung:
Typically we use this method, anytime we change something in the .bashrc or .bash_profile. i.e After changing the .bashrc or .bash_profile we can either logout and login for the changes to take place (or) use “dot space dot slash” to execute .bashrc or .bash_profile for the changes to take effect without logout and login.

Warum sollte es nicht möglich sein, sich nach einer Änderung von .bashrc bzw. .bash-profile auszuloggen oder einzuloggen?

Vielen Dank für Eure Hilfe

Schöne Grüße aus Rheinland,
Eure Ratna

 

[deepthroat]

Hi.

Die Ausführung eines Skriptes mit Kommando SOURCE bewirkt also, dass für die Ausführung kein Kind-Shell erzeugt wird. So ist es sichergestellt, dass das Skript die möglicherweise notwendigen Umgebungsvariablen hat(da das Skript ja in der aktuellen Shell ausgeführt wird). Meine Frage:
Ist das denn nicht so, dass Umgebungsvariablen einer Shell sowieso weiter an die Kind-Shells weiter vererbt werden?

Eine Subshell hat Zugriff auf alle Variablen der "Obershell". Aber nicht umgekehrt.

Eine Kind-Shell (Kindprozeß) erbt lediglich die exportierten Variablen.

$ echo "x=3" >> test.sh && chmod +x test.sh
$ echo 'echo x ist $x' > test2.sh && chmod +x test2.sh
$ ./test.sh
$ echo $x # aktuelle Shell "kennt" x nicht

$ ./test2.sh # Kindprozess "kennt" x auch nicht
x ist
$ . test.sh
$ echo $x # aber jetzt
3
$ ./test2.sh # Kindprozess "kennt" x immer noch nicht
x ist
$ export x
$ ./test2.sh # aber jetzt
x ist 3

Zu der Beispielanwendung:
Typically we use this method, anytime we change something in the .bashrc or .bash_profile. i.e After changing the .bashrc or .bash_profile we can either logout and login for the changes to take place (or) use “dot space dot slash” to execute .bashrc or .bash_profile for the changes to take effect without logout and login.

Warum sollte es nicht möglich sein, sich nach einer Änderung von .bashrc bzw. .bash-profile auszuloggen oder einzuloggen?

Das hast du falsch verstanden. Da steht: entweder man loggt sich aus und wieder ein (was zum Starten einer neuen Shell und zum Neueinlesen von .bashrc führt) oder man übernimmt die Änderungen in die aktuelle Shell mit "source".

 

[oraclin25]

Hallo deepthroat,

danke für den Beispielcode. Ich hoffe, dass ich das richtig verstanden habe:

Das Kommando SOURCE bzw. Pünktchen ist dazu da, damit die Variablen(falls vorhanden) des Skriptes in der aktuellen Shell bekannt sind?

Ausführung in Kind-Shell(ohne Source):
1. Das Skript kann Umgebungsvariablen von Vater-Shell benötigen. Kein Problem, da die Kind-Shell diese geerbt bekommt.
2. Gefahr ist aber --> Variablen, die im Skript enthalten sind, sind in der Vater-Shell nicht bekannt.

Ausführung in aktueller Shell(mit Source):
1. Das Skript hat die eventuell benötigten Umgebungsvariablen, logisch, da sowieso in der aktuellen Shell ausgeführt.
2. Keine Gefahr --> da in aktueller Shell ausgeführt, kennt die aktuelle Shell automatisch die Variablen vom Skript (die möglicherweise im Skript enthalten sind)

Das ist so richtig?

Schöne Grüße aus Rheinland,

Eure Ratna

 

[deepthroat]

Das ist so richtig?

Ja, das ist korrekt.

Aber ich würde dabei nicht von Gefahr sprechen.

Höchstens andersherum: bei Verwendung von source besteht die "Gefahr" das Variablen der Shell von einem "ge-source-ten" Skript verändert werden.

Außerdem betrifft das natürlich nicht nur Variablen, sondern auch Aliase (in interaktiven Shells) und Funktionen.

 

[oraclin25]

Hallo deepthroat,

danke.. Du hast von "interaktive Shells" erwähnt. Ich habe mich dazu ein bisschen schlau gemacht, rückzug bin ich auf folgende Begrifflichkeiten gestoßen:
1. Login-Shell
2. Interaktive Non-Login-Shell
3. Non-Interaktive Non-Login-Shell

Ich hätte zu jeder obigen Shell ein Beispiel:
1. Es steht oft, eine Login-Shell ist zum Beispiel die Shell, die beim Login erzeugt wird und die Startup-Skripte ausführt. Meine Frage:
wenn ich mich unter meinem Benutzerprofil auf einem Unix-Rechner ganz normal anmelde, das erste was kommt ist eigentlich die grafische Benutzeroberfläche. Bis die grafische Benutzeroberfläche aufgetaucht ist, sind die Startup-Skripte von einer Login-Shell bereits fertig ausgeführt? Also, man kommt eigentlich mit einer Login-Shell nie in Berührung. Es sei denn, man logt sich über ssh wie zum Beispiel putty in seinem Rechner ein? In diesem Fall ist die "putty"-Terminal eine interaktive Login-Shell? Aber für Otto-Normal-Ubuntu-Benutzerin wie mich, hat man mit einer Login-Shell eigentlich wenig zu tun, richtig?

2. Wenn ich also bereits auf der grafische Benutzeroberfläche bin und von da aus ein Terminal öffne, das ist dann eine interaktive Non-Login-Shell. Das ist mir klar

3. Wenn ich unter einer interaktiven non-login-Shell(unter meinem "normalen" Terminal also) ein Skript ausführe, dann wird im Hintergrund zur Skriptausführung eine Kind-Shell erzeugt. Diese Kind-Shell ist eine Non-Interaktive Non-Login-Shell, da die Befehle nacheinander direkt ausgeführt werden (ohne auf den Befehl vom Benutzer zu warten). Das sollte auch so richtig sein.

Könntest Du zu (1) vielleicht etwas sagen? Vielen Dank.

Schöne Grüße aus Rheinland,

Eure Ratna

 

[deepthroat]

1. Es steht oft, eine Login-Shell ist zum Beispiel die Shell, die beim Login erzeugt wird und die Startup-Skripte ausführt. Meine Frage:
wenn ich mich unter meinem Benutzerprofil auf einem Unix-Rechner ganz normal anmelde, das erste was kommt ist eigentlich die grafische Benutzeroberfläche. Bis die grafische Benutzeroberfläche aufgetaucht ist, sind die Startup-Skripte von einer Login-Shell bereits fertig ausgeführt?

Das kommt ganz drauf an, ob beim grafischen Login überhaupt eine Login-Shell ausgeführt wird.

Ansonsten kann man sich ja auch auf einer (virtuellen) Konsole einloggen. Dann bekommt man eine interaktive Login-Shell.