![[HaBo]](/styles/default/logoklein.png){kind=small}
Was bewirkt dieser Befehl??
- Themenstarter DelumaX
- Beginndatum
kannst du ev noch einen link mit dem ganzen script posten? es wird dir wahrscheinlich nicht viel bringen wenn ich dir sage, dass dies 2 konsolenbefehle sind welche hintereinander ausgeführt werden.
was man aus dieser linie herausfindet ist nur folgendes:
-dass mit dem ergebnis diser linie die variable "PROMPT_COMMAND" gefüllt wird
- dass der befehl "pwd" seine daten irgendwohin umlenkt
- dass irgendein prog/dienst gestopt wird
was man aus dieser linie herausfindet ist nur folgendes:
-dass mit dem ergebnis diser linie die variable "PROMPT_COMMAND" gefüllt wird
- dass der befehl "pwd" seine daten irgendwohin umlenkt
- dass irgendein prog/dienst gestopt wird
Ich habe den Befehl zufällig in der Befehlshistorie gefunden. Irgendjemand müsste ihn am meinen Arbeitsplatzrechner eingegeben haben während ich nicht da war?! Dazu noch zwei weitere Befehle nach dem Motto " cd `echo /50/52/200` ". Ich weiss leider nicht mehr ob die Zahlen und die Syntax genau so stimmen und kann die genauen auch frühstens Donnerstag posten.
Bin zumindest im Ordner /media dadurch gelandet.
Wie gesagt beschäftige mich noch nicht so lange mit Linux. Der cd Befehl ist ja klar und die echo Anweisung soll wohl irgendeine Ausgabe machen. Aber was soll das mit den Zahlen??
Und der andere Befehl mit pwd lässt mich irgendwie nicht die besten Absichten vermuten?!
Bin zumindest im Ordner /media dadurch gelandet.
Wie gesagt beschäftige mich noch nicht so lange mit Linux. Der cd Befehl ist ja klar und die echo Anweisung soll wohl irgendeine Ausgabe machen. Aber was soll das mit den Zahlen??
Und der andere Befehl mit pwd lässt mich irgendwie nicht die besten Absichten vermuten?!
Moe
1
pwd ist das Kommando, welches den aktuellen Pfad ausgiebt, nicht wirklich etwas gefährliches.
>&7 ist eine Umleitung der 7. Kommunikationsebene (Kommunikationsebenen unter Linux sind in erster Linie stderr, stdout und stdin (Kernel Log Daemon, Bildschirm, Keyboard)). Was mit dieser 7. Ebene bewirkt wird, weiß ich leider nicht.
Zu guter letzt wird irgendein Prozess dazu veranlaßt sich zu beenden, vielleicht ist dabei $$ der Platzhalter für die Ausgabe von pwd sein (und somit die Ausgabe, welche kill beenden soll).
Ich habe das Script mal unter gesicherten Bedingungen zur Ausführung gebracht:
Da das Script sich danach nicht beendet, läßt darauf schließen, das es weiterhin auf eine Eingabe wartet, um seine Arbeit abschließen zu können.
Ich glaube mal gelesen zu haben, das das ' Zeichen um eine Anweisung deren Wirkung negiert und nur den Text als solchen übrig läßt (um die Wirkung für eine Zuweisung zu erhalten muss man es in " setzen). Ich werde nochmal sehen, ob ich die Quelle nochmal wiederfinde.
Moe
>&7 ist eine Umleitung der 7. Kommunikationsebene (Kommunikationsebenen unter Linux sind in erster Linie stderr, stdout und stdin (Kernel Log Daemon, Bildschirm, Keyboard)). Was mit dieser 7. Ebene bewirkt wird, weiß ich leider nicht.
Zu guter letzt wird irgendein Prozess dazu veranlaßt sich zu beenden, vielleicht ist dabei $$ der Platzhalter für die Ausgabe von pwd sein (und somit die Ausgabe, welche kill beenden soll).
Ich habe das Script mal unter gesicherten Bedingungen zur Ausführung gebracht:
Code:
moe:~$ PROMPT_COMMAND='pwd >&7 ; kill -STOP $$'
bash: 1: Ungültiger DateideskriptorDa das Script sich danach nicht beendet, läßt darauf schließen, das es weiterhin auf eine Eingabe wartet, um seine Arbeit abschließen zu können.
Ich glaube mal gelesen zu haben, das das ' Zeichen um eine Anweisung deren Wirkung negiert und nur den Text als solchen übrig läßt (um die Wirkung für eine Zuweisung zu erhalten muss man es in " setzen). Ich werde nochmal sehen, ob ich die Quelle nochmal wiederfinde.
Moe
sieben
1
Original von DelumaX
PROMPT_COMMAND='pwd>&7;kill -STOP $$'
Kann mir da jemand was zu sagen?? Leider noch nicht genug wissen über Linux angehäuft. Thx
Irgendwie vollkommener Unsinn.
Die Ausgabe von pwd soll auf einen ungueltigen Standardkanal umgeleitet werden. ((0) Standardeingabe (1) Standardausgabe (2) Standardfehlerausgabe). Danach soll an die aktuelle PID ein kill STOP gesendet werden, wozu es jedoch nicht mehr kommt, da das Script bereits vorher aufgrund der Ungueltigen Ausgabeumleitung abbricht. Das ganze soll dann PROMPT_COMMAND zugewiesen werden was, ebenfalls nicht passiert (Waehre btw. auch syndaktisch falsch).
Na so sinnlos ist das alles nicht.
Der ganze Term bewirkt erst mal folgendes,
der Varibale $PROMPT_COMMAND wird eben der String 'pwd>&7;kill -STOP $$' zugewiesen.
Und wie die durchweg Grossschreibung vermuten lässt ist $PROMT_COMMAND tatsächlich eine Spezialvariable in der BASH. Der Inhalt dieser Variablen wird als Shell-Command bevor die BASH einen Promt ausgibt ausgeführt.
Zu den Commands in dem String, der ruft pwd auf und leitet die Standartausgabe (Kanal 1) in Kanal 7, bzw. verknüpft die Kanäle. In der BASH kann man durchaus mehrere Känäle benutzen man muss sie nur vorher öffnen sofern es nicht STDOUT (0), SDTIN (1) oder STDERR (2) ist (z. B.: exec 3</etc/HOSTNAME und dann einfach mal z. B.: cat <&3). Also ich vermute, dass vorher der Kanal 7 mit einer Datei verbunden wurde in der so nun das aktuelle Arbeitsverzeichnis geloggt wird, das gibt pwd nämlich aus, aber das hat ja eh schon wer geschrieben, aber dazu müsste man die vorhergeheneden Befehle untersuchen um da Klarheit zu haben.
Und kill -STOP $$, das zweite Kommando schickt ein SIG_STOP and das Programm mit der PID die in $$ ist. $$ ist wiederum eine Spezial-Variable, die die PID von dem Prozess inne hat zu dem sie gehört, also so könnte man mit kill $$ in einem Shell-Script das Script (bzw. die Sub-Shell dazu) in der Ausführung killen. In o. g. Fall beinhaltet $$ allerdings die PID der momentanen User-Shell selbst.
Der Term als ganzen bewirkt also, das nach dem man ihn eingegeben hat, und die Shell vor dem Promt der kommen müsste unser $PROMT_COMMAND ausführt, dass das aktuelle Verzeichnis in irgendwas geleitet wird womit Kanal 7 verbunden ist und danach die Shell stoppt...
OK, also doch wieder irgendwie sinnlos, zumindest kann ich in o. g. Effekt keinen Nutzen finden, aber syntaktisch und so geht das alles...
P.S.:
cd `echo /50/52/200` bewirkt das Selbe wie cd /50/52/200 nur mit mehr Rechenlast... *g*
Der ganze Term bewirkt erst mal folgendes,
der Varibale $PROMPT_COMMAND wird eben der String 'pwd>&7;kill -STOP $$' zugewiesen.
Und wie die durchweg Grossschreibung vermuten lässt ist $PROMT_COMMAND tatsächlich eine Spezialvariable in der BASH. Der Inhalt dieser Variablen wird als Shell-Command bevor die BASH einen Promt ausgibt ausgeführt.
Zu den Commands in dem String, der ruft pwd auf und leitet die Standartausgabe (Kanal 1) in Kanal 7, bzw. verknüpft die Kanäle. In der BASH kann man durchaus mehrere Känäle benutzen man muss sie nur vorher öffnen sofern es nicht STDOUT (0), SDTIN (1) oder STDERR (2) ist (z. B.: exec 3</etc/HOSTNAME und dann einfach mal z. B.: cat <&3). Also ich vermute, dass vorher der Kanal 7 mit einer Datei verbunden wurde in der so nun das aktuelle Arbeitsverzeichnis geloggt wird, das gibt pwd nämlich aus, aber das hat ja eh schon wer geschrieben, aber dazu müsste man die vorhergeheneden Befehle untersuchen um da Klarheit zu haben.
Und kill -STOP $$, das zweite Kommando schickt ein SIG_STOP and das Programm mit der PID die in $$ ist. $$ ist wiederum eine Spezial-Variable, die die PID von dem Prozess inne hat zu dem sie gehört, also so könnte man mit kill $$ in einem Shell-Script das Script (bzw. die Sub-Shell dazu) in der Ausführung killen. In o. g. Fall beinhaltet $$ allerdings die PID der momentanen User-Shell selbst.
Der Term als ganzen bewirkt also, das nach dem man ihn eingegeben hat, und die Shell vor dem Promt der kommen müsste unser $PROMT_COMMAND ausführt, dass das aktuelle Verzeichnis in irgendwas geleitet wird womit Kanal 7 verbunden ist und danach die Shell stoppt...
OK, also doch wieder irgendwie sinnlos, zumindest kann ich in o. g. Effekt keinen Nutzen finden, aber syntaktisch und so geht das alles...
P.S.:
cd `echo /50/52/200` bewirkt das Selbe wie cd /50/52/200 nur mit mehr Rechenlast... *g*