Verhalten von der Ausgabeumleitung der bash
- Ersteller Tom24
- Erstellt am
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Hallo,
ich hatte heute ein komisches, sagen wir unangenehmes Erlebniss.
Ich wollte aus einer Datei genau eine Zeile heraushaben, also bin ich mit:
Das Ergebniss war eine leere Datei, was mich nicht so freute.
Unter Einhaltung von sequenzieller Abarbeitung duerfte doch sowas gar nicht passieren, wie denkt ihr kommt das zustande?
ich hatte heute ein komisches, sagen wir unangenehmes Erlebniss.
Ich wollte aus einer Datei genau eine Zeile heraushaben, also bin ich mit:
die Sache schnell ohne Editor angegangen.
Das Ergebniss war eine leere Datei, was mich nicht so freute.
Unter Einhaltung von sequenzieller Abarbeitung duerfte doch sowas gar nicht passieren, wie denkt ihr kommt das zustande?
Manche Progs umgehen bei der Ausgabe anscheinend die Konsole, hab das auch schon öfters gemerkt. Liegt aber an den Programmen und nicht der bash.
Versuch doch mal ein 'echo $(grep -v 'merkmal' /pfad/zur/datei) > datei'.
Ach ja, bei deinem Beispiel schreibst du das übrigens in die selbe Datei, in der du grepst - das kann nur schief gehen, weil die Ausgabe nicht seriell abgearbeitet wird (also vergiss das von gerade eben, das ist für ein anderes Problem
).
Überleg mal du hättest eine Ausgabe von 10 Megabyte. Dann müsste die Bash erst die 10 MB puffern, um die dann in eine Datei zu schreiben.
Oder noch schlimmer: hexdump /dev/sdb - gibt bei mir locker über 300GB an Daten.
Die Ausgabeumleitung muss also sofort erfolgen, die Datei wird also wahrscheinlich per stream geöffnet und sowie was ausgegeben wird, landet das in der Datei.
Umgekehrt, wenn du die Umleitung weglässt oder nach tty0 machst, erscheint das ja auch sofort auf dem Screen und nicht erst wenn das Prog fertig durchgelaufen ist.
Oder eben zum Entpacken:
'zcat file1 > file2' - geht in die Hose, wenn file1 entpackt sehr groß ist.
Versuch doch mal ein 'echo $(grep -v 'merkmal' /pfad/zur/datei) > datei'.
Ach ja, bei deinem Beispiel schreibst du das übrigens in die selbe Datei, in der du grepst - das kann nur schief gehen, weil die Ausgabe nicht seriell abgearbeitet wird (also vergiss das von gerade eben, das ist für ein anderes Problem
). Überleg mal du hättest eine Ausgabe von 10 Megabyte. Dann müsste die Bash erst die 10 MB puffern, um die dann in eine Datei zu schreiben.
Oder noch schlimmer: hexdump /dev/sdb - gibt bei mir locker über 300GB an Daten.
Die Ausgabeumleitung muss also sofort erfolgen, die Datei wird also wahrscheinlich per stream geöffnet und sowie was ausgegeben wird, landet das in der Datei.
Umgekehrt, wenn du die Umleitung weglässt oder nach tty0 machst, erscheint das ja auch sofort auf dem Screen und nicht erst wenn das Prog fertig durchgelaufen ist.
Oder eben zum Entpacken:
'zcat file1 > file2' - geht in die Hose, wenn file1 entpackt sehr groß ist.
Code:
grep -v 'merkmal' /pfad/zur/datei > /pfad/zur/dateiHast du auch zwei verschiedene Dateien bei /pfad/zur/datei genommen
oder von ~/a nach ~/a ?
Wenn nicht, dann ists klar warum die leer ist.
Die Ausgabe leert die Datei wegen ">" und grep findet dann ne leere Datei.
Bei mir geht der obige Befehl nämlich wunderbar
Wenn man ein bischen logisch nachdenkt, MUSS es so sein, ein anderes Verhalten macht meiner Meinung nach eigentlich keinen Sinn: wie schon i_hasser geschrieben hat, funktioniert die Ausgabeumleitung mit beliebig großen Datenmengen, man kann theoretisch Datenströme mit Größen gegen unendlich durch eine Pipe jagen (der Prozeß läuft dann halt eine ganze Weile . Die Shell muss VOR der Verarbeitung der Daten die Ausgabekanäle öffnen. Normalerweise ist dies die Console, auf der man gerade arbeitet, im Falle einer ausdrücklichen Umlenkung in eine Datei wird die Datei geöffnet.
Wenn Du eine einfache spitze Klammer schreibst, wird eine bereits vorhandene zuerst geleert, bei zwei Klammern wird das, was da kommen mag, an die vorhandenen Daten angehängt. Ein kleiner Test zeigt, dass zumindest in der Bash unter Linux die Inode für die Datei erhalten bleibt:
Die Inode-Nummer hat sich nicht verändert, daher gehe ich mal davon aus, dass die Datei geleert und nicht gelöscht wurde (außer eine neu angelegte Inode bekommt die gleiche Nummer wie die zuletzt gelöschte).
Wenn dann nun also endlich die Ausgabedatei geöffnet ist, fängt die Shell an, das Kommando auszuführen und die Datenkanälee stdout und stderr (und evtl. weitere von dem ausgeführten Programm verwendete Ausgabekanäle) in ihre jeweiligen Ablagen zu plazieren.
(Der Prozeß endet, wenn das Programm zu ende ist, oder auch, wenn die Platte voll ist und nichts mehr ausgegeben werden kann)
Hoffentlich habe ich jetzt keinen Unsinn geschrieben, ich denke aber, dass es genauso ablaufen muss und gar nicht anders gehen kann.
. Die Shell muss VOR der Verarbeitung der Daten die Ausgabekanäle öffnen. Normalerweise ist dies die Console, auf der man gerade arbeitet, im Falle einer ausdrücklichen Umlenkung in eine Datei wird die Datei geöffnet.Wenn Du eine einfache spitze Klammer schreibst, wird eine bereits vorhandene zuerst geleert, bei zwei Klammern wird das, was da kommen mag, an die vorhandenen Daten angehängt. Ein kleiner Test zeigt, dass zumindest in der Bash unter Linux die Inode für die Datei erhalten bleibt:
Code:
$ echo hallo > blabla.text
$ ls -i blabla.text
803516 blabla.text
$ echo hallo > blabla.text
$ ls -i blabla.text
803516 blabla.textWenn dann nun also endlich die Ausgabedatei geöffnet ist, fängt die Shell an, das Kommando auszuführen und die Datenkanälee stdout und stderr (und evtl. weitere von dem ausgeführten Programm verwendete Ausgabekanäle) in ihre jeweiligen Ablagen zu plazieren.
(Der Prozeß endet, wenn das Programm zu ende ist, oder auch, wenn die Platte voll ist und nichts mehr ausgegeben werden kann)
Hoffentlich habe ich jetzt keinen Unsinn geschrieben, ich denke aber, dass es genauso ablaufen muss und gar nicht anders gehen kann.
