Discussion:
was bloß bedeutet diese Bash-Syntax ... ?
(zu alt für eine Antwort)
Florian von Savigny
2005-03-13 00:18:59 UTC
Permalink
Hallo, liebe Leute,

ich grübele gerade über dem Problem, was für eine Syntax in der
Manpage von perldebug(1) benutzt wird, wenn dort empfohlen wird,
Optionen für den Debugger in folgender Form anzugeben:

PERLDB_OPTS="..." perl -d script

[sic] Wieso ist sowas erlaubt, und was bedeutet das genau? Hier
erfolgt ja eine Variablenzuweisung und anschließend ein Befehl mit
zwei Argumenten, OHNE, daß diese durch ein Semikolon getrennt
würden. Ist das normal, und was hat das für einen speziellen Effekt?

Merkwürdig ist auch, daß das einfache Setzen der Variablen und
anschließende Aufrufen des Befehls nicht funktioniert, egal, ob man
jetzt in die obige Zeile ein Semikolon einfügt oder beides
hintereinander aufruft. Die Variable wird dadurch zwar gesetzt, wie
man durch "echo $PERLDB_OPTS" nachprüfen kann, aber der Perl-Debugger
benutzt die Werte dann nicht.

Also, was ist das bloß für ein Konstrukt:

VAR=VALUE COMMAND [ARGS]

und wozu wurde es erfunden?

Die bash-Manpage sagt (offenbar dazu) zwar

The environment for any simple command or function may be
augmented temporarily by prefixing it with parameter assignments,
as described above in PARAMETERS. These assignment statements
affect only the environment seen by that command.

aber das erklärt doch noch nicht, warum perl -d sich nicht um den
Krempel kümmert, wenn es ein separater Befehl ist. Oder?
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Martin Kissner
2005-03-12 23:31:01 UTC
Permalink
Post by Florian von Savigny
VAR=VALUE COMMAND [ARGS]
und wozu wurde es erfunden?
Die bash-Manpage sagt (offenbar dazu) zwar
The environment for any simple command or function may be
augmented temporarily by prefixing it with parameter assignments,
as described above in PARAMETERS. These assignment statements
affect only the environment seen by that command.
Damit ist doch eigentlich alles gesagt.
Schau Dir das an:

$ BLAH=BLUBB perl -e 'print $ENV{BLAH},"\n"'
BLUBB
$ echo $BLAH

$

alles klar?
Post by Florian von Savigny
aber das erklärt doch noch nicht, warum perl -d sich nicht um den
Krempel kümmert, wenn es ein separater Befehl ist. Oder?
Wie Du oben siehst, kümmert per sich sehr wohl um den "Kremepl".

Freundlicher Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Martin Kissner
2005-03-12 23:32:47 UTC
Permalink
Post by Florian von Savigny
VAR=VALUE COMMAND [ARGS]
und wozu wurde es erfunden?
Die bash-Manpage sagt (offenbar dazu) zwar
The environment for any simple command or function may be
augmented temporarily by prefixing it with parameter assignments,
as described above in PARAMETERS. These assignment statements
affect only the environment seen by that command.
Damit ist doch eigentlich alles gesagt.
Schau Dir das an:

$ BLAH=BLUBB perl -e 'print $ENV{BLAH},"\n"'
BLUBB
$ echo $BLAH

$

alles klar?
Post by Florian von Savigny
aber das erklärt doch noch nicht, warum perl -d sich nicht um den
Krempel kümmert, wenn es ein separater Befehl ist. Oder?
Wie Du oben siehst, kümmert perl sich sehr wohl um den "Kremepl".

Freundlicher Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Martin Kissner
2005-03-12 23:34:08 UTC
Permalink
Post by Florian von Savigny
VAR=VALUE COMMAND [ARGS]
und wozu wurde es erfunden?
Die bash-Manpage sagt (offenbar dazu) zwar
The environment for any simple command or function may be
augmented temporarily by prefixing it with parameter assignments,
as described above in PARAMETERS. These assignment statements
affect only the environment seen by that command.
Damit ist doch eigentlich alles gesagt.
Schau Dir das an:

$ BLAH=BLUBB perl -e 'print $ENV{BLAH},"\n"'
BLUBB
$ echo $BLAH

$

alles klar?
Post by Florian von Savigny
aber das erklärt doch noch nicht, warum perl -d sich nicht um den
Krempel kümmert, wenn es ein separater Befehl ist. Oder?
Wie Du oben siehst, kümmert perl sich sehr wohl um den "Krempel".

Freundlicher Gruß
Martin

btw: Deine Uhr geht vor ;-)
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Florian von Savigny
2005-03-13 10:45:03 UTC
Permalink
Lieber Martin,

danke für Deine freundliche (und überaus rasche) Antwort. Ich kann
verstehen, daß man als hilfsbereiter Mensch genervt ist von Leuten,
die die Dokumentation nicht lesen und dann blöde Fragen stellen. Ich
weiß nur nicht, ob das nicht manchmal auch zu vorschnellen Reflexen
Post by Martin Kissner
$ BLAH=BLUBB perl -e 'print $ENV{BLAH},"\n"'
BLUBB
$ echo $BLAH
$
alles klar?
Ja ja, das schon; das wird ja durch die zitierte Passage erklärt.
Post by Martin Kissner
Wie Du oben siehst, kümmert perl sich sehr wohl um den "Krempel".
Das habe ich auch nicht gemeint. Gemeint habe ich, daß Perl sich
nicht um den "Krempel" kümmert, wenn die Umgebungsvariable /einzeln/
(ich habe von "separat" gesprochen) gesetzt wird (und nicht "privat"
nur für diesen Befehl):

$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'

$ echo $BLAH
BLUBB

echo kennt also die Umgebungsvariable, aber Perl nicht (was mich sehr
wundert, weil Umgebungsvariablen sonst immer zuverlässig im %ENV-Hash
aufzufinden sind). Und das verstehe ich nicht! Warum macht das für
Perl irgendeinen Unterschied? "Sieht" es in den beiden Fällen jeweils
etwas anderes?

Was mich vor allem beschäftigt, ist, ob hier die Bash den Unterschied
macht oder Perl.


PS. Danke für den Hinweis mit der Uhr!
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Marian Dubiel
2005-03-13 09:48:45 UTC
Permalink
Post by Martin Kissner
$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'
$ echo $BLAH
BLUBB
echo kennt also die Umgebungsvariable, aber Perl nicht (was mich sehr
wundert, weil Umgebungsvariablen sonst immer zuverlässig im %ENV-Hash
aufzufinden sind). Und das verstehe ich nicht! Warum macht das für
Perl irgendeinen Unterschied? "Sieht" es in den beiden Fällen jeweils
etwas anderes?
Du musst die Umgebungsvariable mit export exportieren, wenn sie an
Unterprozesse weitergegeben werden soll:

$ BLAH=BLUBB
$ export BLAH
$ perl -e 'print $ENV{BLAH},"\n"'
BLUBB
$ echo $BLAH
BLUBB

Das macht den Unterschied.

Marian Dubiel
Martin Kissner
2005-03-13 09:48:48 UTC
Permalink
Post by Florian von Savigny
danke für Deine freundliche (und überaus rasche) Antwort. Ich kann
verstehen, daß man als hilfsbereiter Mensch genervt ist von Leuten,
die die Dokumentation nicht lesen und dann blöde Fragen stellen.
Ich war doch nicht genervt - wie kommst Du darauf?
Post by Florian von Savigny
Post by Martin Kissner
Wie Du oben siehst, kümmert perl sich sehr wohl um den "Krempel".
Das habe ich auch nicht gemeint. Gemeint habe ich, daß Perl sich
nicht um den "Krempel" kümmert, wenn die Umgebungsvariable /einzeln/
(ich habe von "separat" gesprochen) gesetzt wird (und nicht "privat"
$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'
$ echo $BLAH
BLUBB
Du musst exportieren.
% echo $BLAH

% perl -e 'print $ENV{BLAH}."\n"'

% export BLAH=BLUBB
% echo $BLAH
BLUBB
% perl -e 'print $ENV{BLAH}."\n"'
BLUBB
Post by Florian von Savigny
Was mich vor allem beschäftigt, ist, ob hier die Bash den Unterschied
macht oder Perl.
Variablen müssen exportiert werden, damit sie für Childprozesse sichtbar
werden. Das ist eine Angelegenheit der Shell.

HTH
Freundlicher Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Martin Kissner
2005-03-13 09:53:37 UTC
Permalink
Post by Florian von Savigny
danke für Deine freundliche (und überaus rasche) Antwort. Ich kann
verstehen, daß man als hilfsbereiter Mensch genervt ist von Leuten,
die die Dokumentation nicht lesen und dann blöde Fragen stellen.
Ich war doch nicht genervt - wie kommst Du darauf?
Post by Florian von Savigny
Post by Martin Kissner
Wie Du oben siehst, kümmert perl sich sehr wohl um den "Krempel".
Das habe ich auch nicht gemeint. Gemeint habe ich, daß Perl sich
nicht um den "Krempel" kümmert, wenn die Umgebungsvariable /einzeln/
(ich habe von "separat" gesprochen) gesetzt wird (und nicht "privat"
$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'
$ echo $BLAH
BLUBB
Du musst exportieren.
% echo $BLAH

% perl -e 'print $ENV{BLAH}."\n"'

% export BLAH=BLUBB
% echo $BLAH
BLUBB
% perl -e 'print $ENV{BLAH}."\n"'
BLUBB
Post by Florian von Savigny
Was mich vor allem beschäftigt, ist, ob hier die Bash den Unterschied
macht oder Perl.
Variablen müssen exportiert werden, damit sie für Childshells sichtbar
werden. Das ist eine Angelegenheit der Shell.

HTH
Freundlicher Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Florian von Savigny
2005-03-14 10:51:09 UTC
Permalink
Post by Martin Kissner
Ich war doch nicht genervt - wie kommst Du darauf?
Das war eine Vermutung, mit der ich mir Deine Äußerungen erklären
wollte, die nahelegten, ich habe wohl entweder meine Behauptungen
nicht geprüft ("wie Du siehst, kümmert sich Perl sehr wohl um den
ganzen Krempel") bzw. nicht über Gelesenes nachgedacht ("damit ist
doch eigentlich schon alles gesagt").
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Martin Kissner
2005-03-14 15:52:30 UTC
Permalink
Post by Florian von Savigny
Post by Martin Kissner
Ich war doch nicht genervt - wie kommst Du darauf?
Das war eine Vermutung, mit der ich mir Deine Äußerungen erklären
wollte, die nahelegten, ich habe wohl entweder meine Behauptungen
nicht geprüft ("wie Du siehst, kümmert sich Perl sehr wohl um den
ganzen Krempel") bzw. nicht über Gelesenes nachgedacht ("damit ist
doch eigentlich schon alles gesagt").
Oh; war mir gar nicht aufgefallen, dass man das auch als "genervt"
interpretieren kann.
War nur freundlich und hilfsbereit gemeint - ohne Hintergedanken oder
Ironie ;-)

Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Florian von Savigny
2005-03-15 21:40:25 UTC
Permalink
Tja, so geht's manchmal, wenn man nur übers Netz kommuniziert; das ist
mir schon häufiger aufgefallen. Irgendwo habe ich wohl auch mal
gelesen, daß es nicht funktioniert, Arbeitsprojekte rein über Email zu
koordinieren - auf der zwischenmenschlichen Ebene gibt es irgendwie zu
viele Mißverständnisse.
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Tobias Bell
2005-03-13 09:53:54 UTC
Permalink
Post by Florian von Savigny
Das habe ich auch nicht gemeint. Gemeint habe ich, daß Perl sich
nicht um den "Krempel" kümmert, wenn die Umgebungsvariable /einzeln/
(ich habe von "separat" gesprochen) gesetzt wird (und nicht "privat"
$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'
Schau dir das mal an:
$ export BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"
BLUB
Post by Florian von Savigny
$ echo $BLAH
BLUBB
Das funktioniert identisch.
Post by Florian von Savigny
echo kennt also die Umgebungsvariable, aber Perl nicht (was mich sehr
wundert, weil Umgebungsvariablen sonst immer zuverlässig im %ENV-Hash
aufzufinden sind). Und das verstehe ich nicht! Warum macht das für
Perl irgendeinen Unterschied? "Sieht" es in den beiden Fällen jeweils
etwas anderes?
In deinem Beispiel ist BLAH keine Umgebungsvariable. Daher kann perl sie
auch nicht finden. Die Aufrufmimik
var=value command
dient dazu nur für den Aufruf von command die Umgebungsvariable zu
verändern und anschließend die alten Umgebungsvariablen zu nutzen.
Post by Florian von Savigny
Was mich vor allem beschäftigt, ist, ob hier die Bash den Unterschied
macht oder Perl.
Mach dir den Unterschied zwischen Umgebungsvariable und lokaler
Shellvariable klar.
Post by Florian von Savigny
PS. Danke für den Hinweis mit der Uhr!
MfG Tobias
Hauke Laging
2005-03-13 12:42:18 UTC
Permalink
Post by Martin Kissner
$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'
$ echo $BLAH
BLUBB
echo kennt also die Umgebungsvariable, aber Perl nicht
echo "kennt" die Variable zwar, aber das hat mir der Ausgabe nichts
zu tun: Das $BLAH wird von der SHELL ersetzt, und zwar VOR dem
Aufruf von echo. echo ist ein Shell-Builtin, so dass zur Ausführung
kein neues Environment aufgebaut wird, daher WÄRE das mit dem Export
egal (wenn denn echo auf Umgebungsvariablen zurückgriffe).


CU

Hauke
--
Neues Konzept gegen Phishing - Kommentare erbeten
http://www.hauke-laging.de/reccookies/
----------------
Wie können 59.054.087 Leute nur so dumm sein?
Martin Kissner
2005-03-13 13:48:16 UTC
Permalink
Post by Hauke Laging
Post by Martin Kissner
$ BLAH=BLUBB
$ perl -e 'print $ENV{BLAH},"\n"'
$ echo $BLAH
BLUBB
echo kennt also die Umgebungsvariable, aber Perl nicht
echo "kennt" die Variable zwar, aber das hat mir der Ausgabe nichts
zu tun: Das $BLAH wird von der SHELL ersetzt, und zwar VOR dem
Aufruf von echo. echo ist ein Shell-Builtin, so dass zur Ausführung
kein neues Environment aufgebaut wird, daher WÄRE das mit dem Export
egal (wenn denn echo auf Umgebungsvariablen zurückgriffe).
Das hat nicht unbedingt was damit zu tun, dass echo ein Shell-builtin
ist.
/bin/echo reagiert genauso:

% TEST=BLUBB
% /bin/echo $TEST
BLUBB

Freundlicher Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Hauke Laging
2005-03-13 14:56:19 UTC
Permalink
Post by Martin Kissner
Das hat nicht unbedingt was damit zu tun, dass echo ein
Shell-builtin ist.
% TEST=BLUBB
% /bin/echo $TEST
BLUBB
Ja, natürlich, weil die AUFRUFENDE SHELL das $TEST interpretiert. Die
Programme "sehen"

echo BLUBB
bzw.
/bin/echo BLUBB

Da ist übrhaupt nichts mit Umgebungsvariablen - aus Sicht von
echo/ /bin/echo.


CU

Hauke
--
Neues Konzept gegen Phishing - Kommentare erbeten
http://www.hauke-laging.de/reccookies/
----------------
Wie können 59.054.087 Leute nur so dumm sein?
Hauke Laging
2005-03-13 02:14:25 UTC
Permalink
Post by Florian von Savigny
Merkwürdig ist auch, daß das einfache Setzen der Variablen und
anschließende Aufrufen des Befehls nicht funktioniert, egal, ob man
jetzt in die obige Zeile ein Semikolon einfügt oder beides
hintereinander aufruft.
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.


CU

Hauke
--
Neues Konzept gegen Phishing - Kommentare erbeten
http://www.hauke-laging.de/reccookies/
----------------
Wie können 59.054.087 Leute nur so dumm sein?
Florian von Savigny
2005-03-13 10:47:18 UTC
Permalink
Post by Hauke Laging
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.
Aber das heißt doch, daß die Zuweisung MIT Semikolon AUCH auf das
Environment jedes folgenden Kommandos wirken sollte, oder (s. das
Beispiel in meinem Follow-Up auf Martins Beitrag)?
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Martin Kissner
2005-03-13 09:52:38 UTC
Permalink
Post by Florian von Savigny
Post by Hauke Laging
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.
Aber das heißt doch, daß die Zuweisung MIT Semikolon AUCH auf das
Environment jedes folgenden Kommandos wirken sollte, oder (s. das
Beispiel in meinem Follow-Up auf Martins Beitrag)?
Ein Skript (egal ob ein Shellskript oder ein perlskript) läuft in einer
eigenen Umgebung.

Freundlicher Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Thorsten Kampe
2005-03-13 11:39:04 UTC
Permalink
Post by Hauke Laging
Post by Florian von Savigny
Merkwürdig ist auch, daß das einfache Setzen der Variablen und
anschließende Aufrufen des Befehls nicht funktioniert, egal, ob man
jetzt in die obige Zeile ein Semikolon einfügt oder beides
hintereinander aufruft.
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.
Ganz so einfach (zu verstehen) ist es auch nicht:
% TEST=123 echo $TEST
%


Thorsten
Hauke Laging
2005-03-13 12:36:00 UTC
Permalink
Post by Thorsten Kampe
% TEST=123 echo $TEST
Verstehst Du das jetzt nicht, oder wolltest Du nur darauf hinweisen,
dass das Beispiel Anfänger durchaus verwirren kann?


CU

Hauke
--
Neues Konzept gegen Phishing - Kommentare erbeten
http://www.hauke-laging.de/reccookies/
----------------
Wie können 59.054.087 Leute nur so dumm sein?
Thorsten Kampe
2005-03-13 19:37:49 UTC
Permalink
Post by Hauke Laging
Post by Thorsten Kampe
% TEST=123 echo $TEST
Verstehst Du das jetzt nicht, oder wolltest Du nur darauf hinweisen,
dass das Beispiel Anfänger durchaus verwirren kann?
Eigentlich letzteres aber wenn ich's mir genau ueberlege, weiss ich
zwar, dass es so ist, aber nicht warum.

Thorsten
Erkan Yanar
2005-03-13 12:42:56 UTC
Permalink
Post by Thorsten Kampe
Post by Hauke Laging
Post by Florian von Savigny
Merkwürdig ist auch, daß das einfache Setzen der Variablen und
anschließende Aufrufen des Befehls nicht funktioniert, egal, ob man
jetzt in die obige Zeile ein Semikolon einfügt oder beides
hintereinander aufruft.
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.
% TEST=123 echo $TEST
%
Und wo ist da die Subshell? Wann wied $TEST geparst?
Antworten und lernen.

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Thorsten Kampe
2005-03-13 19:48:02 UTC
Permalink
Post by Erkan Yanar
Post by Thorsten Kampe
Post by Hauke Laging
Post by Florian von Savigny
Merkwürdig ist auch, daß das einfache Setzen der Variablen und
anschließende Aufrufen des Befehls nicht funktioniert, egal, ob man
jetzt in die obige Zeile ein Semikolon einfügt oder beides
hintereinander aufruft.
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.
% TEST=123 echo $TEST
%
Und wo ist da die Subshell?
Subshell? Ich sehe nur die Struktur "VAR=value command". Ob da eine
Subshell aufgerufen wird, kann ich normalerweise nicht voraussagen.

Zum Beispiel 'ACCEPT_KEYWORDS="~x86" emerge python' funktioniert. Aber
auch nur, weil ich es weiss. Ausserdem ist mir nicht klar, warum auch

% TEST=123 echo $TEST
% echo $TEST
%
Post by Erkan Yanar
Wann wied $TEST geparst?
Nach dem TEST=123? Ist aber ein bisschen schwach, dass man das wissen
muss, um es zu verstehen.

Thorsten
Erkan Yanar
2005-03-13 20:41:04 UTC
Permalink
[snip]
Post by Thorsten Kampe
Post by Erkan Yanar
Post by Thorsten Kampe
% TEST=123 echo $TEST
%
Und wo ist da die Subshell?
Subshell? Ich sehe nur die Struktur "VAR=value command". Ob da eine
Subshell aufgerufen wird, kann ich normalerweise nicht voraussagen.
Zum Beispiel 'ACCEPT_KEYWORDS="~x86" emerge python' funktioniert. Aber
auch nur, weil ich es weiss. Ausserdem ist mir nicht klar, warum auch
% TEST=123 echo $TEST
% echo $TEST
%
Post by Erkan Yanar
Wann wied $TEST geparst?
Nach dem TEST=123? Ist aber ein bisschen schwach, dass man das wissen
muss, um es zu verstehen.
So mein lieber Thorsten, ich denke mal es gibt nicht viele, die sich für
deine Beschränktheit interessieren. Du kannst es schwach, bescheuert
oder zum Würgen finden. Als Meinungsäußerung sei es Dir auch unbenommen.

Aber bitte woanders.

fup2 dag
--
über den grenzen muß die freiheit wohl wolkenlos sein
Thorsten Kampe
2005-03-13 21:05:54 UTC
Permalink
Post by Erkan Yanar
Post by Thorsten Kampe
Post by Erkan Yanar
Post by Thorsten Kampe
% TEST=123 echo $TEST
%
Und wo ist da die Subshell?
Subshell? Ich sehe nur die Struktur "VAR=value command". Ob da eine
Subshell aufgerufen wird, kann ich normalerweise nicht voraussagen.
Zum Beispiel 'ACCEPT_KEYWORDS="~x86" emerge python' funktioniert. Aber
auch nur, weil ich es weiss. Ausserdem ist mir nicht klar, warum auch
% TEST=123 echo $TEST
% echo $TEST
%
Post by Erkan Yanar
Wann wied $TEST geparst?
Nach dem TEST=123? Ist aber ein bisschen schwach, dass man das wissen
muss, um es zu verstehen.
So mein lieber Thorsten, ich denke mal es gibt nicht viele, die sich für
deine Beschränktheit interessieren. Du kannst es schwach, bescheuert
oder zum Würgen finden. Als Meinungsäußerung sei es Dir auch unbenommen.
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.

Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.


Thorsten
Erkan Yanar
2005-03-13 21:42:45 UTC
Permalink
Post by Thorsten Kampe
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.
Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.
Normatives Gelaber, der Spiegel sei dein Zuhörer. Zudem kannst Du gerne
deine Nase bunt anmalen und die Welt strahlt in deinen Farben.

Du scheinst kognitive Schwächen zu haben und ich keine Zeit für eine
Analyse. In der modernen Psychiatrie verschreibt man gerne Blocker etc.
keine Lösung aber eine Hilfe.

Nichts desto trotz an einem anderen Ort, wie z.B. der Spiegel. Also mach
die Tür es zieht.

fup2dag
^-> Wenn Du wirklich nicht von der Tastatur lassen kannst!
--
über den grenzen muß die freiheit wohl wolkenlos sein
Erkan Yanar
2005-03-13 22:20:51 UTC
Permalink
Post by Thorsten Kampe
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.
Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.
Normatives Gelaber, der Spiegel sei dein Zuhörer. Zudem kannst Du gerne
deine Nase bunt anmalen und die Welt strahlt in deinen Farben.

Du scheinst kognitive Schwächen zu haben und ich keine Zeit für eine
Analyse. In der modernen Psychiatrie verschreibt man gerne Blocker etc.
Keine Lösung, aber eine Hilfe.

Nichts desto trotz an einem anderen Ort, wie z.B. der Spiegel. Also mach
die Tür zu es zieht.

fup2dag
^-> Wenn Du wirklich nicht von der Tastatur lassen kannst!
--
über den grenzen muß die freiheit wohl wolkenlos sein
Thorsten Kampe
2005-03-14 10:02:44 UTC
Permalink
Post by Erkan Yanar
Post by Thorsten Kampe
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.
Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.
Normatives Gelaber, der Spiegel sei dein Zuhörer. Zudem kannst Du gerne
deine Nase bunt anmalen und die Welt strahlt in deinen Farben.
Du scheinst kognitive Schwächen zu haben und ich keine Zeit für eine
Analyse. In der modernen Psychiatrie verschreibt man gerne Blocker etc.
Keine Lösung, aber eine Hilfe.
Nichts desto trotz an einem anderen Ort, wie z.B. der Spiegel. Also mach
die Tür zu es zieht.
fup2dag
^-> Wenn Du wirklich nicht von der Tastatur lassen kannst!
Post by Thorsten Kampe
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.
Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.
Normatives Gelaber, der Spiegel sei dein Zuhörer. Zudem kannst Du gerne
deine Nase bunt anmalen und die Welt strahlt in deinen Farben.
Hast du eigentlich irgendetwas zum Thema zu sagen ausser "das haengt
irgendwie damit zusammen wie die Shell parst"?
Post by Erkan Yanar
Du scheinst kognitive Schwächen zu haben und ich keine Zeit für eine
Analyse. In der modernen Psychiatrie verschreibt man gerne Blocker etc.
Keine Lösung, aber eine Hilfe.
Nichts desto trotz an einem anderen Ort, wie z.B. der Spiegel. Also mach
die Tür zu es zieht.
fup2dag
^-> Wenn Du wirklich nicht von der Tastatur lassen kannst!
Das scheint deine bevorzugte Gruppe zu sein?!

Ich darf nur 'mal festhalten: ich bin "beschraenkt", ein
"Gruppenkasper" und reif fuer die Psychatrie. Schoen, dass deine
Tastatur so geduldig ist. Un4ter vier Augen wuerdest du dich nicht
trauen, mir das zu sagen. Oder genau einmal. Und daran wuerden auch
"deine Brueder" nichts aendern.
Erkan Yanar
2005-03-14 17:29:10 UTC
Permalink
[unfähiges Quoting]
Post by Thorsten Kampe
Hast du eigentlich irgendetwas zum Thema zu sagen ausser "das haengt
irgendwie damit zusammen wie die Shell parst"?
Ist schon mal ein guter Tipp. Wo Du das irgendwie her hast will niemand
wissen. Was hälst Du davon in Zukunft einfach mal anständig zu fragen
anstatt rumzublöken, das es doof ist. Niemand zwingt Dich die Shell auch
zu nutzen. Wir können hier aber wirklich niemanden gebrauchen, der das
mit der Shell doof findet.
Gehe doch dahin wo man Dir nicht soviel abverlangt!
Post by Thorsten Kampe
Post by Erkan Yanar
Du scheinst kognitive Schwächen zu haben und ich keine Zeit für eine
Analyse. In der modernen Psychiatrie verschreibt man gerne Blocker etc.
Keine Lösung, aber eine Hilfe.
Nichts desto trotz an einem anderen Ort, wie z.B. der Spiegel. Also mach
die Tür zu es zieht.
fup2dag
^-> Wenn Du wirklich nicht von der Tastatur lassen kannst!
Das scheint deine bevorzugte Gruppe zu sein?!
Das Newsnet braucht seine Ordnung das stimmt und Du bist hier der
Schmutzfink. Dort wärst du nicht allein.
Post by Thorsten Kampe
Ich darf nur 'mal festhalten: ich bin "beschraenkt", ein
"Gruppenkasper" und reif fuer die Psychatrie. Schoen, dass deine
Tastatur so geduldig ist. Un4ter vier Augen wuerdest du dich nicht
trauen, mir das zu sagen. Oder genau einmal. Und daran wuerden auch
"deine Brueder" nichts aendern.
Hilfe ich hole gleich die Knoblauchwurst.

fup2p

Mit Dir wird das nichts
--
über den grenzen muß die freiheit wohl wolkenlos sein
Helmut Hullen
2005-03-14 18:56:00 UTC
Permalink
Hallo, Erkan,
Post by Erkan Yanar
Niemand zwingt Dich
die Shell auch zu nutzen. Wir können hier aber wirklich niemanden
gebrauchen, der das mit der Shell doof findet.
"wir"?
Du leidest hoffentlich nicht an multipler Schizophrenie.

Nur so als Anregung: such mal nach Gunnar Ritter.

Viele Grüße!
Helmut
Erkan Yanar
2005-03-14 19:41:50 UTC
Permalink
Post by Helmut Hullen
Hallo, Erkan,
Post by Erkan Yanar
Niemand zwingt Dich
die Shell auch zu nutzen. Wir können hier aber wirklich niemanden
gebrauchen, der das mit der Shell doof findet.
"wir"?
Du leidest hoffentlich nicht an multipler Schizophrenie.
Hast Du noch Tabletten über?
Post by Helmut Hullen
Nur so als Anregung: such mal nach Gunnar Ritter.
Und warum kommt jetzt das Dos-Hullenchen hervorgekrochen?
--
über den grenzen muß die freiheit wohl wolkenlos sein
Erkan Yanar
2005-03-14 19:54:48 UTC
Permalink
Post by Helmut Hullen
Hallo, Erkan,
Post by Erkan Yanar
Niemand zwingt Dich
die Shell auch zu nutzen. Wir können hier aber wirklich niemanden
gebrauchen, der das mit der Shell doof findet.
"wir"?
Du leidest hoffentlich nicht an multipler Schizophrenie.
Habt Ihr noch Tabletten über?
Post by Helmut Hullen
Nur so als Anregung: such mal nach Gunnar Ritter.
Und warum kommt jetzt das Dos-Hullenchen hervorgekrochen?
--
über den grenzen muß die freiheit wohl wolkenlos sein
Reinhold Birkenfeld
2005-03-13 22:25:31 UTC
Permalink
Post by Thorsten Kampe
Post by Erkan Yanar
Post by Thorsten Kampe
Post by Erkan Yanar
Post by Thorsten Kampe
% TEST=123 echo $TEST
%
Und wo ist da die Subshell?
Subshell? Ich sehe nur die Struktur "VAR=value command". Ob da eine
Subshell aufgerufen wird, kann ich normalerweise nicht voraussagen.
Zum Beispiel 'ACCEPT_KEYWORDS="~x86" emerge python' funktioniert. Aber
auch nur, weil ich es weiss. Ausserdem ist mir nicht klar, warum auch
% TEST=123 echo $TEST
% echo $TEST
%
Post by Erkan Yanar
Wann wied $TEST geparst?
Nach dem TEST=123? Ist aber ein bisschen schwach, dass man das wissen
muss, um es zu verstehen.
So mein lieber Thorsten, ich denke mal es gibt nicht viele, die sich für
deine Beschränktheit interessieren. Du kannst es schwach, bescheuert
oder zum Würgen finden. Als Meinungsäußerung sei es Dir auch unbenommen.
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.
Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.
Der einzige Haken: Wann Parameter Substitution durchgeführt wird, ist
kein Implementierungsdetail, sondern ein Merkmal der Sprache an sich.

Reinhold
Thorsten Kampe
2005-03-14 09:17:38 UTC
Permalink
Post by Reinhold Birkenfeld
Post by Thorsten Kampe
Post by Erkan Yanar
Post by Thorsten Kampe
Post by Erkan Yanar
Post by Thorsten Kampe
% TEST=123 echo $TEST
%
Und wo ist da die Subshell?
Subshell? Ich sehe nur die Struktur "VAR=value command". Ob da eine
Subshell aufgerufen wird, kann ich normalerweise nicht voraussagen.
Zum Beispiel 'ACCEPT_KEYWORDS="~x86" emerge python' funktioniert. Aber
auch nur, weil ich es weiss. Ausserdem ist mir nicht klar, warum auch
% TEST=123 echo $TEST
% echo $TEST
%
Post by Erkan Yanar
Wann wied $TEST geparst?
Nach dem TEST=123? Ist aber ein bisschen schwach, dass man das wissen
muss, um es zu verstehen.
So mein lieber Thorsten, ich denke mal es gibt nicht viele, die sich für
deine Beschränktheit interessieren. Du kannst es schwach, bescheuert
oder zum Würgen finden. Als Meinungsäußerung sei es Dir auch unbenommen.
Schon wieder das Kindergarten-Theater mit den Shelldeppen. Ist aber
typisch.
Implementierungsdetails sollten fuer das Verstaendnis der Basis-Syntax
einer Programmier- oder Skript-Sprache eigentlich unwichtig sein.
Wirst du aber sowieso nie verstehen.
Der einzige Haken: Wann Parameter Substitution durchgeführt wird, ist
kein Implementierungsdetail, sondern ein Merkmal der Sprache an sich.
Das ist richtig. Wann aber in welcher Shell welche Substitution in
welcher Reihenfolge durchgefuehrt wird, /sollte/ fuer das Verstaendnis
(oder die "Vorhersagbarkeit") solch einfacher Sprachkonstrukte wie
"VAR=value command" nicht erforderlich sein.

Mal ganz abgesehen davon, dass EY offensichtlich auch keine Ahnung hat
("haengt irgendwie mit der Reihenfolge des Parsens zusammen"),
erklaert es auch nichts.

Wenn zum Beispiel erst die ganze Befehlszeile ersetzt wuerde, dann
waere klar, dass die Shell "TEST=123 echo $TEST" zu "TEST=123 echo"
macht. Dann duerfte aber auch

"TEST=123; echo $TEST" zu "TEST=123; echo" werden. Das heisst so eine
kleine Zeile zieht einen Rattenschwanz an Erklaerungen hinter sich
her, der mehr Fragen aufwirft als erklaert. Das beste ist, man
akzeptiert einfach, dass es so ist.

Thorsten
Erkan Yanar
2005-03-14 18:15:57 UTC
Permalink
[snip]
Post by Thorsten Kampe
Post by Reinhold Birkenfeld
Der einzige Haken: Wann Parameter Substitution durchgeführt wird, ist
kein Implementierungsdetail, sondern ein Merkmal der Sprache an sich.
Das ist richtig. Wann aber in welcher Shell welche Substitution in
welcher Reihenfolge durchgefuehrt wird, /sollte/ fuer das Verstaendnis
(oder die "Vorhersagbarkeit") solch einfacher Sprachkonstrukte wie
"VAR=value command" nicht erforderlich sein.
Anscheinend ist es eben nicht einfach!
Post by Thorsten Kampe
Mal ganz abgesehen davon, dass EY offensichtlich auch keine Ahnung hat
("haengt irgendwie mit der Reihenfolge des Parsens zusammen"),
erklaert es auch nichts.
Aua muss das wehtun. Hast Du irgend einen Ausgleichssport?
Post by Thorsten Kampe
Wenn zum Beispiel erst die ganze Befehlszeile ersetzt wuerde, dann
waere klar, dass die Shell "TEST=123 echo $TEST" zu "TEST=123 echo"
macht. Dann duerfte aber auch
"TEST=123; echo $TEST" zu "TEST=123; echo" werden.
Mit welcher Logik ist bei Dir beides da oben äquivalent?
Stell richtige Fragen .. besser lese Dir erst mal etwas Wissen an ..
noch besser tschüss .. bevor Du hier heiteres Beruferaten machst.

pfft
--
über den grenzen muß die freiheit wohl wolkenlos sein
Mathias Pohl
2005-03-14 19:15:43 UTC
Permalink
Post by Erkan Yanar
Wann wied $TEST geparst?
[ ] Du weißt, was "parsen" bedeutet.
Post by Erkan Yanar
Antworten und lernen.
[ ] Du weißt, dass deine Frage nicht zu beantworten ist.


HTH und Gruß,
Mathias
Erkan Yanar
2005-03-14 19:33:58 UTC
Permalink
Post by Mathias Pohl
Post by Erkan Yanar
Wann wied $TEST geparst?
[ ] Du weißt, was "parsen" bedeutet.
Stimmt Expansion wäre korrekt gewesen.
Post by Mathias Pohl
Post by Erkan Yanar
Antworten und lernen.
[ ] Du weißt, dass deine Frage nicht zu beantworten ist.
Stimmt nicht.

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Mathias Pohl
2005-03-14 19:45:12 UTC
Permalink
Post by Erkan Yanar
Post by Mathias Pohl
[ ] Du weißt, dass deine Frage nicht zu beantworten ist.
Stimmt nicht.
Hast recht. Die Antwort auf die entsprechende Frage wäre "nie" gewesen.

Gruß,
Mathias
Erkan Yanar
2005-03-14 20:20:29 UTC
Permalink
Post by Mathias Pohl
Post by Erkan Yanar
Post by Mathias Pohl
[ ] Du weißt, dass deine Frage nicht zu beantworten ist.
Stimmt nicht.
Hast recht. Die Antwort auf die entsprechende Frage wäre "nie" gewesen.
lol

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Reinhold Birkenfeld
2005-03-13 17:53:27 UTC
Permalink
Post by Thorsten Kampe
Post by Hauke Laging
Post by Florian von Savigny
Merkwürdig ist auch, daß das einfache Setzen der Variablen und
anschließende Aufrufen des Befehls nicht funktioniert, egal, ob man
jetzt in die obige Zeile ein Semikolon einfügt oder beides
hintereinander aufruft.
Ohne Semikolon wirkt die Variablenzuweisung nur auf das Environment
des Kommandos, mit Semikolon findet sie im Kontext der laufenden
Shell statt.
% TEST=123 echo $TEST
%
Meinst du jetzt

% TEST=x sh -c 'echo $TEST'

?

Reinhold
Erkan Yanar
2005-03-13 13:00:04 UTC
Permalink
Liebes Archiv,
es folgt eine kleine Geschichte.

Das klassische auf dem Forking aufbauende Konzept der Prozesserstellung
kennt unter Unix zwei Variablentypen. Jene die nur der Prozess/Shell
kennt, was meint beim Erstellen eines neuen Subprozesses/Shell bekommt
der neue Prozess diese nicht mit.
Der andere Variablentyp ist der zum exportieren gekennzeichnete. Neu
erstellte Prozesse bekommen die (zum "Export" freigegebene )Umgebung
des aufrufenden Prozess als eigene Umgebung mit. Solche Variablen werden
mit .. na .. richtig, mit export gekennzeichnet.
Mit diesem Konzept ist es nicht möglich Variablen in die Umgebung des
aufgerufenen Prozesses/Shell zu schreiben die *nur* für den aufgerufenen
Prozess gelten.
Wenn da nicht diese Zuweisungssyntax¹ wäre. Diese schreibt *nur* in die
Umgebung des aufgerufenes Prozesses die Variable, ohne daß die
aufrufende Shell davon etwas "behält".


tschazu
erkan


1:= varible=zuweisung am Anfang der Zeile ohne abschließendes Semikolon
--
über den grenzen muß die freiheit wohl wolkenlos sein
Florian von Savigny
2005-03-15 22:02:23 UTC
Permalink
Ich versuch mal, zusammenzufassen, was ich verstanden habe:

1. jede Shell hat ihre eigene Umgebung. Alle Variablen, die in ihr
gesetzt worden sind, ohne exportiert worden zu sein, sind auch nur
in ihr sichtbar, oder umgekehrt, Variablen, die in anderen Shells
gesetzt worden sind, ohne exportiert worden zu sein, sind in ihr
nicht sichtbar. [das wußte ich zwar schon, aber das ist ja die
Grundlage]

2. jeder Befehl, der in einer Shell ausgeführt wird, wird in Wahrheit
in einer Subshell ausgeführt; das sieht man nur nicht. Punkt 1 gilt
entsprechend. Argumente werden jedoch zunächst von der Eltern-Shell
geparst, bevor sie an den Befehl übergeben werden.

3. das Konstrukt, wegen dem ich hier gefragt habe, hat die Aufgabe,
Variablen in der in Punkt 2 genannten Subshell zu setzen, und
nirgendwo anders.

Ist das korrekt so?


PS: Ich bin bestürzt über den Umgangston hier. Ich weiß, daran ist im
Zweifel immer der andere schuld, aber vielleicht könnten alle die, die
sich hier offenbar routinemäßig beharken, stattdessen einfach bei der
Sache bleiben? Und Persönliches (kann man im Netz sowieso nicht
wirklich transportieren!) außen vor lassen? - Nichtsdestotrotz danke
ich natürlich auch ihnen für ihre Hinweise.
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Reinhold Birkenfeld
2005-03-15 21:07:36 UTC
Permalink
Post by Florian von Savigny
1. jede Shell hat ihre eigene Umgebung. Alle Variablen, die in ihr
gesetzt worden sind, ohne exportiert worden zu sein, sind auch nur
in ihr sichtbar, oder umgekehrt, Variablen, die in anderen Shells
gesetzt worden sind, ohne exportiert worden zu sein, sind in ihr
nicht sichtbar. [das wußte ich zwar schon, aber das ist ja die
Grundlage]
2. jeder Befehl, der in einer Shell ausgeführt wird, wird in Wahrheit
in einer Subshell ausgeführt; das sieht man nur nicht.
Nö. Aber jeder Prozess hat ein Environment, da braucht es keine Shell dazu.
Post by Florian von Savigny
Punkt 1 gilt
entsprechend. Argumente werden jedoch zunächst von der Eltern-Shell
geparst, bevor sie an den Befehl übergeben werden.
s/Eltern-Shell/Shell/
Post by Florian von Savigny
3. das Konstrukt, wegen dem ich hier gefragt habe, hat die Aufgabe,
Variablen in der in Punkt 2 genannten Subshell zu setzen, und
nirgendwo anders.
Nein, es setzt diese im Environment des aufgerufenen Prozesses, und
nirgendwo anders.
Post by Florian von Savigny
PS: Ich bin bestürzt über den Umgangston hier. Ich weiß, daran ist im
Zweifel immer der andere schuld, aber vielleicht könnten alle die, die
sich hier offenbar routinemäßig beharken, stattdessen einfach bei der
Sache bleiben? Und Persönliches (kann man im Netz sowieso nicht
wirklich transportieren!) außen vor lassen? - Nichtsdestotrotz danke
ich natürlich auch ihnen für ihre Hinweise.
Hier ist Usenet, und zwar eine technische Gruppe. Außerdem ist es
schwierig, bei der Sache zu bleiben, wenn Leute teilweise nicht nur die
Meinung der anderen, sondern auch harte Fakten in Frage stellen.

Reinhold
Florian von Savigny
2005-03-16 22:20:47 UTC
Permalink
Post by Reinhold Birkenfeld
Nö. Aber jeder Prozess hat ein Environment, da braucht es keine Shell dazu.
s/Eltern-Shell/Shell/
Nein, es setzt diese im Environment des aufgerufenen Prozesses, und
nirgendwo anders.
Hmm. Ich habe jetzt nochmal meine Bücher gewälzt, wo diese Sache mit
dem Geltungsbereich der Variablen immer ziemlich selbstverständlich
nebenbei abgehandelt wird. Mir scheint, daß der Name des Befehls
"export" an meiner Desorientierung schuld ist: mir war nie klar, daß
"exportieren" eher so was ist wie "vererben", d. h. sich immer nur auf
die eigenen Kinder bezieht. Bisher hatte ich tatsächlich
stillschweigend angenommen, daß durch "exportieren" eine Variable
überall im System sichtbar wird - einfach nur deswegen, weil
"exportieren" ja "nach außen tragen" heißt. Dieser Vorstellung nach
hat es für mich bisher auch nur eine einzige Umgebung gegeben (ich
kann's mir schon denken: technisch ist das wahrscheinlich hochgradig
naiv). Jetzt verstehe ich, daß "Umgebung" vielmehr das ist, was von
einer Shell an ihre Kinder weitergegeben (nämlich "exportiert") wird -
zwar häufig identisch mit der Umgebung, die sie von ihrem Elternprozeß
mitbekommen hat, aber sie kann diese eben auch verändert haben.

Vielen Dank für die Klarstellung.

[Irgendwie unheimlich finde ich das mit den Umgebungsvariablen
übrigens auch, aber das ist nur so eine Bemerkung am Rande: Das
Environment wäre ja ohne Shell(s) überhaupt nicht da, aber es scheint
ja auch ohne sie "vererbt" zu werden: wenn ich z. B. aus einer
Emacs-Funktion mit (call-process ...) ein Perl-Skript starte, dann
erbt Emacs es von seiner Shell und das Perl-Skript von Emacs.]
Post by Reinhold Birkenfeld
Hier ist Usenet, und zwar eine technische Gruppe.
/Dieser/ Satz erklärt für mich nun ehrlich gesagt gar nichts, eher im
Gegenteil. Ich dachte, es gebe so etwas wie eine Netiquette?
Post by Reinhold Birkenfeld
Außerdem ist es schwierig, bei der Sache zu bleiben, wenn Leute
teilweise nicht nur die Meinung der anderen, sondern auch harte
Fakten in Frage stellen.
Mag sein, das kann ich natürlich nicht beurteilen. Aber z. B. Dir
selbst ist das in diesem Thread doch geradezu vorbildlich gelungen.
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Reinhold Birkenfeld
2005-03-16 21:30:51 UTC
Permalink
Post by Florian von Savigny
[Irgendwie unheimlich finde ich das mit den Umgebungsvariablen
übrigens auch, aber das ist nur so eine Bemerkung am Rande: Das
Environment wäre ja ohne Shell(s) überhaupt nicht da, aber es scheint
ja auch ohne sie "vererbt" zu werden: wenn ich z. B. aus einer
Emacs-Funktion mit (call-process ...) ein Perl-Skript starte, dann
erbt Emacs es von seiner Shell und das Perl-Skript von Emacs.]
Das Environment ist auch von der Shell unabhängig. Jeder Prozess hat
eines und vererbt dieses an seinen Kindprozess, wenn er einen erzeugt
(genauer: das aktuelle Environment wird bei fork() kopiert).

D.h., init fängt mit einem leeren Environment an und jeder Kindprozess
im Prozessbaum kann etwas hinzufügen und an seine Kinder weitergeben.

Bei der Shell ist das ganze eine Stufe komplizierter, weil es auch
sowohl Shellvariablen gibt als auch Environmentvariablen (letztere
werden eben mit 'export' definiert). Nur die Environmentvariablen werden
dann auch kopiert.

Reinhold
Erkan Yanar
2005-03-17 00:18:17 UTC
Permalink
Am 15 Mar 2005 23:02:23 +0100,schrieb Florian von Savigny :
[snip]
Post by Florian von Savigny
2. jeder Befehl, der in einer Shell ausgeführt wird, wird in Wahrheit
in einer Subshell ausgeführt; das sieht man nur nicht. Punkt 1 gilt
entsprechend. Argumente werden jedoch zunächst von der Eltern-Shell
geparst, bevor sie an den Befehl übergeben werden.
Eben nicht jeder Befehl. Bei Funktionen und Builtins nicht.
Post by Florian von Savigny
3. das Konstrukt, wegen dem ich hier gefragt habe, hat die Aufgabe,
Variablen in der in Punkt 2 genannten Subshell zu setzen, und
nirgendwo anders.
Ist das korrekt so?
Formulieren wir es mal so, bei einer Subshell bist Du fein raus und
musst Dir keine "Sorgen" machen. Bei Builtins würde ich vom Benutzen
abraten.
Was macht ein HOME=/tmp cd? Oder ZZZ=ZZZ set? Klassische Builtins.
Das verhalten ist von Shell zu Shell unterschiedlich. Die einzig
"sinnige" Verwendung (die mir jetzt einfällt) ist das Setzen des IFS für
read.
Post by Florian von Savigny
PS: Ich bin bestürzt über den Umgangston hier. Ich weiß, daran ist im
Zweifel immer der andere schuld, aber vielleicht könnten alle die, die
sich hier offenbar routinemäßig beharken, stattdessen einfach bei der
Sache bleiben? Und Persönliches (kann man im Netz sowieso nicht
wirklich transportieren!) außen vor lassen? - Nichtsdestotrotz danke
ich natürlich auch ihnen für ihre Hinweise.
LAB&TYD
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Florian von Savigny
2005-03-17 18:03:27 UTC
Permalink
Post by Erkan Yanar
Post by Florian von Savigny
2. jeder Befehl, der in einer Shell ausgeführt wird, wird in Wahrheit
in einer Subshell ausgeführt;
Eben nicht jeder Befehl. Bei Funktionen und Builtins nicht.
Das scheint auch ein interessanter Aspekt zu sein. Reinhold und Du
differieren zwar inhaltlich in dem Punkt, ob hier eine eigene Subshell
gestartet wird, wie ich gemutmaßt habe, oder nur jeder Subprozeß der
Shell ein eigenes Environment hat (wenn ich mir die Ausgabe von
"pstree" anschaue, müßte ich übrigens Reinhold Recht geben).

Aber an Deiner Empfehlung ändert das, vermute ich, gar nichts;
vermutlich würde Reinhold lediglich sagen, daß Shellfunktionen und
Builtins kein eigenes Environment haben ...
Post by Erkan Yanar
Formulieren wir es mal so, bei einer Subshell bist Du fein raus und
musst Dir keine "Sorgen" machen. Bei Builtins würde ich vom Benutzen
abraten.
Was macht ein HOME=/tmp cd? Oder ZZZ=ZZZ set? Klassische Builtins.
Das verhalten ist von Shell zu Shell unterschiedlich. Die einzig
"sinnige" Verwendung (die mir jetzt einfällt) ist das Setzen des IFS für
read.
... bzw., daß das jede Shell anders handhabt, und daß man deswegen
davon absehen sollte, dieses spezielle Zuweisungskonstrukt für
Shellfunktionen und Builtins zu verwenden.
Post by Erkan Yanar
LAB&TYD
Tut mir leid, der wtf("what the fuck [is]")-Befehl auf meinem System,
der, soweit ich weiß, nur englische Usenet-Jargon-Kürzel
entschlüsselt, kapituliert hier - was heißt das beides? Etwa "lachend
auf dem Bauch", "liege auf dem Boden", oder so was (zu TYD fällt mir
gar nix ein)?
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Erkan Yanar
2005-03-17 20:38:24 UTC
Permalink
Post by Florian von Savigny
Post by Erkan Yanar
Post by Florian von Savigny
2. jeder Befehl, der in einer Shell ausgeführt wird, wird in Wahrheit
in einer Subshell ausgeführt;
Eben nicht jeder Befehl. Bei Funktionen und Builtins nicht.
Das scheint auch ein interessanter Aspekt zu sein. Reinhold und Du
differieren zwar inhaltlich in dem Punkt, ob hier eine eigene Subshell
gestartet wird, wie ich gemutmaßt habe, oder nur jeder Subprozeß der
Shell ein eigenes Environment hat (wenn ich mir die Ausgabe von
"pstree" anschaue, müßte ich übrigens Reinhold Recht geben).
Als ob Reinhold mir widersprechen würde. Oben steht, daß bei Funktionen
und Builtins _keine_ Subshell aufgemacht wird. Bei jedem andern
Programm, Skript etc. ganz sicher.
Der Witz der Builtins ist ja gerade, daß keine Subshell aufgemacht wird,
sonst würde (klassisches Beispiel) immer nur in einer Subshell das
Verzeichnis (cd) gewechselt werden, aber davon hat man reichlich wenig.
Post by Florian von Savigny
Aber an Deiner Empfehlung ändert das, vermute ich, gar nichts;
vermutlich würde Reinhold lediglich sagen, daß Shellfunktionen und
Builtins kein eigenes Environment haben ...
Bin ich auch gerade am tüfteln (mit der bash) die Manpage sagt definitiv
nein. Aber:
~$ HOME=/tmp cd
/tmp$ cd
:~$

Muss ma mehr lesen!
Post by Florian von Savigny
Post by Erkan Yanar
LAB&TYD
Tut mir leid, der wtf("what the fuck [is]")-Befehl auf meinem System,
der, soweit ich weiß, nur englische Usenet-Jargon-Kürzel
entschlüsselt, kapituliert hier - was heißt das beides? Etwa "lachend
auf dem Bauch", "liege auf dem Boden", oder so was (zu TYD fällt mir
gar nix ein)?
Lassen wir das, am Ende würdest Du dich wieder über mangelnde
Sozialkompetenz auslassen und ich würde Frau und Kinder schlagen.

tschazu
erkan

P.S.: google Dir einen
--
über den grenzen muß die freiheit wohl wolkenlos sein
Florian von Savigny
2005-03-18 00:37:53 UTC
Permalink
Post by Erkan Yanar
Als ob Reinhold mir widersprechen würde.
Oben steht, daß bei Funktionen und Builtins _keine_ Subshell
aufgemacht wird.
In dem Punkt habe ich auch keine Differenz ausgemacht, sondern
vielmehr darin, ob für "fremde" Befehle eine aufgemacht wird, also
Post by Erkan Yanar
Bei jedem andern Programm, Skript etc. ganz sicher.
Mir überzeugt das inzwischen aus folgendem Grund nicht mehr so ganz:
wenn ich von der Login-Shell aus /explizit/ eine Subshell mit "bash"
starte, aus der ich mit "exit" wieder in die Login-Shell zurückkommen
kann, zeigt pstree (wenn ich es aus dieser Subshell aufrufe) folgendes
an (Auszug):

init-+
|
|-bash---bash---pstree
|


Wenn ich dagegen, wie gewohnt, einfach nur "pstree" aus der
Login-Shell aufrufe, steht da:

init-+
|
|-bash---pstree
|


Wenn für die Ausführung des Befehls "pstree" tatsächlich eine eigene
Subshell aufgerufen würde, müßte man dann unten nicht zweimal
"bash---" stehen haben (und oben dreimal)?

So kann ich das nicht anders interpretieren, als das 'pstree' durch
den Aufruf aus der Shell ein unmittelbarer Kindprozeß dieser Shell
ist. Dann kann da doch eigentlich keine Subshell mit eigener
Prozeßnummer dazwischen sein, oder?
Post by Erkan Yanar
~$ HOME=/tmp cd
/tmp$ cd
Hab ich auch ausprobiert; läuft bei mir auch so. Ich bin fühle mich
aber mit Deiner Empfehlung, sowas lieber ganz zu lassen, gut versorgt
;-)


Gruß, Florian
Erkan Yanar
2005-03-18 16:43:05 UTC
Permalink
Post by Florian von Savigny
Post by Erkan Yanar
Als ob Reinhold mir widersprechen würde.
Oben steht, daß bei Funktionen und Builtins _keine_ Subshell
aufgemacht wird.
In dem Punkt habe ich auch keine Differenz ausgemacht, sondern
vielmehr darin, ob für "fremde" Befehle eine aufgemacht wird, also
Post by Erkan Yanar
Bei jedem andern Programm, Skript etc. ganz sicher.
wenn ich von der Login-Shell aus /explizit/ eine Subshell mit "bash"
starte, aus der ich mit "exit" wieder in die Login-Shell zurückkommen
kann, zeigt pstree (wenn ich es aus dieser Subshell aufrufe) folgendes
init-+
|
|-bash---bash---pstree
|
Wenn ich dagegen, wie gewohnt, einfach nur "pstree" aus der
init-+
|
|-bash---pstree
|
Wenn für die Ausführung des Befehls "pstree" tatsächlich eine eigene
Subshell aufgerufen würde, müßte man dann unten nicht zweimal
"bash---" stehen haben (und oben dreimal)?
So kann ich das nicht anders interpretieren, als das 'pstree' durch
den Aufruf aus der Shell ein unmittelbarer Kindprozeß dieser Shell
ist. Dann kann da doch eigentlich keine Subshell mit eigener
Prozeßnummer dazwischen sein, oder?
Hmm ich dachte das schon gepostet zu haben. Aber zumindest meine ich
jetzt dein Problem zu kennen. Eine Subshell ensteht dadurch, daß sich
die aufrufende Shell sich forkt (einen "Zwilling"von sich erstellt) und
dann exect. Via exec wird die PID etc. des forks übernommen, Du wirst da
nie eine "Subshell" als z.B. bash sehen werden.

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Helmut Waitzmann
2005-03-19 01:44:15 UTC
Permalink
Post by Florian von Savigny
wenn ich von der Login-Shell aus /explizit/ eine Subshell mit "bash"
starte, aus der ich mit "exit" wieder in die Login-Shell zurückkommen
kann, zeigt pstree (wenn ich es aus dieser Subshell aufrufe) folgendes
init-+
|
|-bash---bash---pstree
|
Wenn ich dagegen, wie gewohnt, einfach nur "pstree" aus der
init-+
|
|-bash---pstree
|
Wenn für die Ausführung des Befehls "pstree" tatsächlich eine eigene
Subshell aufgerufen würde, müßte man dann unten nicht zweimal
"bash---" stehen haben (und oben dreimal)?
Wenn Du unmittelbar, bevor das Programm pstree gestartet wird, in das
Betriebssystem schauen
würdest, würdest Du

im ersten Beispiel

init-+
|
|-bash---bash---bash
|

und im zweiten

init-+
|
|-bash---bash
|

sehen. Erklärung:

Wenn ein Shell ein anderes Programm startet, geschehen in Wirklichkeit zwei
Schritte:

(1) Das Shell bittet das Betriebssystem, ihm ein Kind von zu erschaffen.
Das Kind ist ebenfalls ein Shell, das die gesamte Erinnerung des
Eltern-Shells mitbekommt, als hätte es alles selbst erlebt. (Einzig
die Prozessnummer unterscheidet sich.) Daher würde pstree, in diesem
Moment von irgendwo anders her aufgerufen, auch ein weiteres bash
zeigen.

(2) Das Kind beschließt, sich vom Betriebssystem verwandeln zu lassen:
Es sagt dem Betriebssystem: »Mach mich zu einem laufenden
pstree-Programm!« Was prompt geschieht. Dabei verliert es auch seine
gesamte Erinnerung an die Vergangenheit. Es weiß nicht mehr, dass es
einmal ein »bash« war. Ja, selbst das Betriebssystem weiß es nicht
mehr. Daher kann es jetzt, als »pstree«, auch nichts mehr von seiner
Vergangenheit berichten.

Die Unix-Fachbegriffe und Systemaufrufe für (1) heißen »fork« (zu
deutsch: sich gabeln (wie ein Weg)) bzw. »fork« und für (2) »execute«
(ausführen) bzw. »exec«.

In den Manual-Pages »fork« und »exec« steht es genau beschrieben.
Post by Florian von Savigny
So kann ich das nicht anders interpretieren, als das 'pstree' durch
den Aufruf aus der Shell ein unmittelbarer Kindprozeß dieser Shell
ist.
Genau. Am Schluss ist es dann so.
Post by Florian von Savigny
Dann kann da doch eigentlich keine Subshell mit eigener
Prozeßnummer dazwischen sein, oder?
Es war ein Subshell mit eigener Prozeßnummer da, aber dann wurde es zum
»pstree« ohne eigene Prozessnummer.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <***@example.net>, (Helmut Waitzmann) ***@example.net
Florian von Savigny
2005-03-19 14:57:16 UTC
Permalink
Erkan und Reinhold haben das auch schon erklärt (s. andere
Verästelungen hier), aber so eine schöne, didaktisch wertvolle
Erläuterung war nicht dabei. Trotzdem will ich zu der
Dabei verliert es auch seine gesamte Erinnerung an die
Vergangenheit. Es weiß nicht mehr, dass es einmal ein »bash« war.
Ja, selbst das Betriebssystem weiß es nicht mehr. Daher kann es
jetzt, als »pstree«, auch nichts mehr von seiner Vergangenheit
berichten.
Ich verstehe das so, daß damit einfach alles gemeint ist, was
innerhalb der Shell galt (Variablen etc., auch, daß es überhaupt eine
Shell ist und wie eine Shell funktioniert, eben alles, was diese
laufende Instanz eines Shell-Programms ausgemacht hat, sozusagen seine
"Identität"). Daß aber die *Umgebung*, also das, was auch außerhalb
der Subshell galt, davon unberührt ist und auch um das neue pstree
herum gilt. Richtig?
Es war ein Subshell mit eigener Prozeßnummer da, aber dann wurde es
zum »pstree« ohne eigene Prozessnummer.
Meinst Du damit, daß pstree die Prozeßnummer von der Subshell
übernimmt (die insofern keine "eigene" ist), oder daß es gar keine
hat? Wohl doch eher das erstere, oder ... ?


Schreckliches Schicksal. Erst geklont und dann Persönlichkeit einfach
ausgetauscht. Bleibt denn wenigstens der Personalausweis, oder wird
der dann auch noch weggenommen ;-) (siehe letzte Frage)?
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Helmut Waitzmann
2005-03-21 21:45:24 UTC
Permalink
Post by Florian von Savigny
Erkan und Reinhold haben das auch schon erklärt (s. andere
Verästelungen hier), aber so eine schöne, didaktisch wertvolle
Erläuterung war nicht dabei. Trotzdem will ich zu der
Dabei verliert es auch seine gesamte Erinnerung an die
Vergangenheit. Es weiß nicht mehr, dass es einmal ein »bash« war.
Ja, selbst das Betriebssystem weiß es nicht mehr. Daher kann es
jetzt, als »pstree«, auch nichts mehr von seiner Vergangenheit
berichten.
Ich verstehe das so, daß damit einfach alles gemeint ist, was
innerhalb der Shell galt (Variablen etc., auch, daß es überhaupt eine
Shell ist und wie eine Shell funktioniert, eben alles, was diese
laufende Instanz eines Shell-Programms ausgemacht hat, sozusagen seine
"Identität").
Genau.
Post by Florian von Savigny
Daß aber die *Umgebung*, also das, was auch außerhalb der Subshell galt,
davon unberührt ist und auch um das neue pstree herum gilt. Richtig?
Ja. Andere Prozesse sind nicht betroffen.
Post by Florian von Savigny
Es war ein Subshell mit eigener Prozeßnummer da, aber dann wurde es
zum »pstree« ohne eigene Prozessnummer.
Meinst Du damit, daß pstree die Prozeßnummer von der Subshell
übernimmt (die insofern keine "eigene" ist), oder daß es gar keine
hat? Wohl doch eher das erstere, oder ... ?
Genau. Das erstere: Es bleibt derselbe Prozeß.
Post by Florian von Savigny
Schreckliches Schicksal. Erst geklont und dann Persönlichkeit einfach
ausgetauscht. Bleibt denn wenigstens der Personalausweis, oder wird
der dann auch noch weggenommen ;-) (siehe letzte Frage)?
Der bleibt.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <***@example.net>, (Helmut Waitzmann) ***@example.net
Reinhold Birkenfeld
2005-03-18 14:58:18 UTC
Permalink
Post by Erkan Yanar
Post by Florian von Savigny
Post by Erkan Yanar
Post by Florian von Savigny
2. jeder Befehl, der in einer Shell ausgeführt wird, wird in Wahrheit
in einer Subshell ausgeführt;
Eben nicht jeder Befehl. Bei Funktionen und Builtins nicht.
Das scheint auch ein interessanter Aspekt zu sein. Reinhold und Du
differieren zwar inhaltlich in dem Punkt, ob hier eine eigene Subshell
gestartet wird, wie ich gemutmaßt habe, oder nur jeder Subprozeß der
Shell ein eigenes Environment hat (wenn ich mir die Ausgabe von
"pstree" anschaue, müßte ich übrigens Reinhold Recht geben).
Als ob Reinhold mir widersprechen würde. Oben steht, daß bei Funktionen
und Builtins _keine_ Subshell aufgemacht wird. Bei jedem andern
Programm, Skript etc. ganz sicher.
Der Witz der Builtins ist ja gerade, daß keine Subshell aufgemacht wird,
sonst würde (klassisches Beispiel) immer nur in einer Subshell das
Verzeichnis (cd) gewechselt werden, aber davon hat man reichlich wenig.
Verstehen wir das gleiche mit Subshell?

Für mich ist eine Subshell das, was mit

( command; )

erzeugt wird.

Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?

Reinhold
Erkan Yanar
2005-03-18 16:33:53 UTC
Permalink
[snip]
Post by Reinhold Birkenfeld
Verstehen wir das gleiche mit Subshell?
Für mich ist eine Subshell das, was mit
( command; )
erzeugt wird.
Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?
Genau *das* ist eine Subshell. Kind-Shell ist hier IMHO nur verwirrend.

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Reinhold Birkenfeld
2005-03-18 21:41:29 UTC
Permalink
Post by Erkan Yanar
[snip]
Post by Reinhold Birkenfeld
Verstehen wir das gleiche mit Subshell?
Für mich ist eine Subshell das, was mit
( command; )
erzeugt wird.
Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?
Genau *das* ist eine Subshell. Kind-Shell ist hier IMHO nur verwirrend.
Jedenfalls werden in den Shell-Manuals nur Subshells, die mit

( command; )

oder z.B. mit einer Pipe erzeugt werden, auch so genannt.

Reinhold
Erkan Yanar
2005-03-18 22:46:16 UTC
Permalink
Post by Reinhold Birkenfeld
Post by Erkan Yanar
[snip]
Post by Reinhold Birkenfeld
Verstehen wir das gleiche mit Subshell?
Für mich ist eine Subshell das, was mit
( command; )
erzeugt wird.
Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?
Genau *das* ist eine Subshell. Kind-Shell ist hier IMHO nur verwirrend.
Jedenfalls werden in den Shell-Manuals nur Subshells, die mit
( command; )
oder z.B. mit einer Pipe erzeugt werden, auch so genannt.
Gerade Pipe und Subshell ist so ein Thema, die Bash führt AFAIK alle
Kommandos in einer Subshell aus, bei der ksh sieht das anders aus.
Wie soll denn die Shell z.B. vim starten ohne fork-exec (Subshell).
Vielleicht hilft ja folgender Link:
http://linuxreviews.org/beginner/abs-guide/en/c13024.html

tschazu
erkan

P.S.: Aus SUSV3

Subshell

A shell execution environment, distinguished from the main or
current shell execution environment
--
über den grenzen muß die freiheit wohl wolkenlos sein
Reinhold Birkenfeld
2005-03-19 06:53:24 UTC
Permalink
Post by Erkan Yanar
Post by Reinhold Birkenfeld
Post by Erkan Yanar
Post by Reinhold Birkenfeld
Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?
Genau *das* ist eine Subshell. Kind-Shell ist hier IMHO nur verwirrend.
Jedenfalls werden in den Shell-Manuals nur Subshells, die mit
( command; )
oder z.B. mit einer Pipe erzeugt werden, auch so genannt.
Gerade Pipe und Subshell ist so ein Thema, die Bash führt AFAIK alle
Kommandos in einer Subshell aus, bei der ksh sieht das anders aus.
Also startet die Ksh Pipes nicht in einer Subshell? Wie soll sie dies
(nach deiner Definition von Subshell) tun?
Post by Erkan Yanar
Wie soll denn die Shell z.B. vim starten ohne fork-exec (Subshell).
Mir ist klar, dass alle externen Programme über fork-exec gestartet
werden müssen.
Post by Erkan Yanar
http://linuxreviews.org/beginner/abs-guide/en/c13024.html
Alles, was da als Subshell bezeichnet wird, ist ( command; ). Zitat: "An
external command forks off a sub_process_"
Post by Erkan Yanar
P.S.: Aus SUSV3
Subshell
A shell execution environment, distinguished from the main or
current shell execution environment
Nur dass bei einem externen Programm kein "shell environment" mehr
vorhanden ist, sobald exec() ausgeführt wurde.

Reinhold
Erkan Yanar
2005-03-22 20:48:21 UTC
Permalink
[Zeitsprung]
Post by Reinhold Birkenfeld
Post by Erkan Yanar
Gerade Pipe und Subshell ist so ein Thema, die Bash führt AFAIK alle
Kommandos in einer Subshell aus, bei der ksh sieht das anders aus.
Also startet die Ksh Pipes nicht in einer Subshell? Wie soll sie dies
(nach deiner Definition von Subshell) tun?
Der SUSV3 verlangt da nichts von Subshells in Pipes und die ksh wertet
den ersten (oder letzten(gerade keine Lust zu schauen)) in der aktuellen
Shell aus.

[schönes]
Post by Reinhold Birkenfeld
Post by Erkan Yanar
http://linuxreviews.org/beginner/abs-guide/en/c13024.html
Alles, was da als Subshell bezeichnet wird, ist ( command; ). Zitat: "An
external command forks off a sub_process_"
Post by Erkan Yanar
P.S.: Aus SUSV3
Subshell
A shell execution environment, distinguished from the main or
current shell execution environment
Nur dass bei einem externen Programm kein "shell environment" mehr
vorhanden ist, sobald exec() ausgeführt wurde.
Der Witz ist ja envp. Der obige Satz sagt ja auch nichts über fork-exec
aus. Er definiert eine Subshell, die klassischer Weise als fork-exec
implementiert ist. Wobei ich mir nicht sicher bin ob dies eine nicht ganz
genaue Verallgemeinerung ist und es genauer heißen sollte, daß eine
Subshell als fork implementiert ist und das exec ergibt sich dann (oder
auch nicht -> builtin)

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Florian von Savigny
2005-03-19 00:22:40 UTC
Permalink
Eine Subshell ensteht dadurch, daß sich die aufrufende Shell sich
forkt (einen "Zwilling"von sich erstellt) und dann exect. Via exec
wird die PID etc. des forks übernommen, Du wirst da nie eine
"Subshell" als z.B. bash sehen werden.
Das muß man mir langsamer erklären ;-): wenn ich die Manpages richtig
verstehe, gilt doch folgendes:

1.) ein fork erzeugt doch einen Kindprozeß, der eine eigene PID hat,
oder?

2.) execve ersetzt doch den Prozeß, in dem es aufgerufen wird, durch
den aufgerufenen Befehl, oder?

3.) wenn das beides stimmt, heißt das, daß die Shell zunächst einen
Kindprozeß mit eigener PID erzeugt, der aber ansonsten mit ihr
identisch ist, und diesen anschließend durch den aufgerufenen Befehl
ersetzt (der dann auch die PID des Kindprozesses erhält). Aha. Jetzt
verstehe ich, warum man die Subshell nicht mit pstree o. ä. sehen
kann: sie existiert als Prozeß zeitlich VOR dem Befehl (ganz kurz) und
wird dann durch diesen ersetzt.

Die interessante Frage ist für mich natürlich, warum die Shell nicht
einfach direkt den Befehl als Kindprozeß erzeugt. Geht wahrscheinlich
ganz einfach technisch nicht, wie? D. h. ist jeder Prozeß, der einen
Befehl starten soll, gezwungen, das so zu machen (Perl z. B. scheint
es mit seiner system()-Funktion ganz genauso zu machen)?
Post by Reinhold Birkenfeld
Verstehen wir das gleiche mit Subshell?
Für mich ist eine Subshell das, was mit
( command; )
erzeugt wird.
Hmm, aber was ist das genau, was mit ( command; ) erzeugt wird, wenn
man es so beschreibt wie oben? Auch ein Kindprozeß? Ich habe dazu ein
Experiment mit erstaunlichem Ergebnis gemacht:

$ ( pstree -p; )
init(1)-+
|-bash(860)---pstree(1516)


gibt also das gleiche Ergebnis wie "pstree -p" ohne Klammern.


$ ( pstree -p; pstree -p; )
init(1)-+
|-bash(860)---bash(1517)---pstree(1518)

...

init(1)-+
|-bash(860)---bash(1517)---pstree(1519)


Gibt also nicht das gleiche Ergebnis wie "pstree -p; pstree -p".

Womöglich ignoriert die Shell die Klammern, wenn nur ein einziger
Befehl dazwischen steht?
Post by Reinhold Birkenfeld
Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?
Genau *das* ist eine Subshell. Kind-Shell ist hier IMHO nur verwirrend.
OK, ich glaube, inhaltlich habe ich verstanden, was Erkan Subshell und
Reinhold Kind-Shell nennt bzw. genannt hat; das, was direkt nach dem
Forken und bis zum Execen besteht. Hat diese, ich sage mal "flüchtige"
Sub-/Kind-Shell irgendwie eine entscheidende Funktion für das
Environment des dann execten Befehls (ich frage das deswegen, weil
Erkan auf ihre Existenz so nachdrücklich hingewiesen hat)?

Ich habe auch versucht, festzustellen, wie eine Subshell denn nun
"offiziell" definiert ist, und habe, nach meinen gesammelten
Linux-Büchern, die bash-Manpage durchsucht, ohne eine Definition zu
finden. Die Manpage verwendet den Begriff aber öfter; folgende
Passagen scheinen wenigstens einen Anhalt zu geben:


(list) list is executed in a subshell. Variable assign­
ments and builtin commands that affect the shell's
environment do not remain in effect after the com­
mand completes.


Mir scheint, das beschreibt das, was ich oben mit ( pstree -p; pstree
-p ) getestet habe, geht aber nicht auf die Frage ein, ob es einen
Unterschied macht, ob die Liste nur einen oder mehrere Befehle
enthält. Wie dem auch sei: wenn sie mehrere Befehle enthält, sieht man
die "subshell" als Elternprozeß der einzelnen Befehle! Beim
Herumprobieren habe ich auch festgestellt, daß die Geschichte mit dem
export sich nicht auf ()-Subshells bezieht ($BLAH ist im folgenden
Beispiel nicht etwa an anderer Stelle für den Export markiert):

$ BLAH=BLUB
$ ( /bin/echo $BLAH; pstree -p; )
BLUB

[Ausgabe von pstree: "zwischengeschaltete" bash]

Das ist anders (kein BLUB, sondern leerer String), wenn die gleichen
Befehle in einer Datei stehen, wie weiter unten bei COMMAND EXECUTION
beschrieben. Die Ausgabe von pstree ist dabei analog.



$ Expands to the process ID of the shell. In a ()
subshell, it expands to the process ID of the cur­
rent shell, not the subshell.


Das hört sich an, als gebe es verschiedene Typen von Subshells: die
"()-Subshell" und noch andere, vielleicht z. B. die, die in der
folgenden Passage beschrieben wird. Außerdem scheint es zu
implizieren, daß eine "()-Subshell" eine eigene PID hat, also ein
eigener Prozeß ist.

COMMAND EXECUTION

..., the shell executes the named program in a separate
execution environment.

If this execution fails because the file is not in executable
format, ... , it is assumed to be a shell script, a file
containing shell commands. A subshell is spawned to execute
it. This subshell reinitializes itself, so that the effect
is as if a new shell had been invoked to handle the script,


Auch eine solche Subshell sieht man, wie schon gesagt, mit pstree als
Kindprozeß. Aha: sie wird "gespawnt" und sie "reinitialisiert"
sich. Sind das entscheidende Unterschiede zur "()-Subshell"?

Aus Eurer Diskussion habe ich mehr verstanden als aus dieser
Dokumentation; mir gelingt es nicht recht, aus diesen Erwähnungen auf
einen eindeutig definierten Begriff "Subshell" zu schließen. Habt Ihr
noch Lust, Stellung zu nehmen, oder wird es Euch (auch) zu disparat?
Zumindest Erkan scheint ja einen entschiedenen Grund dafür zu haben,
gerade die oben beschriebene "flüchtige" Shell als Subshell zu
bezeichnen (und andere Bezeichnungen dafür, wie "Kind-Shell",
abzulehnen). Wie verhält sich denn das dazu, was die in der Manpage an
verschiedenen Stellen "subshell" nennen: das sind doch offenbar
mindestens zum Teil Shells, die /nicht/ flüchtig sind, weil sie nicht
durch etwas anderes ersetzt werden, und deshalb auch mit pstree
sichtbar sind? Würdest Du das auch "Subshell" nennen bzw. begrifflich
von der "flüchtigen" Subshell unterscheiden?


Und was mir, ganz allgemein, nirgendwo klar wird:

Was ist das, wenn man innerhalb einer Shell "bash" aufruft und dann an
ihrem Prompt weiterarbeitet? Heißt das auch Subshell?

Ist eine Subshell *immer* ein Kindprozeß?

Hat die Variable $SHLVL etwas mit Subshells zu tun oder geht es da um
ein ganz anderes Problem?
--
Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.
Helmut Waitzmann
2005-03-22 00:37:25 UTC
Permalink
Post by Florian von Savigny
Eine Subshell ensteht dadurch, daß sich die aufrufende Shell sich
forkt (einen "Zwilling"von sich erstellt) und dann exect. Via exec
wird die PID etc. des forks übernommen, Du wirst da nie eine
"Subshell" als z.B. bash sehen werden.
Das muß man mir langsamer erklären ;-): wenn ich die Manpages richtig
1.) ein fork erzeugt doch einen Kindprozeß, der eine eigene PID hat,
oder?
Richtig.
Post by Florian von Savigny
2.) execve ersetzt doch den Prozeß, in dem es aufgerufen wird, durch
den aufgerufenen Befehl, oder?
Richtig. »execve« bittet das Betriebssystem, auf dem Prozeß, der
»execve« aufruft, ein neues Programm zu starten, wobei der bisherige
Programmlauf beim »execve«-Aufruf endet.
Post by Florian von Savigny
3.) wenn das beides stimmt, heißt das, daß die Shell zunächst einen
Kindprozeß mit eigener PID erzeugt, der aber ansonsten mit ihr
identisch ist, und diesen anschließend durch den aufgerufenen Befehl
ersetzt (der dann auch die PID des Kindprozesses erhält). Aha. Jetzt
verstehe ich, warum man die Subshell nicht mit pstree o. ä. sehen
kann: sie existiert als Prozeß zeitlich VOR dem Befehl (ganz kurz) und
wird dann durch diesen ersetzt.
Genau so ist es.
Post by Florian von Savigny
Die interessante Frage ist für mich natürlich, warum die Shell nicht
einfach direkt den Befehl als Kindprozeß erzeugt. Geht wahrscheinlich
ganz einfach technisch nicht, wie?
Genau. Es gibt keinen Betriebssystemaufruf, mit dem man das tun könnte.
Es gibt nur die beiden: »fork« und »execve«.
Post by Florian von Savigny
D. h. ist jeder Prozeß, der einen Befehl starten soll, gezwungen, das so
zu machen
Ja. Einen anderen Weg gibt es nicht.
Post by Florian von Savigny
(Perl z. B. scheint es mit seiner system()-Funktion ganz genauso zu
machen)?
Ich kenne mich mit Perl nicht aus. Aber am Ende bleibt auch Perl nichts
anderes übrig, als »fork« und »execve« zu benutzen.
Post by Florian von Savigny
Post by Reinhold Birkenfeld
Verstehen wir das gleiche mit Subshell?
Für mich ist eine Subshell das, was mit
( command; )
erzeugt wird.
Hmm, aber was ist das genau, was mit ( command; ) erzeugt wird, wenn
man es so beschreibt wie oben? Auch ein Kindprozeß? Ich habe dazu ein
$ ( pstree -p; )
init(1)-+
|-bash(860)---pstree(1516)
gibt also das gleiche Ergebnis wie "pstree -p" ohne Klammern.
$ ( pstree -p; pstree -p; )
init(1)-+
|-bash(860)---bash(1517)---pstree(1518)
...
init(1)-+
|-bash(860)---bash(1517)---pstree(1519)
Gibt also nicht das gleiche Ergebnis wie "pstree -p; pstree -p".
Womöglich ignoriert die Shell die Klammern, wenn nur ein einziger
Befehl dazwischen steht?
Das dürfte vermutlich der Fall sein: Wenn in runden Klammern nichts
außer einem einzigen Programmaufruf (hier: pstree) steht, spart sich das
Shell, nachdem es für die runden Klammern ein »fork« ausgeführt hat, ein
weiteres »fork«: Es wird also so verfahren, als hättest Du

$ ( exec pstree -p;)

hingeschrieben: Das »exec« ist ein ins Shell eingebautes Kommando, das
dem Shell sagt, es solle das dahinter genannte Programm samt seiner
Parameterliste mit Hilfe des Systemaufrufs »execve« starten, ohne vorher
ein »fork« durchzuführen.
Post by Florian von Savigny
Post by Reinhold Birkenfeld
Sicherlich, die Shell benutzt wohl fork() und execve() und man bekommt
für einen sehr kleinen Zeitraum eine Kind-Shell. Meinst du das?
Genau *das* ist eine Subshell. Kind-Shell ist hier IMHO nur verwirrend.
OK, ich glaube, inhaltlich habe ich verstanden, was Erkan Subshell und
Reinhold Kind-Shell nennt bzw. genannt hat; das, was direkt nach dem
Forken und bis zum Execen besteht. Hat diese, ich sage mal "flüchtige"
Sub-/Kind-Shell irgendwie eine entscheidende Funktion für das
Environment des dann execten Befehls (ich frage das deswegen, weil
Erkan auf ihre Existenz so nachdrücklich hingewiesen hat)?
Ja. Beim »execve«-Aufruf bleiben gewisse Eigenschaften des Prozesses
erhalten, obwohl ein neues Programm gestartet wird. Zu diesen
Eigenschaften gehören z.B. das momentane Verzeichnis, das momentane
Wurzelverzeichnis (»/«), die Prozesspriorität (das sog. »nice value«),
gewisse Schranken, die das Betriebssystem dem Prozess auferlegt hat
(z.B. die Anzahl der Dateien, die gleichzeitig geöffnet sein darf),
(meistens, aber nicht immer) die Benutzer- und Gruppenzugehörigkeit,
eventuell die Einstellung, ob der Prozeß auf Signale reagieren soll, die
ihn erreichen.

Die Liste der Environmentvariablen und die Aufrufparameter des zu
startenden Programms werden beim »execve«-Aufruf nicht vom alten
Programmlauf übernommen, sondern werden direkt angegeben. Allerdings ist
das ins Shell eingebaute »exec«-Kommando so gemacht, dass es dem
Systemaufruf »execve« die bisherige Liste der Environmentvariablen
unverändert als neue Liste übergibt.

Man kann also z.B. durch

$ ( export LANG; LANG=C; exec pstree -p)

bewirken, dass dem »execve«-Aufruf in der Liste der Umgebungsvariablen
hier eine Umgebungsvariable »LANG« mit dem Wert »C« übergeben wird und
daher »pstree« die Umgebungsvariable »LANG« mit dem Inhalt »C« erhält.
Post by Florian von Savigny
Ich habe auch versucht, festzustellen, wie eine Subshell denn nun
"offiziell" definiert ist, und habe, nach meinen gesammelten
Linux-Büchern, die bash-Manpage durchsucht, ohne eine Definition zu
finden.
Ich vermute, er ist offiziell nicht festgelegt. Das kommt einfach daher,
dass es im Betriebssystem keinen speziellen Begriff »subshell« gibt.
Alles, was es gibt, sind Prozesse, die in Eltern-Kind-Beziehungen
verwandt sind. Wenn also »sub«, dann schlicht »subprocess«. Ein Shell
ist für das Betriebssystem auch nur ein Prozeß wie jeder andere auch.
Post by Florian von Savigny
Die Manpage verwendet den Begriff aber öfter; folgende Passagen scheinen
(list) list is executed in a subshell. Variable assign­
ments and builtin commands that affect the shell's
environment do not remain in effect after the com­
mand completes.
Ich würde den zitierten Abschnitt als Definition von »subshell«
verwenden.
Post by Florian von Savigny
Mir scheint, das beschreibt das, was ich oben mit ( pstree -p; pstree
-p ) getestet habe, geht aber nicht auf die Frage ein, ob es einen
Unterschied macht, ob die Liste nur einen oder mehrere Befehle
enthält.
Auf die Beantwortung dieser Frage würde ich mich für den Begriff
»subshell« auch nicht festlegen. Meine Vermutung ist, dass das erste
Shell, was es jemals gab, seit es Unix gibt, in jedem Fall, d.h. egal, ob
innerhalb der runden Klammern nur ein oder mehrere Programme gestartet
werden, für jedes Programm einen eigenen Prozeß spendiert hat.

Aber wie Du selbst gemerkt hast, ist das heutzutage nicht immer so.
Wichtig ist allein: »do not remain in effect after the command
completes«. Also: Wenn die schließende runde Klammer passiert ist, ist
von dem, was innerhalb der runden Klammern war, nichts mehr zu sehen.

Jemand, der sich (so wie Du jetzt) mit Unix auskennt, denkt da natürlich
sofort an Kindprozesse.
Post by Florian von Savigny
Beim Herumprobieren habe ich auch festgestellt, daß die Geschichte mit
dem export sich nicht auf ()-Subshells bezieht ($BLAH ist im folgenden
$ BLAH=BLUB
$ ( /bin/echo $BLAH; pstree -p; )
BLUB
Genau. »BLAH« (obwohl sie keine Umgebungsvariable ist) hat auch
innerhalb der runden Klammern den Wert »BLUB«, weil beim
»fork«-Systemaufruf vom Betriebssystem einfach der komplette Shell-Prozeß
kopiert wird[1]: Alle Shell-Variablen werden mitkopiert.

[1] Es muß nicht unbedingt sein, daß vom Betriebssystem sofort alles
kopiert wird. Es könnte auch sein, dass das Betriebssystem zunächst
beiden Prozessen, dem Shell außerhalb und dem innerhalb der runden
Klammern, dieselben Prozeßdaten zum Lesen zur Verfügung stellt. Sobald
aber einer von beiden Prozessen an seinen Daten etwas ändern will (etwa,
eine Shell-Variable ändern, u.a.), kommt das Betriebssystem dazwischen
und kopiert schnell die Prozessdaten, damit jeder Prozess seine eigenen
hat. Damit kann in dem Fall, dass innerhalb der runden Klammern nichts
anderes gemacht wird, als den Systemaufruf »execve« aufzurufen, auf das
Kopieren verzichtet werden.
Post by Florian von Savigny
[Ausgabe von pstree: "zwischengeschaltete" bash]
Das ist anders (kein BLUB, sondern leerer String), wenn die gleichen
Befehle in einer Datei stehen, wie weiter unten bei COMMAND EXECUTION
beschrieben. Die Ausgabe von pstree ist dabei analog.
$ Expands to the process ID of the shell. In a ()
subshell, it expands to the process ID of the cur­
rent shell, not the subshell.
Damit ist nur gemeint, dass die Shellvariable »$« im Fall der runden
Klammern mitkopiert und nicht geändert wird. Man erhält also innerhalb
der runden Klammern mit der Variablen »$« keine Auskunft über die
Prozessnummer des Prozesses, der innerhalb der runden Klammern läuft,
sondern die des Prozesses außerhalb der runden Klammern:

$ (ps -p "$$"; ps -p "$$"); ps -p "$$"

liefert dreimal Angaben über den selben Prozess: über den außerhalb der
runden Klammern.
Post by Florian von Savigny
Das hört sich an, als gebe es verschiedene Typen von Subshells: die
"()-Subshell" und noch andere, vielleicht z. B. die, die in der
folgenden Passage beschrieben wird.
Das kann ich daraus nicht heraushören. Ich vermute, es gibt trotzdem nur
einen Typ von Subshells, s.u.
Post by Florian von Savigny
Außerdem scheint es zu implizieren, daß eine "()-Subshell" eine eigene
PID hat, also ein eigener Prozeß ist.
Genau: Ein Subshell ist ein eigener Prozess mit eigenem PID. Jedoch
zeigt die Variable »$« nicht sein PID an, weil sie einfach kopiert (s.o.)
und nicht angepasst wird.
Post by Florian von Savigny
COMMAND EXECUTION
..., the shell executes the named program in a separate
execution environment.
If this execution fails because the file is not in executable
format, ... , it is assumed to be a shell script, a file
containing shell commands. A subshell is spawned to execute
it.
»is spawned« bedeutet wohl einfach »fork«, sonst nichts. Bis hierher
unterscheidet es sich nicht von runden Klammern.
Post by Florian von Savigny
This subshell reinitializes itself,
Das Subshell richtet sich alle Shellvariablen so ein, wie es es tun
würde, wenn es gerade neu mittels »execve« gestartet worden wäre. Jetzt
wird beispielsweise die Variable »$« mit der eigenen Prozessnummer (die
beim Betriebssystem erfragt werden kann) belegt.
Post by Florian von Savigny
so that the effect is as if a new shell had been invoked to
handle the script,
Und dann macht der neue Shell-Prozess genau das, was ein Shell tut, dem
man ein Shell-Script zur Abarbeitung vorlegt.

Das finde ich allerdings etwas bedenklich: Das Shell kann nicht
garantieren, dass das Shell-Script nicht mit einem anderen Shell laufen
soll. Immerhin gibt es tradionell verschiedene Shells, unter denen man
auswählen kann. Am Anfang eines Shell-Scripts kann man daher in der
ersten Zeile mittels »#!« angeben, welches zur Abarbeitung des
Shell-Scripts verwendet werden soll. Jedoch kann sich ein Shell nicht
sicher sein, dass es das gleiche Shell ist wie das, was hinter »#!« zur
Abarbeitung angegeben ist.
Post by Florian von Savigny
Auch eine solche Subshell sieht man, wie schon gesagt, mit pstree als
Kindprozeß. Aha: sie wird "gespawnt" und sie "reinitialisiert"
sich. Sind das entscheidende Unterschiede zur "()-Subshell"?
Im Reinitialisieren dürfte der Unterschied liegen.
Post by Florian von Savigny
Aus Eurer Diskussion habe ich mehr verstanden als aus dieser
Dokumentation; mir gelingt es nicht recht, aus diesen Erwähnungen auf
einen eindeutig definierten Begriff "Subshell" zu schließen. Habt Ihr
noch Lust, Stellung zu nehmen, oder wird es Euch (auch) zu disparat?
Zumindest Erkan scheint ja einen entschiedenen Grund dafür zu haben,
gerade die oben beschriebene "flüchtige" Shell als Subshell zu
bezeichnen (und andere Bezeichnungen dafür, wie "Kind-Shell",
abzulehnen). Wie verhält sich denn das dazu, was die in der Manpage an
verschiedenen Stellen "subshell" nennen: das sind doch offenbar
mindestens zum Teil Shells, die /nicht/ flüchtig sind, weil sie nicht
durch etwas anderes ersetzt werden, und deshalb auch mit pstree
sichtbar sind? Würdest Du das auch "Subshell" nennen bzw. begrifflich
von der "flüchtigen" Subshell unterscheiden?
Was ist das, wenn man innerhalb einer Shell "bash" aufruft und dann an
ihrem Prompt weiterarbeitet? Heißt das auch Subshell?
Ich würde das nicht Subshell nennen: Das neu gestartete bash steht zu
dem alten in keiner anderen Beziehung als ein beliebiges
Eltern-Kind-Prozesspaar sonst auch. Dass beide Prozesse Shells sind,
spielt dabei keine Rolle. Also: Ist die Beziehung kein Sonderfall,
nehme ich auch keinen besonderen Begriff her. Um es noch zu
verdeutlichen:

Angenommen, hier läuft ein bash. Weder bei

$ ksh

noch bei

$ bash

noch bei

$ ksh -c 'exec bash'

würde ich von einem Subshell sprechen.

Technisch ausgedrückt: Von Subshells würde ich höchstens sprechen, wenn
kein »execve« beteiligt ist, sondern höchstens ge»forkt« wird.

Die Fälle mit »execve« würde ich weder »Kind-Shell« noch »Subshell«
nennen. Insofern hat bei mir der Begriff »Kind-Shell« keine Bedeutung.
Post by Florian von Savigny
Ist eine Subshell *immer* ein Kindprozeß?
Du stellst gezielt die spannendsten Fragen, alle Achtung!

Es könnte durchaus sein, dass mal jemand ein Shell entwickelt, bei dem
runde Klammern kein »fork« durchführen. Statt dessen könnte sich das
Shell seine ganzen Einstellungen selbst merken, auf die Seite legen und
kopieren. Es könnte sie innerhalb der runden Klammern dann fröhlich
verändern, weil es nach der schließenden Klammer dann nichts anderes zu tun
bräuchte, als den auf die Seite gelegten alten Zustand wieder herzunehmen
und damit fortzufahren.

Aber halt: Das wird ihm ohne, dass das Betriebssystem geändert wird,
nicht in jedem Fall (in manchen Spezialfällen jedoch schon) gelingen:
Z.B. kann sich ein Prozess weder sein momentanes Verzeichnis, sein
Wurzelverzeichnis, seine Priorität (»nice« value), seine Benutzer- oder
Gruppenkennungen, noch seine Prozess-Limits merken, beliebig verändern
und anschließend auf den gemerkten Wert zurückstellen. Da kann es
durchaus Einbahnstraßen geben.
Post by Florian von Savigny
Hat die Variable $SHLVL etwas mit Subshells zu tun oder geht es da um
ein ganz anderes Problem?
Es hat mit fork-execve-Schritten zu tun: Ich vermute, dass es Shells
gibt, die beim Start in der Umgebungsvariable »SHLVL« eine Zahl erwarten.
Zu dieser zählen sie dann eins dazu und stellen sie wieder in die
Umgebung zurück. Auf diese Weise erhält man, wenn man aus einem Shell
ein weiteres durch Aufruf, etwa

$ bash

startet, einen Zähler, wie tief man schon neue Shells geschachtelt hat.
Wenn man dem Shell dann beibringt, den Wert der Variablen im Shell-Prompt
zu zeigen, verliert man den Überblick nicht, wie oft man jetzt »exit«
eintippen darf, ehe das ursprüngliche Shell beendet wird.

Es würde mich sehr wundern, wenn es Shells gäbe, die bei

$ /bin/echo "$SHLVL"; (/bin/echo "$SHLVL"; /bin/sleep 1)

zwei unterschiedliche Zeilen ausgäben.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <***@example.net>, (Helmut Waitzmann) ***@example.net
Lesen Sie weiter auf narkive:
Loading...