GNU-Philosophie: Was ist "eine" Aufgabe?

[Kaj G. (Firma: RUB) (bloody)]

In der GNU-Philosophie heißt es:
"Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."

Aber was ist denn jetzt "genau eine" Aufgabe?
Wenn ich mal ein Programm nehme, das ich für die Firma geschrieben habe:
Da muss ich TCP bedienen, den seriellen Port muss ich bedienen, Daten 
konvertieren, etc...
Nach meinem Verständnis mehrere Aufgaben.

Was ist "eine" Aufgabe?

[c.m. (Gast)]

und was macht das programm?

pdf's anzeigen?
oder auch noch dazu…
- pdf's aufs dateisystem zugreifen lassen
- forms anbieten in 2 speicherformaten
- forms per http versenden
- inhalt signieren
- inhalt verschlüsseln
- inhalt mit berechtigungen versehen
- "javascript" ausführen
- calls an externe programme erlauben
- binäre dateien einbetten
- sound, video und animationen einbetten

pdf's anzeigen wäre eine aufgabe, der zeitlich dazugewachsene 
"zusatznutzen" ist featuritis (die das ganze schlechter wartbar und 
unsicherer macht).

eine aufgabe ist ein klar umrissener funktionsumfang. alles was 
programmiert werden muss um diesen funktionumfang zu ermöglichen ist 
nötig.

[Peter II (Gast)]

c.m. schrieb:
> eine aufgabe ist ein klar umrissener funktionsumfang. alles was
> programmiert werden muss um diesen funktionumfang zu ermöglichen ist
> nötig.

toll. Also wenn ich den Funktionumfang erweitere darf ich alles was 
gebraucht wird einbauen.

Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3 
Player mit ein.

[Bernd K. (prof7bit)]

Peter II schrieb:
> Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3
> Player mit ein.

Nein, Du machst eine Konfigurationsoption in der man auswählen kann 
welcher Player verwendet werden soll um die Musik abzuspielen.

[derElf (Gast)]

> Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3
> Player mit ein.

Da greift folgende Regel:

Niemals das Rad neu erfinden!

[Peter II (Gast)]

derElf schrieb:
> Niemals das Rad neu erfinden!

dann würde es Linux gar nicht geben?

Wie viel Editoren gibt es?
Wie viele Datenbanken gibt es?
Wie viel Shells gibt es?

Linux ist doch wohl das beste Beispiel dafür, wie oft dinge neu erfunden 
werden können.

[JJ (Gast)]

Peter II schrieb:
> derElf schrieb:
>> Niemals das Rad neu erfinden!
>
> dann würde es Linux gar nicht geben?
>
> Wie viel Editoren gibt es?
> Wie viele Datenbanken gibt es?
> Wie viel Shells gibt es?
>
> Linux ist doch wohl das beste Beispiel dafür, wie oft dinge neu erfunden
> werden können.

Darum gehts nicht. Es geht darum, dass wenn du ein Getriebe baust, nicht 
gleich das Rad mit dran schweißt

[Peter II (Gast)]

JJ schrieb:
> Darum gehts nicht. Es geht darum, dass wenn du ein Getriebe baust, nicht
> gleich das Rad mit dran schweißt

warum kann dann "find" Dateien löschen?

dafür gibt es doch "rm"?

[JJ (Gast)]

Das kann find auch nicht. Find kann rm aufrufen und benutzen.
Genau so etwas ist mit der Philosophie gemeint.

[Peter II (Gast)]

JJ schrieb:
> Das kann find auch nicht

schon mal die doku gelesen?

  -delete
              Delete files; true if removal succeeded.  If the removal 
failed,
              an  error message is issued.  If -delete fails, find's 
exit sta-
              tus will be nonzero (when it eventually exits).  Use of 
-delete
              automatically turns on the -depth option.




Es macht auch sinn, weil es schneller geht als ständig rm aufzurufen.
Das zeigt aber da es nicht viel sinn macht, sich stur an solche regeln 
zu halten.

[JJ (Gast)]

Ah, das kannte ich wirklich noch nicht. Das Feature widerspricht 
tatsächlich der Philosophie. Vermutlich war es einfach nur ziemlich 
einfach zu implementieren.

[JJ (Gast)]

Peter II schrieb:
> Es macht auch sinn, weil es schneller geht als ständig rm aufzurufen.
> Das zeigt aber da es nicht viel sinn macht, sich stur an solche regeln
> zu halten.

Klar, die Regeln sind ja auch nicht in Stein gemeißelt. Hintergrund ist, 
dass wenn du etwas einbaust, du es auch warten musst. Wenn der 
potentielle Aufwand den Nutzen rechtfertigt ist das natürlich ok.

[W.S. (Gast)]

Kaj G. schrieb:
> In der GNU-Philosophie heißt es:
> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."

Nun, das ist eben die "Tool"-Denkweise, die man bei Unix-Leuten immer 
noch antrifft. Ist heutzutage eigentlich herzlich überholt. 
Ausgeschrieben heißt das, sogenannte Tools, also 
Einzweck-Kommandozeilen-Programme herzunehmen, selbige in Shell-Skripten 
aufzurufen und daraus "höhere" Funktionalitäten zu bilden.

Das ist Murks, denn schon unsere Vorväter haben gewußt, daß ein Ganzes 
mehr ist als die Summe seiner Einzelteile. Genau deshalb haben sich 
weltweit ja auch komplexe Programme mit grafischer Oberfläche (Apps) 
durchgesetzt. Wer benutzt denn noch einen PC ausschließlich mittels 
Kommandozeile? Naja, vielleich 0.1% aller Anwender, also eine 
verschwindende Minderheit. Versuche doch mal als Beispiel, dir 
vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von 
Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen 
sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln.

Also mal plakativ formuliert: Heutzutage hat man Applikationen und 
grafische Oberflächen und die Kommandozeile nebst Shell-Skripten, wo 
dann irgendwelche simplen Einzweck-Programme drin vorkommen, sind Schnee 
von vor-vor-gestern.

Die Welt als solche IST komplex und Programme auf dem PC (und 
neuerdings auf dem smarten Phone) sind mittlerweile ebenso komplex.

W.S.

[Rolf M. (rmagnus)]

Peter II schrieb:
> c.m. schrieb:
>> eine aufgabe ist ein klar umrissener funktionsumfang. alles was
>> programmiert werden muss um diesen funktionumfang zu ermöglichen ist
>> nötig.
>
> toll. Also wenn ich den Funktionumfang erweitere darf ich alles was
> gebraucht wird einbauen.
>
> Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3
> Player mit ein.

Ist denn MP3 abspielen ein integraler Bestandteil des Anzeigens einer 
PDF-Datei? Ergibt sich irgendein signifikanter Nachteil, wenn das MP3 
nicht im PDF-Viewer, sondern in einem anderen Programm abgespielt wird? 
Wenn nicht, ist es nicht Teil der Funktion "Anzeigen einer PDF-Datei".

Peter II schrieb:
> warum kann dann "find" Dateien löschen?

GNU-Featuritis? Ich würde die Philosophie "ein Tool pro Aufgabe" nicht 
unbedingt als GNU-Philosophie bezeichnen, sondern eher als 
UNIX-Philosophie. Entsprechend findet man in der POSIX-Spezifikation von 
find auch keine Option zum Löschen von Dateien. Es handelt sich um eine 
GNU-Erweiterung.

[Nils S. (kruemeltee)]

Bevor wir hier Birnen mit Äpfeln........

Stellt sich auch zuallerst mal die Frage, was für eine Art Programm will 
ich erstellen?

Will ich nur Dateien löschen, dann brauche ich keinen Dateimanagr mit in 
rm einbauen.
Will ich einen Dateimanager "kann der" rm, cp, mv ... .
Ein Officepaket unterscheidet sich in gleicher weise von einer Library 
die Exel-Tabellen einliest.

//edit:
Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl 
eher:
> find . -exec rm {} \;
Ja - genau so mit der kruden Syntax.

[Peter II (Gast)]

Nils S. schrieb:
> Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl
> eher:
>> find . -exec rm {} \;
> Ja - genau so mit der kruden Syntax.

ja nur sau langsam.

[tom (Gast)]

GNU Emacs dürfte das beste Beispiel für diese Philosophie sein;)

Und Linux hat das Rad nicht neu erfunden, zu der Zeit gab es kein freies 
Unix(artiges) Betriebsystem für x86 das verfügbar war. Hurd befand sich 
noch in den frühsten Kinderschuhen, Minix war nicht frei und auf die 
reine Ausbildung ausgerichtet und (lite)BSDs rechtlichelage war noch 
nicht klar und es hing eine Klage seitens AT&T an.

[Nils S. (kruemeltee)]

Peter, weswegen wahrscheinlich die GNU-Erweiterung dazu kam.

Tom, das sind hauptsächlich keine Grunde für die Entwicklung von Linux, 
sonderrn Umstände, die es sehr früh gefördert haben.

[tom (Gast)]

Nils S. schrieb:
> Peter, weswegen wahrscheinlich die GNU-Erweiterung dazu kam.
>
> Tom, das sind hauptsächlich keine Grunde für die Entwicklung von Linux,
> sonderrn Umstände, die es sehr früh gefördert haben.

Linus wollte ein freies (wenn vielleicht im Sinne von Freibier) 
unixartiges System für seinen x86 und seine Minix-Erweiterungen haben 
dafür den Grundstein gelegt. Wäre ein anderes System ob BSD oder Hurd 
verfügbar gewesen so hätte er vermutlich nicht mit der Entwicklung 
begonnen. (das ist seine Aussage)

[Jörg W. (dl8dtl) (Moderator)]

tom schrieb:
> Wäre ein anderes System ob BSD oder Hurd verfügbar gewesen so hätte er
> vermutlich nicht mit der Entwicklung begonnen. (das ist seine Aussage)

Stimmt allerdings nicht ganz.  Zu der Zeit, als er mit Linux
angefangen hat, war Bill Jolitz mit 386BSD schon deutlich in der
Phase, dass das System selbst booten konnte (und von potenziellen
juristischen Problemen damit hat da noch keiner was geahnt).

Kann allerdings sein, dass er es noch nicht gewusst hat, die
Veröffentlichung von Bill Jolitz im Dr. Dobbs Journal könnte sich
zeitlich gerade so überschnitten haben mit seinen Anfängen.

Da er aber andererseits vor allem deshalb angefangen hat, weil er
überhaupt mal den protected mode des i386 kennenlernen wollte, ist
es durchaus zweifelhaft, ob ihn ein bereits vorhandenes freies System
tatsächlich davon abgehalten hätte, seinen Spieltrieb weiter zu
verfolgen.

Aber das nur am Rande.

[Noch einer (Gast)]

Das hat sich wohl erledigt.

Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte 
schrieben. Dafür brauchte man kleine Programme, die nur Dateien suchten, 
oder nur Textzeile aus Ascii-Dateien filterten.

Heutzutage benutzt ein normaler Mensch Dateimanager und Office-Paket. 
Wir haben keine Textdateinen mehr. Wir haben Emails mit Word-Attachment. 
Was  sollen wir da mit den alten Unix-Tools wie sed, grep und sort 
anfangen?

Nicht mal die Programmierer wollen heutzutage noch ein Makefile mit find 
und sed generieren.

[c.m. (Gast)]

Noch einer schrieb:
> Das hat sich wohl erledigt.
>
> Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte
> schrieben. Dafür brauchte man kleine Programme, die nur Dateien suchten,
> oder nur Textzeile aus Ascii-Dateien filterten.

och die braucht $admin immernoch.
und ganz ehrlich mag ich die gnu erweiterungen - es gibt nichts 
beschisseneres als ein grep das nicht rekursiv suchen kann oder ein tar 
das bei quelldateien>4GB runzickt.
aber ein tar das mir auf eine framebuffer console bilder anzeigen kann 
braucht kein mensch ;)

[Sebastian B. (smoere)]

Noch einer schrieb:
> Nicht mal die Programmierer wollen heutzutage noch ein Makefile mit find
> und sed generieren.

Dafür nehmen Programmierer (die nicht Klicki-Bunti machen) seit 
Ewigkeiten die GNU Autotools. Mit dem tollen Nebeneffekt dass es dann 
sehr (wenn auch leider nicht 100%) Plattform unabhängig wird.

[Robert L. (lrlr)]

> GNU-Philosophie

macht einheitliche Konfigurationsdateien steht da wohl nicht drin ;-)

[Noch einer (Gast)]

> die nicht Klicki-Bunti machen

Gibt es überhaupt noch Programmierer, die diese GNU Autotools verstehen? 
Das letzte mal habe ich 2010 davon gehört.

http://geekandpoke.typepad.com/geekandpoke/2010/05/how-to-become-invaluable.html

[Jörg W. (dl8dtl) (Moderator)]

Noch einer schrieb:
> Gibt es überhaupt noch Programmierer, die diese GNU Autotools verstehen?

Ob es jemanden gibt, der sie bis in die letzte Ecke versteht, weiß
ich nicht. ;-)  Aber benutzen kann man sie auch schon dann ganz gut,
wenn man die 50 % verstanden hat, die man am häufigsten braucht.

Ihr wesentlicher Vorteil gegenüber allen anderen Lösungen ist, dass
sie eben bei demjenigen, der den Salat dann compilieren soll, wirklich
nur eine Shell und ein paar gängigere Tools benötigen, während man bei
scons, cmake, … jeweils noch irgendwas zusätzlich auch auf der
Zielplattform braucht.

[Läubi .. (laeubi)]

Jörg W. schrieb:
> Ihr wesentlicher Vorteil gegenüber allen anderen Lösungen ist, dass sie
> eben bei demjenigen, der den Salat dann compilieren soll

Irgendeine unverständliche Fehlermeldung um die Ohren hauen die laut den 
Entwicklern "überhaupt nicht auftreten dürfte" ;-)

[Jay (Gast)]

W.S. schrieb:
> Unix

Robert L. schrieb:
>> GNU-Philosophie
>
> macht einheitliche Konfigurationsdateien steht da wohl nicht drin ;-)

So wie die Windows Registry? Auch der große Erfolg überhaupt.

Die Unix-Philosophie (GNU kam erst viel später) bei 
Konfigurationsdateien war eigentlich:

- Text

- Zeilenorientiert

- als dot-rc Datei im Home-Verzeichnis versteckt.

Dann kamen die speziellen Helden, die fanden, dass Environment-Variablen 
besser wären oder eine komplizierte Syntax her muss.

Im Ergebnis ist es jetzt genauso wild wie bei Windows. Zeig mir 
jemanden, der alle Einträge in der Registry versteht.

[Mostfett (Gast)]

Kaj G. schrieb:
> In der GNU-Philosophie heißt es:
> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."
Das stammt noch aus Zeiten der Ur-Unixsteinzeit, wo jedes Gramm zu viel 
Code den Speicher vollmüllte und Codewiederverwendung anders umgesetzt 
wurde.

Heute schreibt man Programme nach dem Motto: soll Funktion x am 
einfachsten erfüllen und benutzerfreundlich sein und mir nicht auf den 
Sack gehen.

Das Beispiel von find mit eingebautem Datei löschen zeigt es doch: Das 
braucht man oft also baut man es direkt ein ohne sich einen mit der 
Sythax abzubrechen, die zudem noch seltsame Seiteneffekte hat die ich 
bei bestimmten Sternenkonstellationen neachten muss.

Schreib dein Programm wie du es für am sinnvollsten hältst.

[Guest (Gast)]

W.S. schrieb:
> Das ist Murks, denn schon unsere Vorväter haben gewußt, daß ein Ganzes
> mehr ist als die Summe seiner Einzelteile. Genau deshalb haben sich
> weltweit ja auch komplexe Programme mit grafischer Oberfläche (Apps)
> durchgesetzt. Wer benutzt denn noch einen PC ausschließlich mittels
> Kommandozeile? Naja, vielleich 0.1% aller Anwender, also eine
> verschwindende Minderheit. Versuche doch mal als Beispiel, dir
> vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von
> Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen
> sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln.

Das letzte mal als du Linux benutzt hast hatte ein Monitor noch 80 
Zeichen breite oder? Es geht garnicht darum NUR konsolenprogramme mit 
minimaler Funktionalität zur Verfügung zu stellen. Die Sache musst du 
dir eigentlich andersrum überlegen. Stelle dir vor, jemand möchte ein 
tolles Programm schreiben um Datenträger zu partitionieren und 
formatieren. Mit der Windows-Mentalität müsste er dafür alle 
Dateisysteme und Datenträger-Header selbst implementieren und warten. 
Unter Linux braucht er nur die entsprechenden Tools aufrufen, fdisk, 
gdisk, mkfs.* usw. Den User freut es, weil das Programm stabiler Läuft 
und öfter Updates bekommt. Den Entwickler auch, weil er sich nur um das 
Interface und die Verbindung der Tools kümmern muss. Und der versierte 
Nutzer kann, wenn er keine Lust auf die GUI hat, die Tools auch einzeln 
ausführen. Wo ist da das Problem?

[Peter II (Gast)]

Guest schrieb:
> Stelle dir vor, jemand möchte ein
> tolles Programm schreiben um Datenträger zu partitionieren und
> formatieren. Mit der Windows-Mentalität müsste er dafür alle
> Dateisysteme und Datenträger-Header selbst implementieren und warten.

oder die passenden Bibliotheken verwenden.

> Unter Linux braucht er nur die entsprechenden Tools aufrufen, fdisk,
> gdisk, mkfs.* usw. Den User freut es, weil das Programm stabiler Läuft
> und öfter Updates bekommt. Den Entwickler auch, weil er sich nur um das
> Interface und die Verbindung der Tools kümmern muss.
und das ist gar nicht so einfach, weil er die Ausgaben von fdisk usw. 
parsen muss. Wenn fdisk jetzt auf die Idee kommt ihre Ausgaben anders zu 
formatieren (und wenn es nur die Sprache ist) geht es schief. Oder FDISK 
ändert die Parameter oder eingaben ab.

Damit muss man hier genauso die "Schnittstelle" pflegen.

Sinnvoller ist es Bibliotheken mit einer Definierten API zu schaffen, 
dann kann man sie überall nutzen.

[mec (Gast)]

Peter II schrieb:
> parsen muss. Wenn fdisk jetzt auf die Idee kommt ihre Ausgaben anders zu
> formatieren (und wenn es nur die Sprache ist) geht es schief. Oder FDISK
> ändert die Parameter oder eingaben ab.
>
> Damit muss man hier genauso die "Schnittstelle" pflegen.
>
> Sinnvoller ist es Bibliotheken mit einer Definierten API zu schaffen,
> dann kann man sie überall nutzen.


Was du da für Nachteile aufzählst, gilt doch genau so für Bibliotheken, 
wenn man da die Schnittstelle ändert.  Und außerdem ist man mit 
Bibliotheken erst einmal auf eine Programiersprache festgelegt.



"Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."

Sieht man, finde ich, am Schönsten beim betrachten der 
CD/DVD-Brennprogramme.
Bei Linux gibt es die Backend-Programme welche auch auf der Konsole 
Bedienbar sind und zusätzlich noch das Frontend, welches man auch nach 
belieben Austauschen kann.
Und zum Vergleich das völlige Gegenteil dazu ist z.B. Nero(gibt es das 
noch?), da kannst du dann mit dem Brennprogramm auch noch gleich den 
Videoschnitt machen ;)

[Peter II (Gast)]

mec schrieb:
> Was du da für Nachteile aufzählst, gilt doch genau so für Bibliotheken,
> wenn man da die Schnittstelle ändert.  Und außerdem ist man mit
> Bibliotheken erst einmal auf eine Programiersprache festgelegt.

nicht wirklich. Eine Änderung der API bekommt man dann vom Compiler 
geliefert. API sind etwas stabiler als der Input und Output eines 
Konsolenprogrammes.

Da jede Programmiersprache mehr oder weniger direkt Funktionen vom 
Betriebssystem aufrufen kann, scheint die "Sprache" wohl kein Problem zu 
sein.

[toolset (Gast)]

W.S. schrieb:
> Das ist Murks, denn schon unsere Vorväter haben gewußt, daß ein Ganzes
> mehr ist als die Summe seiner Einzelteile. Genau deshalb haben sich
> weltweit ja auch komplexe Programme mit grafischer Oberfläche (Apps)
> durchgesetzt.
...und wenn der Entwickler dieses tollen bunten Programms irgendeine 
Funktion nicht so implementiert wurde, wie ich sie benötige, schreibe 
ich einfach das Programm nochmal? soso....

[W.S. (Gast)]

Guest schrieb:
> Stelle dir vor, jemand möchte ein
> tolles Programm schreiben um Datenträger zu partitionieren und
> formatieren. Mit der Windows-Mentalität müsste er dafür alle
> Dateisysteme und Datenträger-Header selbst implementieren und warten.

Ja, kann ich mir vorstellen: Partition Magic zum Beispiel. Ist alt, 
sollte deshalb bekannt sein.

Wird per nacktem MSDOS gestartet, bringt seine eigene grafische 
Oberfläche nebst Mausbedienung mit, kann/konnte mit allen damals 
bekannten Dateisystemen umgehen. Und das MUSS so eine Anwendung auch, 
denn die Thematik ist zu komplex, um sie in einzelne 
Kommandozeilenprogramme aufzuteilen.

mec schrieb:
> Bei Linux gibt es die Backend-Programme welche auch auf der Konsole
> Bedienbar sind und zusätzlich noch das Frontend, welches man auch nach
> belieben Austauschen kann.
> Und zum Vergleich das völlige Gegenteil dazu ist z.B. Nero(gibt es das
> noch?), da kannst du dann mit dem Brennprogramm auch noch gleich den
> Videoschnitt machen

Man könnte glatt auf den Gedanken kommen, daß du so ein 
Backend-Gewurschtel nebst davon losgelöstem Frontend besser findest als 
eine richtige Anwendung, die das alles integriert in sich hat, 
konsistenter funktioniert und schlichtweg benutzerfreundlicher ist.

Ich zeig dir mal ein Gegenteil:
Kopiere mal ne Datei, sagen wir mal 1 GB, unter Linux von HD nach Stick, 
benutze dazu Krusader oder nen Dateimanager deiner Wahl. Was passiert? 
Nun - SCHEINBAR - wird die ganze Datei binnen 2 Sekunden auf den Stick 
kopiert. Danach steht der Fortschrittsbalken im Popupfenster des 
(eigentlichen) Kopierprogramms auf 100% - und dort bleibt er dann auch 
für die nächsten Minuten. Warum? Weil es bei dem tollen Tool-System eben 
keine sinnvolle Kopplung zwischen Frontend und Backend gibt.

Bei der Verfahrensweise, daß ein Frontend ein temporäres Skript oder 
Kommandozeile generiert und selbige dann quer durch's System zum 
ausführenden Tool geleitet wird, gibt es keine Echtzeit-verbindung 
zwischen Front und Back. Das ist saublöd, denn dabei ist in keiner Weise 
daran gedacht worden, daß vor dem PC ein MENSCHLICHER Benutzer sitzt und 
sich fragt, ob der PC abgestürzt ist. Bei sowas ist der 
Fortschrittsbalken völliger Mumpitz, denn er zeigt nicht im Geringsten 
den eigentlichen Stand der Bearbeitung an.

Ich hab's ja weiter oben schon geschrieben, daß diese Tool-Denkweise 
überholt ist. Mal ganz ordinär gesagt, ist sie scheisse, denn dabei 
werden immer nur die Befindlichkeiten von Programmierern berücksichtigt, 
die sich über komplexe Dinge keine Gedanken machen wollen - und die 
Bedürfnisse der Benutzer bleiben schlichtweg außen vor. OK, Admins, die 
über "userland" nur mit gerümpfter Nase sprechen, denken so und meinen 
daß dies die alleinseligmachende Denkweise sei, aber der Rest der Welt 
sieht das ganz anders.


W.S.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> Weil es bei dem tollen Tool-System eben keine sinnvolle Kopplung
> zwischen Frontend und Backend gibt.

Nö, aber schön, dass du auch ohne Analyse schon weißt, woran es liegt.

Da das zugrunde liegende Problem nicht so ganz trivial ist, wäre wohl
die Alternative vieler anderer Programme, dann einfach auf (sowieso
nicht funktionierende) Prozentzahlen zu verzichten und einen vor sich
hin wabernden Fortschrittsbalken anzuzeigen …

Ein besonders krasses Exemplar davon hatte ich mal vor Jahren bei
irgendeiner Software, die eine ISDN-Verbindung herstellen sollte.  Ich
musste beide Seiten konfigurieren (den Einwahlrouter und den Client):
während der Einwahlrouter innerhalb nullkommanix meldet, dass er den
Einwählenden abgewiesen hat, wabert der Fortschrittsbalken „Verbindung
wird aufgebaut“ noch 5 Sekunden vor sich hin, bis dann irgendwann die
lapidare Meldung „geht nich“ angezeigt wird.

In dem Falle dahingehend nicht tragisch, dass ich ja beide Seiten sehen
konnte, aber ein Nutzer, der nur den Client vor sich hat, wäre mit
einem (optional, braucht man ja nur zum Einrichten) in Echtzeit
angezeigten Log des Einwahl-Backends deutlich besser bedient gewesen.
Er hätte dann ohne „Kunstpausen“ sofort gesehen, dass das noch was
nicht stimmt, und die Logmeldungen hätten ihm vielleicht auch noch
verraten, was nicht passt.

[Jan H. (j_hansen)]

W.S. schrieb:
> Ja, kann ich mir vorstellen: Partition Magic zum Beispiel. Ist alt,
> sollte deshalb bekannt sein.
>
> Wird per nacktem MSDOS gestartet, bringt seine eigene grafische
> Oberfläche nebst Mausbedienung mit, kann/konnte mit allen damals
> bekannten Dateisystemen umgehen. Und das MUSS so eine Anwendung auch,
> denn die Thematik ist zu komplex, um sie in einzelne
> Kommandozeilenprogramme aufzuteilen.

Ganz im Gegenteil: gerade das lässt sich wunderbar in kleine Häppchen 
aufteilen.

> Man könnte glatt auf den Gedanken kommen, daß du so ein
> Backend-Gewurschtel nebst davon losgelöstem Frontend besser findest als
> eine richtige Anwendung, die das alles integriert in sich hat,
> konsistenter funktioniert und schlichtweg benutzerfreundlicher ist.

"Man könnte glatt auf den Gedanken kommen, dass du ein bloatiges 
Anwendungs-Gewurschtel besser findest, als ein richtig gut gemachtes 
Frontend, dass die Funktionalität schön abstrahiert hat, konsistent 
funktioniert und schlicht anwenderfreundlicher ist." Das ist genauso 
sinnvoll. Ja, eine gut gemachte Anwendung ist besser als Gewurschtel - 
unabhängig davon, nach welchem Prinzip die Anwendung entwickelt ist.

> Ich zeig dir mal ein Gegenteil:
> Kopiere mal ne Datei, sagen wir mal 1 GB, unter Linux von HD nach Stick,
> benutze dazu Krusader oder nen Dateimanager deiner Wahl. Was passiert?
> Nun - SCHEINBAR - wird die ganze Datei binnen 2 Sekunden auf den Stick
> kopiert. Danach steht der Fortschrittsbalken im Popupfenster des
> (eigentlichen) Kopierprogramms auf 100% - und dort bleibt er dann auch
> für die nächsten Minuten. Warum? Weil es bei dem tollen Tool-System eben
> keine sinnvolle Kopplung zwischen Frontend und Backend gibt.

Schlecht gemacht, aber das hat nichts mit der Architektur generell zu 
tun. Allgemein kenne ich dieses Problem nicht, und Krusader ist, wenn 
ich das richtig sehe, auch schon in die Jahre gekommen. Letztes stabile 
Release Anfang 2009, vielleicht solltest du einmal etwas moderneres 
probieren?

> Ich hab's ja weiter oben schon geschrieben, daß diese Tool-Denkweise
> überholt ist. Mal ganz ordinär gesagt, ist sie scheisse, denn dabei
> werden immer nur die Befindlichkeiten von Programmierern berücksichtigt,
> die sich über komplexe Dinge keine Gedanken machen wollen - und die
> Bedürfnisse der Benutzer bleiben schlichtweg außen vor. OK, Admins, die
> über "userland" nur mit gerümpfter Nase sprechen, denken so und meinen
> daß dies die alleinseligmachende Denkweise sei, aber der Rest der Welt
> sieht das ganz anders.

Interessante Meinung, ich teile sie aber ganz und gar nicht. Irgendwie 
scheint mir, als wärst du der Meinung, dass sich die Anwender hier ihre 
Tools generell selbst in der Kommandozeile verketten müssten.

[Rolf M. (rmagnus)]

Noch einer schrieb:
> Das hat sich wohl erledigt.
>
> Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte
> schrieben. Dafür brauchte man kleine Programme, die nur Dateien suchten,
> oder nur Textzeile aus Ascii-Dateien filterten.
>
> Heutzutage benutzt ein normaler Mensch Dateimanager und Office-Paket.

Ja, und man erkennt als jemand, der die alte Philosophie gewöhnt ist, 
schnell den Nachteil. Die neuen Programme sind Bloatware, vollgestopft 
mit den Dingen, von denen der Entwickler dachte, daß es das sei, was man 
braucht. Tausend Funktionen in ein einzelnes Programm gequetscht, und 
das, was man tatsächlich braucht, ist doch nicht dabei. Man wird in 
einen Workflow gezwängt, den der Hersteller vorgesehen hat, und wenn man 
es anders will, wird's hakelig und umständlich. Das System an die 
eigenen Bedürfnisse anpassen, geht nur noch in sehr engem Rahmen.

[Robert L. (lrlr)]

>Die neuen Programme

Word und Excel
oder was meinst

das ist alles Neuland für uns..
aber irgendwann werden wird das auch schaffen..!!

[Robert L. (lrlr)]

Nachtrag:
> Man wird in
>einen Workflow gezwängt, den der Hersteller vorgesehen hat, und wenn man
>es anders will, wird's hakelig und umständlich.

du scheinst noch sie ein Programm entwickelt zu haben.

die Einstellmöglichkeiten werden versteckt

DAS IST ABSICHT..stell dir vor jeder Kunden könnte überall 
herum-schrauben

und du bei jedem Supportfall erstmal schauen muss was er wo/wie 
unmögliches eingestellte haben könnte..

[Robert L. (lrlr)]

>Versuche doch mal als Beispiel, dir
>vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von
>Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen
>sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln.

super Beispiel ;-)

http://ftp6.nero.com/user_guides/utilities/nerocmd/NeroCMDUser.pdf

[Rolf M. (rmagnus)]

Robert L. schrieb:
> Nachtrag:
>> Man wird in
>>einen Workflow gezwängt, den der Hersteller vorgesehen hat, und wenn man
>>es anders will, wird's hakelig und umständlich.
>
> du scheinst noch sie ein Programm entwickelt zu haben.
>
> die Einstellmöglichkeiten werden versteckt
>
> DAS IST ABSICHT..stell dir vor jeder Kunden könnte überall
> herum-schrauben

Tja, ich bin dann wohl nicht Zielgruppe solcher Software, denn ich 
möchte mich nicht an das System anpassen müssen, sondern das System an 
mich anpassen. Natürlich hat sich die User-Landschaft im Laufe der Jahre 
geändert. Heute soll ein Computer so leicht zu bedienen sein, wie ein 
Toaster, so daß auch Leute, die sich damit nicht auskennen und nicht 
einen großen Teil ihrer Zeit damit verbringen, ihn nutzen können. Schade 
ist es nur, wenn für den heute wohl "Poweruser" genannten Benutzer 
dadurch alles umständlicher und schlechter anpassbar wird.

W.S. schrieb:
> Versuche doch mal als Beispiel, dir
> vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von
> Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen
> sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln.

Also ich bin mit k3b ganz zufrieden. Das ist ein Frontend für einen 
ganzen Stall von Kommandozeilentools zum Brennen von CDs und DVDs. Man 
muß keine Shellskripte schreiben, um es zu benutzen, aber wer irgendeine 
besondere Anforderung hat, kann die Tools auch direkt einzeln auf der 
Kommandozeile nutzen.

[Robert L. (lrlr)]

teil 1: nenn halt mal konkrete programme?

wenn ich mir anschauen, wie sich leute ihr Excel "angepasst" haben (mit 
macros usw.) wird einem eher schlecht... als dass man von "zuwenig 
Anpassung möglich" sprechen könnte)
das war früher allerdings schlimmer als jetzt..



teil 2: CD/DVD brennen interessiert eh keinen mehr..

[Michael E. (Firma: irgendeine) (nodalek)]

Vielleicht sollte man es wirklich als "Philosophie" sehen, und nicht als 
der Weißheit letzter Schluß, denn manchmal ist dieses Vorgehhen, und 
dann auch mal wieder das andere Vorgehen, sinnvoller. Einer liebt dies, 
der andere das.
Man sollte sich immer beide Seiten, vor- und Nachteile ansehen, und dann 
für sich das richtige Wählen.


Ich für mich, finde die Unix-Philosophi besser, sie ist anpassbarer, 
logischer und es dekt sich mit den ganzen Ratschlägen, wie man große und 
komplexe Dinge angehen sollte.

Und wenn man Geld verdienen will, wäre die Windows-Philosophy besser, 
damit kann man die Kunden viel besser binden und zur Melkkuh machen. 
Jeder flucht über das System, trozdem will man nicht umlehrnen ;)

[Karl Käfer (Gast)]

Peter II schrieb:
> c.m. schrieb:
>> eine aufgabe ist ein klar umrissener funktionsumfang. alles was
>> programmiert werden muss um diesen funktionumfang zu ermöglichen ist
>> nötig.
>
> toll. Also wenn ich den Funktionumfang erweitere darf ich alles was
> gebraucht wird einbauen.
>
> Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3
> Player mit ein.

...und dann willst Du noch Funktionen, um einzelne Worte aus Deinem PDF 
in einem Wörterbuch oder bei Google nachzuschlagen, und baust einen 
Webbrowser mit ein, danach willst Du bestimmte Textpassagen aus Deinem 
PDF per E-Mail verschicken und baust einen MUA ein, und dann möchtest Du 
noch formatierte Notizen in Deinem PDF einfügen und baust einen 
Wordprozessor ein, ...

Am Ende hast Du dann einen unwartbaren, unflexiblen, nicht erweiterbaren 
und instabilen Monolithen, der zwar alles kann, irgendwie, aber nichts 
richtig. Und um kurz in ein PDF-Datenblatt zu schauen, braucht alleine 
der Start Deines Programms zehn Minuten, und während es läuft, belegt es 
vier Gigabyte Arbeitsspeicher und lastet zwei CPU-Kerne voll aus...

Merkst Du was? Genau: das ist total bescheuert. Darum gibt es Programme, 
um PDFs anzuschauen, und andere, um MP3s anzuhören. Und wenn Du 
ernsthaft Funktionen für MP3s in Deinem PDF-Viewer haben willst, dann 
baust Du nur höchstens die Steuerung für einen externen MP3-Player ein, 
statt gleich einen ganzen MP3-Player.

[Karl Käfer (Gast)]

Peter II schrieb:
> JJ schrieb:
>> Darum gehts nicht. Es geht darum, dass wenn du ein Getriebe baust, nicht
>> gleich das Rad mit dran schweißt
>
> warum kann dann "find" Dateien löschen?
>
> dafür gibt es doch "rm"?

Trotzdem ist "find" zunächst nur ein Programm, um Dateien und 
Verzeichnisse zu finden. Wenn es mit den gefundenen Dateien und 
Verzeichnissen nichts tun kann, wäre das Programm als solches ziemlich 
sinnlos, oder? Deswegen kann es mit -exec ein externes Programm mit dem 
Gefundenen aufrufen, mit -print und -print0 das Gefundene ausgeben, oder 
es mit -delete eben auch löschen. Dabei ist -delete nur ein Shortcut für 
"-exec rm {} \;" mit dem zusätzlichen Vorteil, daß nicht für jede 
gefundene Datei eigens ein fork() und exec() zum Starten von /bin/rm 
ausgeführt werden muß. (Ja, neuere Versionen von find können an dieser 
Stelle "-exec rm {} +" benutzen, aber das ist hier nicht der Punkt.)

Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: 
find ist besonders gut darin, Dateien und Verzeichnisse zu finden und 
was damit zu machen, während rm besonders gut darin ist, Dateien und 
Verzeichnisse zu löschen. Da hättest Du mit ein bisschen Nachdenken aber 
auch selbst drauf kommen können, wenn Du nicht krampfhaft damit 
beschäftigt gewesen wärest, irgendwie einen Widerspruch zu konstruieren.

[Peter II (Gast)]

Karl Käfer schrieb:
> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs:

kann man sich auch einreden.

Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm 
Befehl.

[Karl Käfer (Gast)]

W.S. schrieb:
> Kaj G. schrieb:
>> In der GNU-Philosophie heißt es:
>> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."
>
> Nun, das ist eben die "Tool"-Denkweise, die man bei Unix-Leuten immer
> noch antrifft. Ist heutzutage eigentlich herzlich überholt.

Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein 
paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese 
Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens 
"Powershell" gegossen.

Insofern sind Deine Aussagen an ignoranter Inkompetenz kaum zu 
überbieten, aber das ist man von Dir ja gewohnt. :-)

[Tom M. (Gast)]

Rolf M. schrieb:
> Ja, und man erkennt als jemand, der die alte Philosophie gewöhnt ist,
> schnell den Nachteil. Die neuen Programme sind Bloatware, vollgestopft
> mit den Dingen, von denen der Entwickler dachte, daß es das sei, was man
> braucht.


Davon abgesehen gibt es viele Aufgaben, die automatisiert werden müssen, 
um effizient zu laufen. Natürlich kann der Heimanwender und 
Büroschreibling gerne mit Excel hantieren, aber das ist für gewisse 
Aufgaben nicht effizient.

[Peter II (Gast)]

Karl Käfer schrieb:
> Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein
> paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese
> Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens
> "Powershell" gegossen.

nein, sie arbeiten mit Libs(dlls) und nicht mit einzelnen Programme. 
Damit haben sie eine definierte API und nicht nur Aufrufparameter und 
Output der geparst werden muss.

[Karl Käfer (Gast)]

Nils S. schrieb:
> Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl
> eher:
>> find . -exec rm {} \;
> Ja - genau so mit der kruden Syntax.

Heutzutage kann man auch

find <where> <kriterium> -exec rm {} +

benutzen -- das übergibt immer so viel Gefundenes an eine Instanz von 
rm, bis die maximale Länge der Kommandozeile erreicht ist.

[Karl Käfer (Gast)]

Noch einer schrieb:
> Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte
> schrieben.

Apples MacOS hat jahrelang gar keine Shell mitgebracht, und Microsoft 
hat ebensolang versucht, die Kommandozeile aus dem System zu verbannen. 
Aber irgendwann haben sowohl Apple als auch Microsoft gemerkt, daß so 
eine Shell keineswegs antiquiert und in den Händen eines Könners ein 
viel flexibleres, leistungfähigeres, und produktiveres Werkzeug ist als 
der ganze klickibunte Mist ist. Und siehe da: urplötzlich hat MacOS seit 
Version X eine moderne, leistungsfähige Bash dabei, während MS mit der 
Powershell sogar eine eigene Neuentwicklung auf die Beine gestellt hat.

Anders gesagt: mittlerweile haben sogar die bornierten Hirnis bei 
Microsoft und Apple begriffen, was für ein mächtiges Werkzeug so eine 
Shell ist. Nur Du hast es offensichtlich immer noch nicht gerafft. Warum 
nur?

[Karl (Gast)]

Peter II schrieb:
> Karl Käfer schrieb:
>> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs:
>
> kann man sich auch einreden.
>
> Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm
> Befehl.

Wenn find rm aufruft ist es keine eigene Implementierung, weil dann find 
keinen Sourcecode zum löschen von Dateien hat.

Und die Philosophie von jede Aufgabe ein Programm steckt doch im 
übertragenden Sinne heute auch in der Modularisierung bzw. 
Objektorientierung. Man schreibt nicht 1000 Zeilen Code sondern Packt 
das in einzelne Module/Objekte.

Peter II, deine Verteufelung von Linux ist manchmal einfach nervend.

[Peter II (Gast)]

Karl schrieb:
>> Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm
>> Befehl.
>
> Wenn find rm aufruft ist es keine eigene Implementierung, weil dann find
> keinen Sourcecode zum löschen von Dateien hat.

find ruft aber nicht rm auf.

find hat es aber im Quellcode:

static bool
perform_delete (int flags)
{
  return 0 == unlinkat (state.cwd_dir_fd, state.rel_pathname, flags);
}

> Peter II, deine Verteufelung von Linux ist manchmal einfach nervend.
wo liest du das raus? Ich verwende selber Linux auf Servern.

[Lukas K. (carrotindustries)]

Karl Käfer schrieb:
> Nils S. schrieb:
>> Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl
>> eher:
>>> find . -exec rm {} \;
>> Ja - genau so mit der kruden Syntax.
>
> Heutzutage kann man auch
>

> find <where> <kriterium> -exec rm {} +
>

> benutzen -- das übergibt immer so viel Gefundenes an eine Instanz von
> rm, bis die maximale Länge der Kommandozeile erreicht ist.

Der (IMO) UNIXigere weg wäre es, wenn find einfach nur Dateinamen auf 
die Standardausgabe schreiben könnte. Löschen, etc. kann man dann ja mit 
| xargs rm o.ä. machen.

[Karl Käfer (Gast)]

Peter II schrieb:
> Karl Käfer schrieb:
>> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs:
>
> kann man sich auch einreden.
>
> Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm
> Befehl.

Welchen Teil von "Trotzdem ist "find" zunächst nur ein Programm, um 
Dateien und Verzeichnisse zu finden." hast Du nicht verstanden?

Wie gesagt: wenn Du nicht ständig bemüht wärst, irgendwelche 
Widersprüche zu konstruieren, nur um widersprechen zu können, wärst Du 
sicher selbst darauf gekommen. Aber so -- und obwohl Du oben selbst 
festgestellt hast, daß ein "-exec rm {} \;" bei vielen Fundstellen nicht 
sonderlich performant ist -- erkennst Du nicht einmal, daß "-delete" nur 
eine Möglichkeit in Form eines Shortcut für eine der drei Möglichkeiten 
"-exec rm {} \;", "-exec rm {} +" oder "-print0 | xargs -0 -- rm" ist. 
Wobei "rm" natürlich noch eine ganze Reihe weiterer Möglichkeiten 
bietet, die die Option "-delete" von find nicht hat: schau einfach mal 
in die Manpage von rm.

[Peter II (Gast)]

Karl Käfer schrieb:
> Welchen Teil von "Trotzdem ist "find" zunächst nur ein Programm, um
> Dateien und Verzeichnisse zu finden." hast Du nicht verstanden?

und welchen Teil von "Das hat in einen find nichts zu suchen" nach der 
GNU-Philosophie hast du nicht verstanden?

Es war nur als Beispiel gemeint, das man diese Philosophie nicht stur 
befolgen sollte, weil es teilweisen keinen Sinn macht.

[Karl Käfer (Gast)]

Peter II schrieb:
> Karl Käfer schrieb:
>> Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein
>> paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese
>> Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens
>> "Powershell" gegossen.
>
> nein, sie arbeiten mit Libs(dlls) und nicht mit einzelnen Programme.

Willst Du mich verarschen? Das Pipeline-Konzept, die Ausgabe eines Teils 
als Eingabe für den nächsten Teil zu benutzen und die einzelnen 
einfachen Teile zu einer wesentlich komplexeren Gesamtfunktion 
zusammenzusetzen, ist 1:1 von den UNIX-Shells geklaut.

Dabei ist es auch unter UNIX egal, ob ein Teil einer Pipe nun ein 
externes Programm oder ein Shell-Builtin aufruft -- im letzeren Fall ist 
das genau dasselbe wie bei den meisten Aufrufen in der Powershell, und 
im ersten Fall ist es genau wie wenn man ein eigenes Cmdlet in der 
Powershell benutzt.

[Peter II (Gast)]

Karl Käfer schrieb:
> Willst Du mich verarschen? Das Pipeline-Konzept, die Ausgabe eines Teils
> als Eingabe für den nächsten Teil zu benutzen und die einzelnen
> einfachen Teile zu einer wesentlich komplexeren Gesamtfunktion
> zusammenzusetzen, ist 1:1 von den UNIX-Shells geklaut.

und, was willst du jetzt damit sagen? Hat jemand etwas anders behauptet?

[RAX (Gast)]

Auf Mathematik übertragen hieße das wohl, man kommt überall mit 1 und + 
hin.

Ein klassischer Text dazu ist ganz gut verständlich
http://harmful.cat-v.org/cat-v/ und hier mit verlinkt:
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

Haskell funktioniert (und failt, siehe Grafik) ganz gut in dieser 
gedachten Richtung.

Beispielsitzung mit dem Haskellcompiler ghci:

Prelude> let add1 = (+1)

Prelude> add1 5
6

Prelude> map add1 [1..10]
[2,3,4,5,6,7,8,9,10,11]

Prelude> drop 5 (map add1 [1..10])
[7,8,9,10,11]

Prelude> reverse (drop 5 (map add1 [1..10]))
[11,10,9,8,7]

Aber Silberkugeln...
https://www.lug-ottobrunn.de/wiki/Basisregeln_zur_Softwareentwicklung

Letztlich:
a) Es kommt auf den Zusammenhang an ->  https://xkcd.com/224/
b) einfach modular, (+1) usw. braucht etwas Übung.

[Sheeva P. (sheevaplug)]

Peter II schrieb:
> Karl Käfer schrieb:
>> Willst Du mich verarschen? Das Pipeline-Konzept, die Ausgabe eines Teils
>> als Eingabe für den nächsten Teil zu benutzen und die einzelnen
>> einfachen Teile zu einer wesentlich komplexeren Gesamtfunktion
>> zusammenzusetzen, ist 1:1 von den UNIX-Shells geklaut.
>
> und, was willst du jetzt damit sagen? Hat jemand etwas anders behauptet?

Fassen wir den Verlauf an dieser Stelle doch einfach mal kurz zusammen: 
W.S. behauptet, daß die "Tool-Denkweise" wahlweise "saublöd", "scheisse" 
oder wenigstens "herzlich antiquiert" sei. (Nunja, jeder ist für seine 
kommunikativen Fähigkeiten selbst verantwortlich...)

Sheeva Plug führt daraufhin die Powershell als Beweis dafür an, daß 
genau diese "Tool-Denkweise" gerade bei Microsoft eine Renaissance 
erlebt, weil sogar Microsoft mittlerweile erkannt hat, daß diese 
"Tool-Denkweise" eine hervorragende Automatisierungs- und 
Benutzerschnittstelle darstellt.

Du widersprichst Sheeva Plug daraufhin mit dem, äh, "Argument", daß bei 
der Powershell keine externen Programme, sondern Bibliotheksfunktionen 
aufgerufen würden, was erstens einfach falsch ist und zweitens, selbst 
wenn es stimmen würde, vollkommen irrelevant wäre.

Denn gleichgültig, ob die Tools nun aus einer Bibliothek aufgerufen oder 
als externe Programme ausgeführt werden, gehört kein besonderes Genie zu 
der schlichten Erkenntnis, daß hinter dem ganzen Konzept der Powershell 
genau dieselbe "Tool-Denkweise" steckt wie bei den Shells unter Unix.

[Peter II (Gast)]

Sheeva P. schrieb:
> Du widersprichst Sheeva Plug daraufhin mit dem, äh, "Argument", daß bei
> der Powershell keine externen Programme, sondern Bibliotheksfunktionen
> aufgerufen würden, was erstens einfach falsch ist und zweitens, selbst
> wenn es stimmen würde, vollkommen irrelevant wäre.
genau das ist aber der Unterschied. Bibliotheken mit definierten APIs 
aufzurufen ist nicht wirklich vergleichbar mit externe Programm starten.

Und ja es stimmt. das die Cmdlet, keine einfache externen Programm sind
https://technet.microsoft.com/en-us/library/ms714395(v=vs.85).aspx

> Denn gleichgültig, ob die Tools nun aus einer Bibliothek aufgerufen oder
> als externe Programme ausgeführt werden, gehört kein besonderes Genie zu
> der schlichten Erkenntnis, daß hinter dem ganzen Konzept der Powershell
> genau dieselbe "Tool-Denkweise" steckt wie bei den Shells unter Unix.

nein, ist die die Denkweise das man möglichst viel Code wiederverwendet. 
Dabei ist das Aufrufen von externen Programm eine extrem "primitive" 
Version davon.

Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen.

[Christian B. (casandro)]

Ich glaube da hat der OP auch einiges verwechselt. Er meint wohl die 
Unix-Philosophie, nicht die GNU-Philosophie.

Und die wird im Buch "The Art of UNIX Programming" sehr gut besprochen.
http://www.catb.org/esr/writings/taoup/html/

[JJ (Gast)]

@ Peter II

Der fehlender Fortschrittsanzeiger hat weniger mit Programm oder 
Funktion zu tun als damit, dass es einfach nicht implementiert ist.
cp ist schlicht dann fertig, wenn EOF erreicht ist.

Es gibt genug Gegenbeispiele, die Ihren Fortschritt auf der Konsole 
ausspucken oder ihn nach /proc schreiben.

[Sheeva P. (sheevaplug)]

Peter II schrieb:
>> Denn gleichgültig, ob die Tools nun aus einer Bibliothek aufgerufen oder
>> als externe Programme ausgeführt werden, gehört kein besonderes Genie zu
>> der schlichten Erkenntnis, daß hinter dem ganzen Konzept der Powershell
>> genau dieselbe "Tool-Denkweise" steckt wie bei den Shells unter Unix.
>
> nein, ist die die Denkweise das man möglichst viel Code wiederverwendet.

Schwachsinn. Mit der "Tool-Denkweise", komplexere Funktionen durch die 
Verknüpfung einfacher Komponenten zusammensetzen, hat das nichts zu tun. 
Schwachsinn auch, weil klassische UNIX-Werkzeuge natürlich den Großteil 
ihres Code aus gemeinsamen Bibliotheken beziehen.

> Dabei ist das Aufrufen von externen Programm eine extrem "primitive"
> Version davon.

Schwachsinn. Kannst Du nicht zwischen Konzept und Umsetzung 
unterscheiden?

> Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen.

Schwachsinn. Ohne einen entsprechenden Mechanismus geht sowas bei einer 
Bibliotheksfunktion auch nicht. Solche Mechanismen kann man natürlich 
auch beim Aufruf eines externen Programms einbauen, sogar viel einfacher 
als bei einer Bibliotheksfunktion. Abgesehen davon hat das aber auch 
nichts mit der hier diskutierten "Tool-Denkweise" zu tun.

[Walter T. (nicolas)]

Sheeva P. schrieb:
> Schwachsinn.
> [...]
>
> Schwachsinn.
> [...]
>
> Schwachsinn.
> [...]

Man merkt: Hier schreibt der geborene Menschenfänger, der es schafft, 
Leser und Zuhörer auf seine Seite zu ziehen.

[Sheeva P. (sheevaplug)]

Walter T. schrieb:
> Sheeva P. schrieb:
>> Schwachsinn.
>> [...]
>>
>> Schwachsinn.
>> [...]
>>
>> Schwachsinn.
>> [...]
>
> Man merkt: Hier schreibt der geborene Menschenfänger, der es schafft,
> Leser und Zuhörer auf seine Seite zu ziehen.

Ach, weißt Du, ich möchte gar kein "Menschenfänger" sein. Darüber hinaus 
bin ich nicht dafür verantwortlich, wenn jemand anders Schwachsinn 
schreibt, und obendrein habe ich meine Aussagen, im Gegensatz zum 
Vorredner, in der Sache begründet. Nach den weder sachlichen noch 
begründeten Pöbeleien ("primitiv", "saublöd", "scheisse") finde ich 
"Schwachsinn" aber geradezu diplomatisch.

[peter 3 (Gast)]

Peter II ist so ein ganz besonderer Typ Mensch, welchen man manchmal 
begegnet. Ich habe nie die Motivation welche hinter diesem Verhalten 
steckt verstanden.

@ Peter II, du musst doch auch Zugeben, das der Ansatz mit den einzelnen 
Programmen auch einen großen Vorteil hat, nämlich der, dass man diese 
auch einzeln nutzen kann und bei bedarf auch schnell, ohne das man 
Programierkentnisse braucht, für Komplexere Aufgaben verknüpfen kann, 
oder?

Wenn man zuerst etwas mit einer Bib Programieren muss, und es dann sogar 
nur für eine einmalige Angelegenheit ist, hat man einfach zuviel Aufwand 
sich in die Programierung und API einzuarbeiten, oder?

[Peter II (Gast)]

peter 3 schrieb:
> @ Peter II, du musst doch auch Zugeben, das der Ansatz mit den einzelnen
> Programmen auch einen großen Vorteil hat, nämlich der, dass man diese
> auch einzeln nutzen kann und bei bedarf auch schnell, ohne das man
> Programierkentnisse braucht, für Komplexere Aufgaben verknüpfen kann,
> oder?

richtig. Aber man könnte auch zu jeder lib ein Konsolenprogramm dazu 
liefern. Dann kann man auch einfach ein GUI Programm ohne aufwand 
schreiben.

man sollte eh Funktionalitätund frontend trennen.

[Karl Käfer (Gast)]

Peter II schrieb:
> genau das ist aber der Unterschied. Bibliotheken mit definierten APIs
> aufzurufen ist nicht wirklich vergleichbar mit externe Programm starten.

Busybox ruft ebenfalls in der Regel keine externen Programme auf -- und 
auch die Applets von Busybox und die externen Programme haben eine klar 
definierte Schnittstelle: zeilenorientierten Klartext, den jeder Laie 
ohne Probleme lesen und verstehen kann. Prima, nicht wahr?

> nein, ist die die Denkweise das man möglichst viel Code wiederverwendet.

Dazu gibt es Shared Libraries.

> Dabei ist das Aufrufen von externen Programm eine extrem "primitive"
> Version davon.

Das mag zwar primitiv im Sinne von einfach, lesbar, und klar 
verständlich auch ohne Dokumentation sein. Aber ich halte das für einen 
großen Vorteil gegenüber einer Powershell, für deren Benutzung man 
zwingend auf die Dokumentation eines ultrafetten Frameworks wie .Net 
angewiesen ist.

Vermutlich benutzt deswegen ein signifikanter Anteil der UNIX-Anwender 
gerne die Shell und nimmt ihr UNIX nicht zuletzt deswegen als besonders 
leistungsfähig, flexibel und mächtig wahr, während sich die Powershell 
unter Windows eher mäßiger Beliebtheit erfreut und Windows trotz 
nominell ähnlicher Möglichkeiten immer noch der Nimbus mangelhafter 
Flexibilität, Automatisierbarkeit und Mächtigkeit anhängt.

> Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen.

Die ist bei Kommandozeilenprogrammen sogar einfacher zu realisieren 
(siehe zum Beispiel apt-get(8) oder rpm(8)), weil diese Programme nicht 
nur über ihren Rückgabewert mit ihrem Aufrufer kommunizieren, sondern 
zusätzlich über die Standardein- und -ausgabekanäle STDIN, STDOUT, und 
STDERR.

Eine Bibliotheksfunktion hingegen kommuniziert mit ihrem Aufrufer ohne 
zusätzliche Maßnahmen lediglich über ihren Rückgabewert. Wenn sie ihren 
Fortschritt an den Aufrufer zurück melden will, muß sie dies über die 
Modifikation einer Variablen tun, die sowohl dem Aufrufer als auch der 
Funktion bekannt ist. Unser Aufrufer muß wiederum den Variableninhalt 
periodisch auf Fortschritte überprüfen, was bedeutet, daß Funktion und 
Aufrufer mindestens in verschiedenen Prozessen, Threads, oder gar unter 
einem eigenen Scheduler laufen müssen.

[Peter II (Gast)]

Karl Käfer schrieb:
> Eine Bibliotheksfunktion hingegen kommuniziert mit ihrem Aufrufer ohne
> zusätzliche Maßnahmen lediglich über ihren Rückgabewert. Wenn sie ihren
> Fortschritt an den Aufrufer zurück melden will, muß sie dies über die
> Modifikation einer Variablen tun, die sowohl dem Aufrufer als auch der
> Funktion bekannt ist. Unser Aufrufer muß wiederum den Variableninhalt
> periodisch auf Fortschritte überprüfen, was bedeutet, daß Funktion und
> Aufrufer mindestens in verschiedenen Prozessen, Threads, oder gar unter
> einem eigenen Scheduler laufen müssen.

Unsinn, es reicht einfach eine Callback festzulegen. Dafür braucht man 
keine Threads oder mehre Prozesse.

[morob65 (Gast)]

Peter II schrieb:
> Nils S. schrieb:
>> Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl
>> eher:
>>> find . -exec rm {} \;
>> Ja - genau so mit der kruden Syntax.
>
> ja nur sau langsam.

joo, aber man kann eine beliebige menge an dateien löschen.

[Karl Käfer (Gast)]

Peter II schrieb:
> Unsinn, es reicht einfach eine Callback festzulegen.

Dann mußt Du Deine Callbackfunktion irgendwie übergeben, aber das ist 
viel komplizierter als den Fortschritt einfach auf STDOUT zu schreiben.

[Robert L. (lrlr)]

>viel komplizierter als den Fortschritt einfach auf STDOUT zu schreiben.

findest?
STDOUT ist doch "human readable" (für console gedacht)
jedes Programm macht das irgendwie anders..
das aufrufende Programm muss es mühsam Parsen
STDOUT wird u.u. schon für andere Ausgaben gebraucht (die Prozentangabe 
müsste irgendwie hineinversteckt werden)

dagegen kannst (könnte man) einen callback für fortschritt ganz einfach, 
für jede (ich nenn es mal) Modul einheitlich definieren..


(wie gut/schlecht das ganze funktioniert sieht man IMHO recht gut am 
Webserver: CGI vs. "module")

[W.S. (Gast)]

Karl Käfer schrieb:
> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs:
> find ist besonders gut darin, Dateien und Verzeichnisse zu finden und
> was damit zu machen, während rm besonders gut darin ist, Dateien und
> Verzeichnisse zu löschen. Da hättest Du mit ein bisschen Nachdenken aber
> auch selbst drauf kommen können, wenn Du nicht krampfhaft damit
> beschäftigt gewesen wärest, irgendwie einen Widerspruch zu konstruieren.

Ah ja - und das soll tatsächlich BESSER sein, als alles andere?

Fall 1: du suchst mit wildcards, also unvollständigem Dateinamen. Find 
findet da alles mögliche (logo) und rm putzt es von der Platte weg. 
Klasse. Hättest du als Benutzer des PC nicht vielleicht eher das 
Bedürfnis, vor dem gnadenlosen Löschen das Ganze erst noch mal in einer 
netten Listbox anzuschauen - vielleicht hast du dich in irgend einem 
Kringel geirrt und hättest bei dir selbst richtigen Schaden zugefügt. 
Also Listbox mit der Möglichkeit, das eine oder andere von der Liste 
lieber doch zu streichen. Das geht aber nur mit grafischer Oberfläche 
und nicht per Kommandozeile.

Fall 2: du suchst mit qualifiziertem, also vollem Dateinamen. Wozu dann 
das find, wenn du es schon vorher weißt? Bloß um das Eintippen des 
Pfades zu vermeiden?

Merkst du endlich was?

Karl Käfer schrieb:
> Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein
> paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese
> Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens
> "Powershell" gegossen.

Die Tool-Denkweise IST überholt. Genauso wie die Lehre von der 
scheibenförmigen Erde. Da hilft dir auch kein vehementes Pfeifen im 
Walde.


So.
Erstens ist für mich niemand heilig, weder du noch Microsoft noch der 
Papst oder sonstwer.

Zweitens: Wer benutzt denn sowas wie Powershell? Ich kenne da niemanden, 
der sowas tut. Es hat auch noch nie viele Leute gegeben, die den 
Scripting-Host benutzt haben. Die Leute benutzen den Explorer und wer 
den nicht mag, nimmt den TC. Ja, das ist auch so ein mächtiges Werkzeug, 
was so überhaupt nicht eurer Denke entspricht.

Drittens: Dieser ganze Thread ist ein etwa 10 jähriges deja vu. Auch 
damals haben Eiferer aus dem Linux-Lager zu jeder Gelegenheit die 
absolute Unübertrefflichkeit ihres BS betont und im selben Atemzug gegen 
Windows nebst Bill Gates sämtliche Flüche ausgestoßen, die ihnen 
einfielen.

Und jetzt?
- Windows ist immer noch der absolute Marktführer -ätsch.

- Wenn überhaupt was anderes angedacht wird, kaufen sich die Leute einen 
Mac - nochmal ätsch.

- Linux, FreeBSD und Konsorten machen zwar allzeit und überall einen 
Riesentraffic, aber die 5% Hürde haben sie noch lange nicht erklommen.

"Bäsch gehabbd" sagt der Sachse dazu. Aber das stimmt nicht. Es war und 
ist kein Pech, sondern die schiere Dummheit, mit Fleiß sämtliche 
Bedürfnisse von etwaigen Kunden in den Wind zu schlagen, immer alles 
besser zu wissen und ein Loblied auf Kommandozeile, Skripte und 
Steinalt-Progrämmchen zu singen, wo der Rest der Welt es seit Windows 
3.1 ganz anders haben will.

Und wenn euch gar keine Argumente mehr einfallen, dann spielt ihr 
beleidigte Leberwurst. Wie kann man auch nur die veralteten Dinge beim 
Namen nennen. Als nächstes wird vielleicht TAR gelobt, weil man ja 
neuerdings nach unbestätigten Gerüchten gehört haben will, daß Bill 
Gates das papierene Lochband wieder aus der Versenkung holen will...

W.S.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> Hättest du als Benutzer des PC nicht vielleicht eher das Bedürfnis, vor
> dem gnadenlosen Löschen das Ganze erst noch mal in einer netten Listbox
> anzuschauen

Wenn man das Bedürfnis hat, dann nimmst man ein Tool, welches einen
dieses Bedürfnis ausleben lässt.  Du tust ja gerade so, als würden
alle Unixer noch vor VT100s sitzen und hätten noch nie sowas wie einen
grafischen (oder textmäßigen, Norton-Commander-Clones stehen da bei
vielen nicht nur Unixern nach wie vor hoch im Kurs) Dateimanager
gesehen.

Wenn ich aber nach einer Patchorgie alle Dateien, die auf *.orig
oder *.rej lauten, löschen lassen will, dann bin ich mir auch mit
dem Absenden des find-Kommandos bereits hinreichend sicher, dass
ich das jetzt will.  Dann brauch' ich nicht noch eine lästige
Bestätigungsbox.

Wenn ich temporäre Dateien nächtlich bereinigen lassen will, für die
sich beispielsweise seit 30 Tagen kein Schwein mehr interessiert hat
(die Suche nach Dateien, die eine bestimmte Zeit lang niemand mehr
gelesen hat, ist eine der möglichen Optionen), meinst du ich möchte
dann nachts um 3 Uhr aufstehen und einen „OK“-Button drücken?  Aber
genau für solche Fälle ist die -delete Option eben gut.

[Uwe B. (boerge)]

MoinMoin

W.S. schrieb:
> Es war und
> ist kein Pech, sondern die schiere Dummheit, mit Fleiß sämtliche
> Bedürfnisse von etwaigen Kunden in den Wind zu schlagen, immer alles
> besser zu wissen und ein Loblied auf Kommandozeile, Skripte und
> Steinalt-Progrämmchen zu singen, wo der Rest der Welt es seit Windows
> 3.1 ganz anders haben will.

Es kommt doch darauf an, welche Bedürfnisse der Benutzer hat! Wenn er 
der Meinung ist, so wie scheinbar auch du, alles schick bunt und mit 
Sicherheitsabfragen vorgesetzt zu bekommen, dann ist es gut und soll 
auch so sein. Für den sind die mächtigen Tools, wie du sie so vehement 
forderst, auch genau die richtigen. Dann muss man aber auch mit den 
Unzulänglichkeiten dieser Programme, die nur so gut sind, wie der 
Entwickler sie geplant und umgesetzt hat, leben.

Wer aber Aufgaben auf seinem Rechner zu erledigen hat, die vielleicht 
nicht in das Schema solcher eierlegenden Wollmilchsäue passen, ist 
glücklich, wenn er ein Toolset zur Verfügung hat, mit dem er seine 
Abläufe nach seinem Anforderungen zusammenstellen kann. Das dies 
vielleicht mehr Aufwand bedeutet, ist unbestreitbar, aber in vielen 
Fällen die Beste und manchmal einzige Lösung, um eine Aufgabe effektiv 
und zielgerichtet zu erledigen.

...und die Geschichte ist kein Glaubenskrieg irgendwelcher 
Betriebssystemfanatikern, die angeblich noch immer vor ASCII-Terminals 
oder Fernschreibern sitzen, sondern nur einfach eine Möglichkeit, wie 
man mit einem Rechner arbeitet und arbeiten könnte. Ich bekenne mich 
auch zu dieser "5%-Minderheit", würde mir aber nie anmaßen, die anderen 
95% als Unwissende (noch milde ausgedrückt, im Gegensatz zu dir) zu 
bezeichnen! Jeder benutzt seinen Rechner und Software, so wie er es 
möchte und kann. Nebenbei, das ist einer der Grundregeln Freier 
Software...

W.S. schrieb:
> Als nächstes wird vielleicht TAR gelobt, weil man ja
> neuerdings nach unbestätigten Gerüchten gehört haben will, daß Bill
> Gates das papierene Lochband wieder aus der Versenkung holen will...

...naja, den nächsten Streit fängst du gerade an, weil dir vielleicht 
die Argumente ausgehen. Aber um das qualifiziert zu machen, solltest du 
erst mal nachlesen, was tar eigentlich ist und kann. Den Zusammenhang 
zwischen Lochstreifen und tar kannte ich noch nicht, aber ich bin ja 
nicht allwissend...

[Bernd W. (berndwiebus)]

Hallo W.S.

W.S. schrieb:
> Es war und
> ist kein Pech, sondern die schiere Dummheit, mit Fleiß sämtliche
> Bedürfnisse von etwaigen Kunden in den Wind zu schlagen,

Linux hat KEINE KUNDEN. Es wird rein für sich selber und für andere 
schräge Vögel, die genauso drauf sind, programmiert.

Es ist für halt für Leute, die dem Mainstream nicht viel abgewinnen 
können, egal wie toll der auch sein mag. ;O)

Nebenher: Wieso stört es Dich eigentlich, wenn Leute ihren eigenen Kram 
machen, wenn er Dich eh nicht interessiert, und der sowieso nach Deiner 
Ansicht gesellschaftlich irrelevant ist?

> immer alles
> besser zu wissen und ein Loblied auf Kommandozeile, Skripte und
> Steinalt-Progrämmchen zu singen, wo der Rest der Welt es seit Windows
> 3.1 ganz anders haben will.

Es ist eher selten, dass ich privat bei Linux eine Kommandozeile 
verwende.
Auf der Arbeit mit Windows aber recht häufig.

Soviel also zu Deinem Bezug zur Realität. ;O)

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

[mec (Gast)]

das ist ungefähr so wie der Vergleich von Playmobil zu Lego ;)

[Walter T. (nicolas)]

W.S. schrieb:
> Wer benutzt denn sowas wie Powershell? Ich kenne da niemanden,
> der sowas tut.

Mit dieser Aussage zeigst Du, daß du in der Welt der integrierten, 
grafischen Werkzeuge zuhause bist. Oder kurz: daß Deine Computernutzung 
in eine Richtung geht, in der die Frage nach der Modularität von 
Konsolenwerkzeugen für eine Aufgabe völlig irrelevant ist. Warum willst 
Du dann unbedingt mitdiskutieren? Warum läßt Du nicht einfach die 
Kommandozeile und die Leute, die gerne damit arbeiten, in Ruhe? Wir 
lassen im Gegenzug auch die Leute, die im Jahr 2015 immer noch einen 
Norton-Commander-Klon benutzen in Ruhe. (Und das fällt mir auch nicht 
immer leicht.)

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Karl Käfer schrieb:
>> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs:
>> find ist besonders gut darin, Dateien und Verzeichnisse zu finden und
>> was damit zu machen, während rm besonders gut darin ist, Dateien und
>> Verzeichnisse zu löschen. Da hättest Du mit ein bisschen Nachdenken aber
>> auch selbst drauf kommen können, wenn Du nicht krampfhaft damit
>> beschäftigt gewesen wärest, irgendwie einen Widerspruch zu konstruieren.
>
> Ah ja - und das soll tatsächlich BESSER sein, als alles andere?

Ja, das ist es -- weil ich die Dateien und Verzeichnisse nicht nur 
finden, sondern auch gleich be- und verarbeiten kann.

> Fall 1: du suchst mit wildcards, also unvollständigem Dateinamen. Find
> findet da alles mögliche (logo) und rm putzt es von der Platte weg.
> Klasse. Hättest du als Benutzer des PC nicht vielleicht eher das
> Bedürfnis, vor dem gnadenlosen Löschen das Ganze erst noch mal in einer
> netten Listbox anzuschauen - vielleicht hast du dich in irgend einem
> Kringel geirrt und hättest bei dir selbst richtigen Schaden zugefügt.
> Also Listbox mit der Möglichkeit, das eine oder andere von der Liste
> lieber doch zu streichen. Das geht aber nur mit grafischer Oberfläche
> und nicht per Kommandozeile.

Selbstverständlich geht das auch auf der Kommandozeile: da rufe ich find 
einmal mit meinem Suchmuster ohne "-delete" auf, schon habe ich meine 
Liste. Ich persönlich bevorzuge allerdings die Lösung mit "-exec rm {} 
+": die ist fast genau so schnell wie "-delete", aber besser steuerbar.

> Fall 2: du suchst mit qualifiziertem, also vollem Dateinamen. Wozu dann
> das find, wenn du es schon vorher weißt? Bloß um das Eintippen des
> Pfades zu vermeiden?

Hin und wieder kommt es vor, daß ich zwar den Dateinamen weiß, aber 
nicht mehr, wo (Pfad) ich die Datei abgelegt habe. Das ist natürlich 
mein ganz eigenes Organisationsproblem, ändert aber nichts daran, daß 
ich dank find eine exrem effiziente Möglichkeit habe, mit dem Problem 
umzugehen.

> Merkst du endlich was?

Es bist Du, der nichts merkt und keine Ahnung hat, wovon der redet. Ich 
arbeite täglich mit der Kommandozeile und weiß deswegen sehr genau, wie 
effizient, flexibel und schnell das ist.

> Karl Käfer schrieb:
>> Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein
>> paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese
>> Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens
>> "Powershell" gegossen.
>
> Die Tool-Denkweise IST überholt. Genauso wie die Lehre von der
> scheibenförmigen Erde. Da hilft dir auch kein vehementes Pfeifen im
> Walde.

Hört sich für mich so an, als ob Du eigentlich nur neidisch auf die 
Leute bist, die die Flexibilität und Effizienz der Kommandozeile nutzen 
können. In so einem Fall hat man zwei Möglichkeiten: die Intelligenten 
lernen, wie das geht, und die anderen starten einen Kreuzzug, um sich 
wenigstens noch selbst einreden zu können, sie seien der Held. :-)

> Zweitens: Wer benutzt denn sowas wie Powershell? Ich kenne da niemanden,
> der sowas tut.

Ich kenne einen Exchange-Spezialisten, der die Powershell benutzt, aber 
der ist auch der Einzige. Und ja, die Powershell wird selten benutzt, 
weil sie eben keine klar verständliche Plaintext-Schnittstelle benutzt, 
sondern .NET-Objekte, so daß jeder, der sie benutzen will, dazu zwingend 
solide .NET-Kenntnisse benötigt. Aber wer ohnehin .NET kennt, nimmt 
vermutlich lieber VB(A) und Co.

Trotzdem ändert das nichts daran, daß alle modernen Betriebssysteme eine 
leistungsfähige Kommandozeilenumgebung haben, weil deren Hersteller im 
Gegensatz zu Dir erkannt haben, was für eine leistungsfähige, flexible, 
moderne und effiziente Möglichkeit zur Bedienung und Steuerung eines 
Computers das ist. Ob Du das verstehen willst oder nicht, ist dabei vor 
allem Eines: nämlich vollkommen nebensächlich.

> Es hat auch noch nie viele Leute gegeben, die den
> Scripting-Host benutzt haben. Die Leute benutzen den Explorer und wer
> den nicht mag, nimmt den TC. Ja, das ist auch so ein mächtiges Werkzeug,
> was so überhaupt nicht eurer Denke entspricht.

Ach Gottchen, ja, der Explorer. Solche Dateimanager gibt es -- in 
deutlich leistungsfähigeren Versionen -- natürlich auch unter Linux, und 
für Leute, die mit Kommandozeilen überfordert sind, sind sie eine prima 
Sache. Aber wer die Kommandozeile beherrscht, kann damit Sachen machen, 
bei denen die GUI-Benutzer nur noch mit den Ohren schlackern und sich 
mit ihren dummen grafischen Werkzeugen buchstäblich zu Tode klicken.

[Walter T. (nicolas)]

Sheeva P. schrieb:
> für Leute, die mit Kommandozeilen überfordert sind, sind sie eine prima
> Sache.

Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden, 
der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Und 
nutzt Du echt Lynx, um im Internet zu surfen? Achwas... echte Männer 
surfen mit "wget".

Es gibt Aufgaben, für die GUIs besser geeignet sind. Es gibt Aufgaben, 
für die Kommandozeilenwerkzeuge besser geeignet sind. Und deswegen nutzt 
man einfach beide.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> Achwas... echte Männer surfen mit "wget".

Nö, mit "telnet" und "script" (damit die Daten auch gespeichert werden 
;).

$ telnet www.mikrocontroller.net http
Trying 188.40.52.210...
Connected to www.mikrocontroller.net.
Escape character is '^]'.
GET /user/show/nicolas HTTP/1.1
Host: www.mikrocontroller.net

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Fri, 06 Nov 2015 09:07:30 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Status: 200 OK
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Cache-Control: private
Vary: Cookie
ETag: W/"a89c830e807670cd200fdc8b762194dc"
Set-Cookie: _forum_session=Y3BmSjJMY0RqTmg3SjFWYzRpMWZvSXFMVTlweGl1WUdzV0NTOGZEa2xuK2V5ZktveGN3bWdvejQ3TmtHclVEa0JyVU8wTnNHSUsxcG9jOXp6d3Mzc0lnTTVHb2dwTEdRWld6aXg2OSs4VFlhYUhqcDNXUU9ZWjUyWXlObmM2cXk3QVhFZHBiZmF6RVY0d0paaWNHdnplRVRjaldudHVBZjl1ZC9wWUZWb2lGdkd2ZXk4SDlsN0NQa0gvVTJ3Z0RjLS1iYUs3L1FlWTBOTnJFZ2VpV1RmYkxRPT0%3D--2e3a091170a9a14b39453c0022adc5fcfc22a139; path=/; expires=Mon, 16 Nov 2015 09:07:30 -0000; HttpOnly
X-Request-Id: 6051532d-6e40-4a0f-856f-3e464f97bec8
X-Runtime: 0.061774
Alternate-Protocol: 443:npn-spdy/3

3096
<!DOCTYPE html>
<html lang="de" dir="ltr">
<head>
  <title>
      User information - Mikrocontroller.net
  </title>
  <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
…

[Frank M. (ukw) (Moderator)]

Peter II schrieb:
> Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen.

Was interessiert mich eine Fortschrittsanzeige in einem Cron-Job, der 
nachts um ein Uhr läuft, wo ich schlafe?

Soll mir der Fortschrittsbalken dann per Mail zugeschickt werden oder 
was?

Merke:

Es gibt sinnvolle Aufgaben für die Kommandozeile, nämlich 
nicht-interaktive (oder wenig interaktive) Programme. Das macht man 
besser mit der Shell. Genau aus diesem Grunde verwendest Du auch 
Linux-*Server* (oder habe ich mich da verlesen?), denn Server 
interagieren ziemlich wenig mit dem Otto-Normal-User. Das machen 
ausgelagerte Programme wie Web-Browser, File-Manager oder andere 
Programme, die auf dem Client-System laufen. Man braucht auch in der 
Regel kein Word oder Excel auf einem "Server".

Es gibt sicher sinnvolle Aufgaben, die man besser mit einer graphischen 
Benutzeroberfläche löst. Das ist aber in den wenigsten Fällen ein 
Klicki-Bunti-Programm, dem ich sage: Lösche mir ab einem bestimmten Ast 
im Dateibaum alle *.BAK-Dateien.

Daher sehe ich das so:

Für jede Aufgabe das geeignete System. Von "antiquierter" Kommandozeile 
zu sprechen zeugt lediglich von stark beschränkter Sicht.

[Robert L. (lrlr)]

jetzt hat nur blöderweise "Kommandozeile vs. GUI" nichts mit  der Frage 
zu tun hat.. (soll ein Ding nur eine Aufgabe können)



gibt ja auch Kommandozeilenprogramme die 20 Seiten ausspucken wenn man 
--help anfügt: da kann dann von "EINER" aufgabe nicht mehr wirklich die 
rede sein (egal ob jetzt linux oder windows)

andererseits gibt auch GUI-Programme die "wiederkehrende Aufgaben" 
wesentlich besser erstellen (und vorallem debuggen) lassen, als das mit 
script-sch.. je möglich wäre..

z.b. www.finalbuilder.com

[Karl Käfer (Gast)]

Walter T. schrieb:
> Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden,
> der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Und
> nutzt Du echt Lynx, um im Internet zu surfen? Achwas... echte Männer
> surfen mit "wget".

Wir sind da schon etwas weiter und benutzen w3m. ;-)

[Karl Käfer (Gast)]

Robert L. schrieb:
> gibt ja auch Kommandozeilenprogramme die 20 Seiten ausspucken wenn man
> --help anfügt: da kann dann von "EINER" aufgabe nicht mehr wirklich die
> rede sein (egal ob jetzt linux oder windows)

Manche Kommandozeilenprogramme erledigen eben sehr komplizierte 
Aufgaben.

> andererseits gibt auch GUI-Programme die "wiederkehrende Aufgaben"
> wesentlich besser erstellen (und vorallem debuggen) lassen, als das mit
> script-sch.. je möglich wäre..
>
> z.b. www.finalbuilder.com

Wie lustig. Was genau soll dieses klickibunte Machwerk denn bitte besser 
können als die herkömmlichen Build-Werkzeuge? Wenn ich da nur mal auf 
die Screenshots schaue... da lob' ich mir GNU Make.

[Karl Käfer (Gast)]

Frank M. schrieb:
> Peter II schrieb:
>> Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen.
>
> Was interessiert mich eine Fortschrittsanzeige in einem Cron-Job, der
> nachts um ein Uhr läuft, wo ich schlafe?
>
> Soll mir der Fortschrittsbalken dann per Mail zugeschickt werden oder
> was?

;-)

Zumal der Fortschrittsbalken ja ohnehin häufig nur Unsinn anzeigt. Unter 
Windows kenne ich das Verhalten, daß der Balken erst zügig bis ca. n% 
fortschreitet, dann ewig dort hängenbleibt und schließlich ganz schnell 
auf 100% springt. Was für einen Informationswert soll so eine eindeutig 
fehlerhaften, irreführenden Anzeige denn haben?

Auch bei Dateisystemoperationen sind Fortschrittsbalken unsinnig, weil 
unter dem Dateisystem ein Dateisystempuffer und ein Journal liegen, 
deren Zustände sich nicht abfragen lassen. Dabei zeigt der 
Fortschrittsbalken an, daß die Dateisystemoperation beendet sei, 
tatsächlich sind die Daten aber gerade nur im Puffer angekommen und 
müssen jetzt erstmal ins Journal geschrieben und dann ins eigentliche 
Dateisystem übertragen werden. Dabei zeigt Peter II's toller 
Fortschrittsbalken an, die Operation sei bereits beendet, aber in 
Wahrheit werden die Daten erst beim "sicheren Aushängen" des USB-Sticks 
auf denselben geschrieben.

[Peter II (Gast)]

Karl Käfer schrieb:
> Zumal der Fortschrittsbalken ja ohnehin häufig nur Unsinn anzeigt.

scheinbar kennst du den Unterschied nicht mal zwischen einen 
Fortschrittsbalken und einer geschätzten Laufzeit.

[Daniel A. (daniel-a)]

Karl Käfer schrieb:
> Walter T. schrieb:
>> Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden,
>> der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Und
>> nutzt Du echt Lynx, um im Internet zu surfen? Achwas... echte Männer
>> surfen mit "wget".
>
> Wir sind da schon etwas weiter und benutzen w3m. ;-)

Ich bin auch für wget, manchmal villeicht noch curl, telnet und links.

links ist der einzige mir bekannte Browser, der die Testseite
http://danielabrecht.ch:8080/ korrekt verarbeitet. wget macht auch keine 
Probleme, aber w3m sagt mir nur "gzip: stdin: not in gzip format"

[Robert L. (lrlr)]

Karl Käfer schrieb:
> Wie lustig. Was genau soll dieses klickibunte Machwerk denn bitte besser
> können als die herkömmlichen Build-Werkzeuge?


die Frage muss lauten: was kann der "Enduser" mit dem Werkzeug besser 
machen

und da sind GUIs eben doch (viel) selbsterklärender ...

wenn du jemanden der das noch nie gemacht hat, beide "Werkzeuge" in die 
Hand drückst, wird er nach 3 Stunden mit GNU Make genau garnix gemacht 
haben.. (obwohl es theoretisch irgendwie gehen würde)

mit dem "klickibunti" wird er e-mails versenden können, cd-brennen, 
ftp-uploads machen, regitry einträge ändern, zip-files erstellen, etwas 
in einem xmlfile ändern, usw. usw und ja, auch eine Compiler aufrufen 
oder ein help-filer erstellen lassen...

(https://www.finalbuilder.com/finalbuilder/feature-matrix)

OHEN auch nur ansatzweise im Detail wissen zu müssen wie es im 
funktioniert

(das ganze mit oder ohne userinteraktion, je nach aufgabe)

bei gnu make müsste er sich für jedes Programm erstmal ewig einlesen..

[Karl Käfer (Gast)]

Robert L. schrieb:
> Karl Käfer schrieb:
>> Wie lustig. Was genau soll dieses klickibunte Machwerk denn bitte besser
>> können als die herkömmlichen Build-Werkzeuge?
>
> die Frage muss lauten: was kann der "Enduser" mit dem Werkzeug besser
> machen

Wir reden hier von einem Build-Werkzeug. Sowas wird üblicherweise nicht 
von Entenbenutzern benutzt, sondern von Entwicklern.

> und da sind GUIs eben doch (viel) selbsterklärender ...

Wenn ich mir die Screenshots so anschaue, halte ich das für ein Gerücht. 
Dieses heillose Chaos aus tausend verschiedenen Eingabemasken ist nicht 
übersichtlicher als ein dokumentiertes und strukturiertes Makefile.

> wenn du jemanden der das noch nie gemacht hat, beide "Werkzeuge" in die
> Hand drückst, wird er nach 3 Stunden mit GNU Make genau garnix gemacht
> haben.. (obwohl es theoretisch irgendwie gehen würde)

Das wage ich zu bezweifeln: alleine die ausufernde Vielfalt von Optionen 
und Screens (siehe Screenshots) setzen auch bei dem Klickibuntidings 
eine ziemliche Einarbeitungszeit voraus. Vielleicht kann man damit schon 
nach drei Stunden ein paar ganz einfache Sachen machen, zum Beispiel ein 
"Hello World"-Programm übersetzen, aber sowas Einfaches bekommt man mit 
GNU Make sicher mindestens genauso schnell hin -- sogar ohne ein 
Makefile schreiben zu müssen, am Rande bemerkt.

[Karl Käfer (Gast)]

Daniel A. schrieb:
> Karl Käfer schrieb:
>> Walter T. schrieb:
>>> echte Männer surfen mit "wget".
>>
>> Wir sind da schon etwas weiter und benutzen w3m. ;-)
>
> Ich bin auch für wget, manchmal villeicht noch curl, telnet und links.
>
> links ist der einzige mir bekannte Browser, der die Testseite
> http://danielabrecht.ch:8080/ korrekt verarbeitet. wget macht auch keine
> Probleme, aber w3m sagt mir nur "gzip: stdin: not in gzip format"

Bei w3m unter Ubuntu 15.10 kommt: "abc test" (genauso übrigens wie bei 
"GET http://danielabrecht.ch:8080/ | gunzip"). Das ist korrekt, oder?

[CQ_One (Gast)]

Robert L. schrieb:
> und da sind GUIs eben doch (viel) selbsterklärender ...
>
> wenn du jemanden der das noch nie gemacht hat, beide "Werkzeuge" in die
> Hand drückst, wird er nach 3 Stunden mit GNU Make genau garnix gemacht
> haben.. (obwohl es theoretisch irgendwie gehen würde)
>
> mit dem "klickibunti" wird er e-mails versenden können, cd-brennen,
> ftp-uploads machen, regitry einträge ändern, zip-files erstellen, etwas
> in einem xmlfile ändern, usw. usw und ja, auch eine Compiler aufrufen
> oder ein help-filer erstellen lassen...
Diese annahme ist schlicht falsch! Du gehst davon aus, der angenomme 
User hat schon irgendwann mal mit einem Computer was zu tun gehabt und 
weiß wie eine GUI aussieht...

Nimm für deinen Test einen Nutzer der noch nie was mit einem Computer 
zu tun gehabt hat (das beinhaltet auch smartphones, handys, etc.), 
einen, der das wort nicht kennt, und auch technisch keine ahnung hat, 
was das sein könnte.

Dieser Nutzer wird nach 3 Stunden mit sicherheit keine cd brennen 
können, keine e-mail schreiben können, keine ftp-uploads machen 
können... der wird nach 3 stunden exakt gar nichts machen können.

GUIs sind für uns halbwegs selbsterklärend, weil wir die scheiße schon 
jahre lang nutzen, und eingetrichtert bekommen: Das ist so, das muss so, 
das war schon immer so, das wird immer so sein.
Nur und ausschließlich deswegen würde ein 'normaler' nutzer nach 3 
stunden mit der GUI irgendwas auf die reihe bekommen.

[Daniel A. (daniel-a)]

Karl Käfer schrieb:
> Bei w3m unter Ubuntu 15.10 kommt: "abc test" (genauso übrigens wie bei
> "GET http://danielabrecht.ch:8080/ | gunzip"). Das ist korrekt, oder?

Ja, Welche w3m Version war das? Ich hatte es mit w3m/0.5.3+debian-19 
unter debian jessie versucht.

[Sheeva P. (sheevaplug)]

Walter T. schrieb:
> Sheeva P. schrieb:
>> für Leute, die mit Kommandozeilen überfordert sind, sind sie eine prima
>> Sache.
>
> Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden,
> der seine Fotos (ausschließlich) mit der Kommandozeile sortiert.

Das ist einer von den Fällen, in denen ein GUI enorm nützlich sein kann, 
aber dabei geht es eher um das Management von Inhalten. Doch die meisten 
Aufgaben im Dateimanagement können immer noch sehr bequem und effizient 
auf der Kommandozeile erledigt werden.

Das hängt natürlich auch davon ab, welche Dateiformate genutzt werden. 
Ein Entwickler, der hauptsächlich mit Quelltexten arbeitet, hat daher 
mehr von einer Kommandozeile als ein Grafikdesigner, Videobearbeiter 
oder jene, die schon einfache Notizen in Binärformaten speichern...

> Es gibt Aufgaben, für die GUIs besser geeignet sind.

Das hat niemand bezweifelt, ...

> Es gibt Aufgaben, für die Kommandozeilenwerkzeuge besser geeignet sind.

...jenes hingegen schon.

> Und deswegen nutzt man einfach beide.

Die Mehrheit der Computerbenutzer tut das eben nicht -- auf der einen 
Seite, weil Leute wie Peter II und W.S. ihnen einreden, daß das ganz 
schrecklich kompliziert und total antiquiert sei, und auf der anderen 
Seite, weil mit dem weitestverbreiteten Betriebssystem ausgelieferten 
Kommandozeilenwerkzeuge entweder unkomfortabel und wenig leistungsfähig 
sind, oder weil sie nur mit Programmierkenntnissen des .NET-Framework 
effektiv benutzt werden können.

[Dirk (Gast)]

> In der GNU-Philosophie heißt es:
> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."

Der Gründer des GNU-Projektes, Richard Stallman, hält sich mit seinem 
Emacs selbst nicht daran. Emacs kann man auch als Editor verwenden. Zum 
Kaffeekochen allerdings noch nicht.


> Mit dem tollen Nebeneffekt dass es dann
> sehr (wenn auch leider nicht 100%) Plattform unabhängig wird.

Das interessiert heute doch leider nur noch wenige. Die meisten Firmen 
hätten lieber ihre proprietäre Insellösung um sich von der Konkurrenz 
abzuheben. Aufs  iPhone kann man seine mp3s nur mit einem 
Spezialprogramm laden. Es wäre zu einfach und zu Plattformunabhängig, 
wenn das so einfach wie mit einem USB-Stick ginge. Und Microsoft hätte 
gern ihre eigene HTML-Version, eigene Dateiformate sowieso. Das nur als 
Beispiel.

[Sheeva P. (sheevaplug)]

Dirk schrieb:
>> In der GNU-Philosophie heißt es:
>> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut."
>
> Der Gründer des GNU-Projektes, Richard Stallman, hält sich mit seinem
> Emacs selbst nicht daran. Emacs kann man auch als Editor verwenden.

Eigentlich hält sich RMS sehr wohl an die UNIX-Philosophie: Emacs ist 
ein erweiterbarer Editor. Daß es Leute gegeben hat, die alle möglichen 
und unmöglichen Erweiterungen dafür gestrickt haben, von denen manche 
nicht unbedingt zu den Kernaufgaben eines Editors und / oder einer IDE 
gehören, widerspricht dem prinzipiell nicht.

> Zum Kaffeekochen allerdings noch nicht.

Aber natürlich kann er das: http://www.emacswiki.org/emacs/CoffeeMode

[Tunix (Gast)]

Karl Käfer schrieb:
> Trotzdem ist "find" zunächst nur ein Programm, um Dateien und
> Verzeichnisse zu finden. Wenn es mit den gefundenen Dateien und
> Verzeichnissen nichts tun kann, wäre das Programm als solches ziemlich
> sinnlos, oder? Deswegen kann es mit -exec ein externes Programm mit dem
> Gefundenen aufrufen, mit -print und -print0 das Gefundene ausgeben, oder
> es mit -delete eben auch löschen. Dabei ist -delete nur ein Shortcut für
> "-exec rm {} \;" mit dem zusätzlichen Vorteil, daß nicht für jede
> gefundene Datei eigens ein fork() und exec() zum Starten von /bin/rm
> ausgeführt werden muß. (Ja, neuere Versionen von find können an dieser
> Stelle "-exec rm {} +" benutzen, aber das ist hier nicht der Punkt.)

Besser:

find . -print0 -name 'foo' | xargs -0 rm

Und wenn mehrere rm gleichzeitig laufen sollen:

find . -print0 -name 'foo' | xargs -P <jobs> -n <max_per_job> -0 rm

Das ist damit gemeint.

[Tunix (Gast)]

CQ_One schrieb:
> Nimm für deinen Test einen Nutzer der noch nie was mit einem Computer
> zu tun gehabt hat (das beinhaltet auch smartphones, handys, etc.),
> einen, der das wort nicht kennt, und auch technisch keine ahnung hat,
> was das sein könnte.

Dieser Fall ist nicht der Maßstab für Alles, oder warum macht man 
Platinenlayouts nicht mit einem Malprogramm?

[Tunix (Gast)]

W.S. schrieb:
> Fall 1: du suchst mit wildcards, also unvollständigem Dateinamen. Find
> findet da alles mögliche (logo) und rm putzt es von der Platte weg.
> Klasse. Hättest du als Benutzer des PC nicht vielleicht eher das
> Bedürfnis, vor dem gnadenlosen Löschen das Ganze erst noch mal in einer
> netten Listbox anzuschauen - vielleicht hast du dich in irgend einem
> Kringel geirrt und hättest bei dir selbst richtigen Schaden zugefügt.
> Also Listbox mit der Möglichkeit, das eine oder andere von der Liste
> lieber doch zu streichen. Das geht aber nur mit grafischer Oberfläche
> und nicht per Kommandozeile.

find kann mehr als löschen.

[Sheeva P. (sheevaplug)]

Tunix schrieb:
> Karl Käfer schrieb:
>> Trotzdem ist "find" zunächst nur ein Programm, um Dateien und
>> Verzeichnisse zu finden. Wenn es mit den gefundenen Dateien und
>> Verzeichnissen nichts tun kann, wäre das Programm als solches ziemlich
>> sinnlos, oder? Deswegen kann es mit -exec ein externes Programm mit dem
>> Gefundenen aufrufen, mit -print und -print0 das Gefundene ausgeben, oder
>> es mit -delete eben auch löschen. Dabei ist -delete nur ein Shortcut für
>> "-exec rm {} \;" mit dem zusätzlichen Vorteil, daß nicht für jede
>> gefundene Datei eigens ein fork() und exec() zum Starten von /bin/rm
>> ausgeführt werden muß. (Ja, neuere Versionen von find können an dieser
>> Stelle "-exec rm {} +" benutzen, aber das ist hier nicht der Punkt.)
>
> Besser:
>
> find . -print0 -name 'foo' | xargs -0 rm

"find . -print0 -name 'foo' -exec rm {} +" macht ziemlich genau 
dasselbe.

> Und wenn mehrere rm gleichzeitig laufen sollen:
>
> find . -print0 -name 'foo' | xargs -P <jobs> -n <max_per_job> -0 rm

Gute Idee... Aber wenn ich mal so viele Dateien löschen müssen, daß sich 
eine Parallelisierung lohnen würde, habe ich schon vorher einen Fehler 
gemacht, fürchte ich. ;-)

[W.S. (Gast)]

Sheeva P. schrieb:
>> Und deswegen nutzt man einfach beide.
>
> Die Mehrheit der Computerbenutzer tut das eben nicht -- auf der einen
> Seite, weil Leute wie Peter II und W.S. ihnen einreden, daß das ganz
> schrecklich kompliziert und total antiquiert sei,

Gröhl...

Junge, den Leuten braucht man garnix einzureden, denn sie haben schon 
lange mit den Füßen abgestimmt. Erzähl mal deiner Tochter, daß sie ihre 
email oder mms per Kommandozeile abschicken soll - sie wird dich 
schlichtweg auslachen.

Nee, hier greinen Außenseiter vor sich hin. Leute, die schon längst auf 
dem Abstellgleis gelandet sind und die vehement versuchen, sich das auch 
noch schönzureden.

Ich hab da mal einen kleinen Vergleich zur Hand:

Anno 1994 war das: Da haben extrem von sich selbst überzeugte OS/2 Leute 
eine ziemlich ähnliche Diskussion geführt. Alles was außerhalb von OS/2 
war, wurde als unqualifiziert und lächerlich bezeichnet. Selbst von 
herzlich unqualifizierten Vergleichen schreckten diese Knaller nicht 
zurück - und hier kommt das Beispiel: Da schrieb einer, daß alle, die 
auf Windows setzen, doch vergleichbar seien mit Leuten die aus dem 1. 
Gang ihres Autos nicht herauskämen. Nun, auf sowas antwortete 
unsereiner, daß ich bei meinem Auto nur 2 und 3 kenne, aber 
normalerweise nur D nehme und daß das Auto damit weitaus besser fährt 
als mit dem 1. Gang. Kapiert haben diese Trottel es aber nicht.

So, nun faßt euch an eure jeweiligen Nasen.

W.S.

[RAX (Gast)]

An die Nase fassen wäre eine Aufgabe.

An die Nase fassen, sich dabei gleichzeitig den Kopf kratzen, Hänschen 
Klein sächsisch singen (alternativ pfeifen) und mit den Augen eine 
virtuelle (etwa doppelt Carrerabahn groß) Acht verfolgen und mit dem 
linken Fuß in etwa nach Süden zeigen, mit dem rechten Fuß in etwa nach 
Norden, wäre irgendwie...

[Yalu X. (yalu) (Moderator)]

W.S. schrieb:
> Gröhl...
>
> Junge, den Leuten braucht man garnix einzureden, denn sie haben schon
> lange mit den Füßen abgestimmt. Erzähl mal deiner Tochter, daß sie ihre
> email oder mms per Kommandozeile abschicken soll - sie wird dich
> schlichtweg auslachen.

Es ist Samstagnacht, da fällt es zum Glück nicht so auf, wenn du
herumgröhlst :)

Falls du trotzdem noch einigermaßen aufnahmebereit bist, lass dir gesagt
sein, dass es Leute gibt, die einen Computer nicht ausschließlich für
E-Mail, Word und Internet-Surfen einsetzen.

Ursprünglich wurden Computer ja dazu erfunden, um benutzerdefinierte,
häufig wiederkehrende Abläufe automatisch abzuarbeiten. Und genau für
diese Sorte von Anwendungen stellt die Unix-Philosophie eine große Hilfe
dar, da damit das Rad nicht immer wieder neu erfunden werden muss. Und
diese Anwendungen gibt es auch heute mehr denn je, nur vielleicht nicht
bei dir.

Mittlerweile wird der Computer aber zusätzlich auch für interaktive
Anwendungen genutzt, wo ein Großteil der Arbeit nicht vom Computer,
sondern vom Benutzer gemacht werden muss, weil bspw. dessen Erfahrung
oder Kreativität gefordert sind. Zu diesen Anwendungen zählen u.a.
Textverarbeitungs- , Mal- und CAD-Programme. Da diese Programme i.Allg.
immer als Ganzes benötigt werden, ist es hier wenig sinnvoll, sie in
Einzelwerkzeuge aufzuteilen. Da hast du völlig recht.

Für diese interaktiven Anwendungen hat sich aber ein anderer Trend
durchgesetzt, der ebenfalls aus dem Unix-Umfeld kommt: Skripting. Die
besseren dieser Programme (und sogar Word und Excel) verfügen praktisch
alle über einen Interpreter für eine Skriptsprache, mit der innerhalb
der Anwendung Abläufe automatisiert werden können.

Und für die einzelnen Funktionen, die der Interpreter zur Verfügung
stellt, gilt wiederum: Jede Funktion sollte eine einzelne, klar
abgegrenzte Aufgabe erfüllen. Ein VBA-Skript in Word oder ein ULP in
Eagle unterscheidet sich vom Prinzip her kaum von einem Shell-Skript,
nur die Syntax und die Basisfunktionen sind anders.

Man hat hier also die Unix-Philosophie von der Betriebssystemsebene (wo
sie nach wie vor gültig ist) in die Anwendungsebene übertragen.

Auch in der Anwendungsebene gilt: Nicht jeder braucht diese Möglichkeit
der Automatisierung, es gibt aber welche, die damit sehr viele Stunden
ihrer wertvollen Arbeitszeit einsparen können. Und genau dafür sind
Computer gemacht: um Zeit zu sparen.

[Bernd K. (prof7bit)]

> Die Mehrheit der Computerbenutzer

Die Mehrheit der Computerbenutzer benutzt den Computer nur sehr 
ineffizient und viele Dinge die theoretisch der Computer für sie 
erledigen könnte tun sie lieber von Hand weil sie nicht nicht wissen wie 
sie dem Computer überhaupt mitteilen könnten was sie erledigt haben 
wollen.

Das liegt daran daß ihr Dialog mit der Maschine, bzw die Sprache in der 
er geführt wird, nur aus Zeigen und Klicken besteht. Deshalb können sie 
nur vorgefertigte Vorgänge auslösen. Deshalb sind sie für jede einzelne 
neue Aufgabe die sie erledigt haben wollen entweder darauf angewiesen 
sich von der kleinen Minderheit der Computerprogrammierer ein neues 
Programm (Äpp) mit neuen Buttons und Menüs anfertigen zu lassen auf die 
sie klicken können, oder sie verzichten schlichtweg darauf und erledigen 
die Aufgabe von Hand.

Die Minderheit der Computerprogrammierer jedoch beherrscht den Dialog 
mit der Maschine über Sprachen und Kommunikationskanäle die weit über 
Zeigen und Klicken hinausgehen, sie sind in der Lage neue 
Aufgabenstellungen so zu formulieren daß der Computer sie versteht und 
ausführen kann, das nutzen sie dann entweder für ihre eigenen Zwecke 
oder sie verpacken es in einer "Äpp" und verkaufen es dem 
Computerbenutzer, auf daß er drauf klicken möge.

So war das schon immer, so wirds auch immer bleiben.

Und nichts davon ist antiquiert. Ohne die kleine Gruppe der 
Programmierer die den reichhaltigen schriftlichen Dialog mit der 
Maschine nutzen weil mit der Babysprache allein (Zeigen auf Bilder und 
"dada" sagen (Mausklick)) einfach keine neuen Ideen oder komplexe 
Anweisungen vermittelt werden können, ohne diese kleine Gruppe von 
Leuten die mit dem Gerät wirklich in ganzen Sätzen mit Punkt und Komma 
sprechen können (und dafür gerne dieses kleine schwarze Chat-Fenster 
nehmen) hätte die große Gruppe der Anwender überhaupt nichts worauf sie 
klicken könnten.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Gröhl...
>
> Junge, den Leuten braucht man garnix einzureden, denn sie haben schon
> lange mit den Füßen abgestimmt. Erzähl mal deiner Tochter, daß sie ihre
> email oder mms per Kommandozeile abschicken soll - sie wird dich
> schlichtweg auslachen.
>
> Nee, hier greinen Außenseiter vor sich hin. Leute, die schon längst auf
> dem Abstellgleis gelandet sind und die vehement versuchen, sich das auch
> noch schönzureden.

YMMD.

[Linuxnutzer, der auch vi, sed, awk nutzt (Gast)]

Yalu X. schrieb:
> Mittlerweile wird der Computer aber zusätzlich auch für interaktive
> Anwendungen genutzt, wo ein Großteil der Arbeit nicht vom Computer,
> sondern vom Benutzer gemacht werden muss, weil

Korrigiere bitte mal dein verzerrtes Weltbild. Heutzutage sind die von 
dir genannten interaktiven Anwendungen der Haupteinsatzbereich und nicht 
nur "zusätzlich". Nahezu jeder Mitarbeiter (auch die meisten 
Bildungsfernen) haben heutzutage Zugriff auf solche interaktiven 
Anwendungen. Damit meine ich nicht nur die reinen Bürokräfte (die 
anzahlmäßig in den meisten Firmen die Mehrheit bilden) wo jeder seinen 
Windows-PC hat. Dazu zählt der Produktionshelfer genauso wie der 
Ingenieur, der mit einer grafischen IDE programmiert.

Dazu kommt noch die große Anzahl der embedded Systems in Maschinen, die 
der Anwender nicht sieht und die er auch nicht direkt bedient. Auf die 
trifft deine Aussage eher zu. Aber die werden nur von den jeweiligen 
Spezialisten programmiert und konfiguriert. Der Maschinenbediener 
bekommt davon nichts mit. Für ihn gibt es eine intuitive interaktive 
Benutzerschnittstelle mit vom Entwickler vorgegebener Features.

[Sheeva P. (sheevaplug)]

Bernd K. schrieb:
> Die Mehrheit der Computerbenutzer benutzt den Computer nur sehr
> ineffizient und viele Dinge die theoretisch der Computer für sie
> erledigen könnte tun sie lieber von Hand weil sie nicht nicht wissen wie
> sie dem Computer überhaupt mitteilen könnten was sie erledigt haben
> wollen.
>
> Das liegt daran daß ihr Dialog mit der Maschine, bzw die Sprache in der
> er geführt wird, nur aus Zeigen und Klicken besteht.

Das ist die eine Seite der Medaille. Die andere Seite der Medaille ist, 
daß viele eine irrationale Angst davor haben, sich effizientere 
Mechanismen zur Mensch-Maschine-Kommunikation anzueignen. Das liegt 
nicht zuletzt an Leuten, die ihnen erzählen, wie kompliziert das sei, 
sowie auch an Werkzeugen, die unnötig unkomfortabel und unnötig 
kompliziert sind.

Beide Sorten müssen die eigene Faulheit, Dummheit oder Angst vor sich 
selbst zu rechtfertigen -- spätestens dann, wenn ihnen jemandem 
begegnet, der diese effizienteren Mechanismen beherrscht und benutzt. 
Das führt dann zu solchen aggressiven Pöbeleien, wie sie unser kleiner 
Troll hier aufführt -- aber am Ende dokumentiert (und kompensiert) er 
mit seinem Verhalten lediglich seine eigenen charakterlichen, 
technischen und kommunikativen Defizite. :-)

[Sheeva P. (sheevaplug)]

Linuxnutzer, der auch vi, sed, awk nutzt schrieb:
> Korrigiere bitte mal dein verzerrtes Weltbild. Heutzutage sind die von
> dir genannten interaktiven Anwendungen der Haupteinsatzbereich und nicht
> nur "zusätzlich".

Hm... regelmäßig sind diese interaktiven Anwendungen lediglich ein 
Frontend für Anwendungen, die im Hintergrund ablaufen. Beispielsweise 
ein Webbrowser greift auf einen Webserver zu, ein Mailprogramm auf einen 
Mailserver, ein Layout-CAD-Programm auf eine Bauteiledatenbank, ein 
Dateimanager auf einen Dateiserver und ein Geldautomat ... you get the 
idea: viele, und vielleicht sogar die meisten interaktiven Anwendungen 
nutzen im Hintergrund eine nicht-interaktive Anwendung.

Wo ist die Grenze, und was ist da der "Haupteinsatzbereich"?

[Yalu X. (yalu) (Moderator)]

Linuxnutzer, der auch vi, sed, awk nutzt schrieb:
> Korrigiere bitte mal dein verzerrtes Weltbild. Heutzutage sind die von
> dir genannten interaktiven Anwendungen der Haupteinsatzbereich und nicht
> nur "zusätzlich".

Klar sind die interaktiven Anwendungen "zusätzlich", denn sonst wären
sie ja nicht nur der "Haupteinsatzbereich", sondern der "alleinige,
ausschließliche Einsatzbereich". Und das ist definitiv nicht der Fall,
auch wenn ein W.S. und noch ein paar andere gebetsmühlenartig versuchen,
diesen Irrglauben unters Volk zu bringen.

[Linuxnutzer, der auch vi, sed, awk nutzt (Gast)]

Trollversuch oder meine Aussage wirklich nicht verstanden?
Nach meinen bisherigen Erfahrungen mit den Moderatoren dieses Forums 
tippe ich auf ersteres.

> Beispielsweise
> ein Webbrowser greift auf einen Webserver zu, ein Mailprogramm auf einen
> Mailserver, ein Layout-CAD-Programm auf eine Bauteiledatenbank, ein
> Dateimanager auf einen Dateiserver und ein Geldautomat ...

dto.

Wieviele Webserver laufen auf dieser Welt und wieviele Webbrowser sind 
in Betrieb und was merkt der Endanwender des Webbrowsers von der 
Benutzerschnittstelle des Webbrowsers für den Administrator? Also 
wieviel Endanwender gibt es für die Webbrowser und wieviel 
Administratoren für die Server? Wobei heutzutage ja auch immer mehr 
Server mit GUI konfiguriert werden. Nur mal als Gedankenanstoß.

[Yalu X. (yalu) (Moderator)]

Linuxnutzer, der auch vi, sed, awk nutzt schrieb:
> Trollversuch

Keineswegs.

> oder meine Aussage wirklich nicht verstanden?

Möglicherweise.

> Nach meinen bisherigen Erfahrungen mit den Moderatoren dieses Forums
> tippe ich auf ersteres.

Diese Bemerkung hättest du dir sparen können :-/

Es könnte aber auch sein, dass du es bist, der meinen Beitrag nicht
verstanden hat (Trollerei möchte ich dir jetzt einmal nicht
unterstellen).

Vielleicht noch einmal zur Klarstellung: Mit dem "zusätzlich" wollte ich
nicht ausdrücken, dass die interaktiven Anwendungen in der Minderheit
sind.

Oder formal ausgedrückt ;-)

  A = K;    // die klassischen Anwendungen
  A += I;   // hinzu kommen die Interaktiven Anwendungen

impliziert für mich nicht I < K.


Dewegen verstehe ich nicht, warum ich mein Weltbild verzerrt sein sollte
und warum ich es korrigieren sollte.

Du sagst: I > K, und dem stimme ich, zumindest wenn man die Zahlen über
alle Computeranwender mittelt, zu.

W.S. sagt (wenn ich ihn richtig verstanden habe): K = 0 oder zumindest
K <<< I, und dem stimme ich eben icht zu.

[Konrad S. (maybee)]

Linuxnutzer, der auch vi, sed, awk nutzt schrieb:
> Wieviele Webserver laufen auf dieser Welt und wieviele Webbrowser sind
> in Betrieb

Na, dann benutz deinen Webbrowser doch ohne einen Webserver. Hat doch 
keiner was dagegen. ;-)