Idee: PyBar - Prozessbar für pipes in shell skripten...

[jens]

Es gibt bar: http://clpbar.sourceforge.net/ (installierbar e.g.: apt-get install bar)
u.a. gibt es was ähnliches als reines shell skript: http://www.theiling.de/projects/bar.html

Hilfreich z.B. beim SQL-Dump erstellen/einspielen oder bei längeren dd Aktionen.

Beide sind nett. Doch das erste muss ich erst installieren (ok, gibt auch kompilierte Pakete hier: http://sourceforge.net/projects/clpbar/files/ ) Das zweite muss man nicht installieren, hat aber im Grunde keine Anzeige, wenn die Quellen-Dateigröße nicht ermittelbar ist:

Infinite streams are not nice: the bar is only displayed at 0% and at 100%. Have some other form of entertainment, like the ASCII-propeller: propeller in ASCII art.

Wie wäre es mit einem kleinen Python Skript mit der selben Aufgabe?

[lunar]

@jens Und so ein Python-Skript muss man dann nicht installieren, oder wie? Fällt das dann magisch auf die Festplatte?

[jens]

Natürlich nicht. Aber es ist portabler als das Kompilierte bar und sollte halt was besseres Anzeigen, als das shell-skript bar, wenn Dateigröße unbekannt. (z.B. den Durchsatz)

[snafu]

Du willst ein ausgereiftes Programm in Python neuschreiben, damit du es außerhalb von Python verwenden kannst? Was spricht denn gegen die Installation über die Paketverwaltung? Vielleicht verrätst du mal mehr über deine Beweggründe, dann bisher kann das glaube ich niemand außer dir so recht nachvollziehen, welchen tieferen Sinn das Ganze hätte.

[jens]

Für den Fall:
* keine root rechte
* Infinite streams

btw. ist nur eine Idee im Ideen Forum. Denke nicht, das ich eine Implementierung es angehen werde. Wobei ich es grundsätzlich interessant finde.

[lunar]

@jens Unwahrscheinlich. Die Aufgabenstellung effizient und portabel zu lösen, ist nicht einfach, weil jedes System andere Systemaufrufe hat.

[jens]

Keine Ahnung. Aber im einfachsten Fall liest man von sys.stdin und schreibt nach sys.stdout und gibt die Daten auf sys.stderr aus... So würde ich zumindest anfangen.

Aber ok, bis man die ganze Funktionalität der anderen Programme nach implementiert hat, ist übermorgen...

btw. finde es sehr dumm, das viele Programme keinen Fortschritt auf der Konsole ausgeben und man das über diese Geschichte ändern kann...

[EyDu]

Bei den meisten Anwendungen ist es ja schon an sich sehr schwer überhaupt zu bestimmen, was Fortschritt im genannten Kontext ist. Man denke nur an die hübschen Balken beim Kopieren von großen Verzeichnissen, da ist die Abschätzung meistens eher sehr schlecht. In einem großen Teil der Fälle weiß man ja nicht einmal, wie weit man eine Aufgabe gelöst hat, da die Kosten der Zwischenschritte gar nicht richtig vorhergesagt werden können. Ich gebe mich daher durchaus damit zufrieden, wenn man dem Programm die Arbeit irgendwie ansehen kann. Sei es nun durch einen weiteren ausgegebenen Punkt alle paar Sekunden oder einfach nur eine Meldung, welcher Zwischenschritt gerade ausgeführt wurde.

[lunar]

@jens Sagte ich ja. Dein Ansatz ist zwar portabel, aber nicht effizient. Die Daten der Pipe wandern so durch diverse Puffer und Kontextwechsel zwischen Userspace und Kernel hin und her.

"pv" dagegen versucht mit den Mitteln des jeweiligen Systems Daten möglichst unter Umgehung aller Puffer vom Anfang zum Ende zu schicken, unter Linux beispielsweise mit "splice()". Ähnliche Systemaufrufe gibt es auch unter anderen Systemen…

[jens]

Stimmt. "pv" wollte ich mir auch mal ansehen.

Btw. mit portabel meinte ich jetzt nicht "für verschiedene Betriebssysteme". Ich nutzte das Ausschließlich unter Linux.

[snafu]

Für ``splice()`` gibt es übrigens ein Modul: http://pypi.python.org/pypi/splicetee

Aber von 2006, sehe ich gerade. Naja, ein Versuch ist es zumindest wert. Ggf auch als Orientierung für einen eigenen Wrapper.