Subshells in der Bash

[oom]

Hallo,

Die Frage klingt vielleicht doof - vielleicht auch nicht ...

Was ist der Sinn einer Subshell? Warum arbeitet man nicht in einer definierten Umgebung?

Weder Google noch meine Literatur brachte ein passendes Ergebnis.

MfG

o.o.m

[niesommer]

Hallo,

hier hab ich mal einen Link der etwas über subshell sag:

http://tldp.org/LDP/abs/html/subshells.html

ich habe da mal google übersetzen lassen http://debianforum.de/forum/pastebin.ph ... ew&s=34743
das war wohl nicht so gut, sorry, das sollte jetzt besser sein:

http://translate.google.de/translate?hl ... e%26sa%3DG

hilft dir das weiter?

[Meillo]

Was ist der Sinn einer Subshell? Warum arbeitet man nicht in einer definierten Umgebung?

Das schöne an einer Subshell ist, dass du darin die Umgebung beliebig manipulieren kannst, aber wenn du sie wieder verlassen hast, dir sicher sein kannst, dass alles wieder wie vorher ist.

[oom]

... um es eben noch zu erwähnen:

... mir ist man mit der o.g. Frage in den Rücken gefallen. Selbst wäre ich vermutlich nicht auf diese Frage gekommen.

MfG

o.o.m

[Meillo]

... um es eben noch zu erwähnen:

Danke für die Zusatzinformation.

... mir ist man mit der o.g. Frage in den Rücken gefallen. Selbst wäre ich vermutlich nicht auf diese Frage gekommen.

Wie meinst du ``in den Rücken gefallen''? War es eine Prüfungssituation?

Dann hätte ich zuerst mal zurückgefragt: Was genau ist mit der ``Subshell'' gemeint? Das Syntax-Konstrukt (= runde Klammern) der Shell, oder grundsätzlich das Aufrufen einer Shell in einer Shell, oder was weiß ich?

Erst wenn man das weiß kann man wirklich argumentieren.



(Ich diskutiere gerne noch ein bisschen auf dem Thema rum, wenn noch andere dabei sind.)

[uname]

(Ich diskutiere gerne noch ein bisschen auf dem Thema rum, wenn noch andere dabei sind.)

Mit screen kann man Subshells visualisieren. Obwohl eigentlich sind es gar keine wirklichen Subshells, oder etwa doch?

Code: Alles auswählen

 
 2660 ?        Ss     0:07 /usr/bin/SCREEN -xRR
 2661 pts/1    Ss+    0:00  \_ /bin/bash
 2662 pts/2    Ss+    0:00  \_ /bin/bash
 2677 pts/3    Ss+    0:00  \_ /bin/bash

[Meillo]

Mit screen kann man Subshells visualisieren. [...]

Code: Alles auswählen

 
 2660 ?        Ss     0:07 /usr/bin/SCREEN -xRR
 2661 pts/1    Ss+    0:00  \_ /bin/bash
 2662 pts/2    Ss+    0:00  \_ /bin/bash
 2677 pts/3    Ss+    0:00  \_ /bin/bash

Wie hast du die Ausgabe erzeugt? Scheint sowas wie `ps f' zu sein.


Letztlich ist das auch nur eine Visualisierung vom Prozessbaum (pstree). Ob es sich um Subshells (was auch immer man darunter verstehen will) oder irgendwelchen andere Kind-Prozesse handelt ist gleich.


Ich vermute dass es bei der ursprünglichen Frage um die runden Klammern der Shell-Syntax ging, denn alles andere läuft ja nur auf Forks hinaus. Und da ist es dann egal ob ein Prozess eine Shell ist oder ein anderes Programm ... eine Shell ist ja auch nur ein Programm wie jedes andere.

btw: ein paar Versuche (getestet mit der ksh):

Code: Alles auswählen

$ sleep 60           # ist ein built-in und wird vom sh-Prozess ausgeführt
$ /bin/sleep 60      # ist ein externes Programm und wird abgeforked
$ ( /bin/sleep 60 )  # erzeugt eine Subshell die dann /bin/sleep abforked
$ ( sleep 60 )       # läuft komplett in der einen Shell (hätte erwartet, dass eine weitere ksh abgeforked wird ... aber vermutlich ist das eine Performanceoptimierung.)

Muss mich mal genauer einlesen wie das intern abläuft.



@oom: Bitte teile uns noch mit wie genau die Fragestellung gemeint war.

[oom]

... Stell Dir einfach vor Du sitzt an Deinem Server um etwas zu konfigurieren. Auf einmal steht Deine Frau oder Freundin hinter Dir und fragt Dich: "Wo is' denn da eigentlich der Mauszeiger?"

Soviel dazu:

... mir ist man mit der o.g. Frage in den Rücken gefallen

Klar soweit?;)

Die Frage habe ich hier letztendlich so weitergeben wie man sie mir gestellt hat. Er meint damit, wqarum man nicht nur eine einzige Shell zur Verfügung hat. Alles was er in dieser Shell schraubt, läuft auch nur in dieser einen Shell ab. Es entstehen also keine Subshells oder wie ich mal gelernt habe - keine Kind-Shells.

MfG

o.o.m

[Meillo]

... Stell Dir einfach vor Du sitzt an Deinem Server um etwas zu konfigurieren. Auf einmal steht Deine Frau oder Freundin hinter Dir und fragt Dich: "Wo is' denn da eigentlich der Mauszeiger?"

Soviel dazu:

... mir ist man mit der o.g. Frage in den Rücken gefallen

Klar soweit?;)

Die Frage habe ich hier letztendlich so weitergeben wie man sie mir gestellt hat.

Du wurdest also von einem gefragt der Unix nicht, oder kaum, kennt.

Sieh es so: Dadurch, dass du die Frage nicht sofort beantworten konntest, hast du nun einiges gelernt.

Er meint damit, wqarum man nicht nur eine einzige Shell zur Verfügung hat. Alles was er in dieser Shell schraubt, läuft auch nur in dieser einen Shell ab.

Man könnte diese eine Shell ja auch gleich zu *der* System-Shell machen ... usw.

Das Tolle an Unix ist eben, dass es sich um sowas gar nicht kümmert. Stattdessen gibt es wenige grundlegende und klar definierte Konzepte die sehr flexibel sind. Z.B. fork und exec; damit kann man dann machen was man will. Oder Login-Shells -- niemand sagt dass deine Login-Shell eine Shell sein muss ... sie kann jedes beliebige Programm sein.

So ist das Starten einer Shell in einer Shell letztlich auch nur ein Ergebnis der Möglichkeit in einer Shell beliebige Programme zu starten. (Soweit jedenfalls zum allgemeinen Kindprozess-Thema.)

Dass Shells dieses runde-Klammern-Konstrukt haben macht das Starten einer Shell in der Shell nur bequemer. ... aber was rede ich da schon: Es gibt nunmal nicht *die* Shell für Unix. Wenn du eine verwendest die so ein Syntaxkonstrukt nicht anbietet, dann musst du halt die Subshell herkömmlich starten: sh -c 'foo'