[linux-l] Re: [linux-l] GUIs und anderes Getier (was: Kommando für das Programm "Nach Dateien suchen" gesucht)

[Norman Steinbach]

Hi Steffen,

Steffen Dettmer wrote:
>> Linux auf einem Blatt
>> www.helmbold.de/linux
> wollte nur mal bemerken, dass da *überhaupt nichts* über Linux steht. 

Außer in der URL ;-)

> Also, bei mir ist es sowohl im Mailprogramm (mutt) als auch im Editor
> (vim) farbig, aber eine (1) Leerzeile zwischen Zitat und Text finde ich
> auch besser. Warum man zwei oder drei Leerzeilen brauchen sollte, ist
> [...]
> BTW, die Quote-Zeichen sind auch nicht ">>" sondern "> > ", weil ein
> einzelnes Quote-Zeichen "> ", also mit Leerzeichen ist.

Ich bin das Quoting aus FIDO-Zeiten noch etwas anders gewöhnt, und 
(merke gerade, muss mich wirklich jedes mal dazu extra in den hintern 
treten, ne Zeile *über* meinem geschriebenen Text einzufügen) habe mich 
gerade daran gewöhnen können, dass die Initialen am Anfang der Zeilen 
weggefallen sind und durch die Anzahl an ">"-Zeichen ersetzt wurden. 
Wenn dann hinter jedem ">" auch immernoch ein Leerzeichen steht, sind 
die Zeilenumbrüche bei längeren, gequoteten Abschnitten wiederum sowas 
von zerrissen und unlesbar, dass ich persönlich das Quotig manchmal 
sogar per Hand berichtige, weil mein Maileditor das leider nicht kann...
Auch denke ich seit FIDO-Net-Zeiten über den "idealen" 
Quoting-Algorithmus nach (initiiert ebenfalls durch die Automatismen 
beim Quoting manuell bereinigen), der auch Zeilenumbrüche und alles 
korrekt umsetzt...

>> Zudem erkennt man dann auch, welcher Text zu welchem Zitat gehört,
>> wenn diese jeweils an einem Block zusammenhängen.
> Das erkennt man ja aber auch mit Leerzeile, weil der Text ja unter dem
> Bezug steht :-)

Ja, aber rein vom optischen steht er genausoweit über dem folgenden Text 
wie unter dem Vorhergehenden. Das ist IMHO suboptimal. Daher würde ich 
am liebsten vor dem nächsten Textblock noch eine weitere Leerzeile 
einfügen, damit das Verhältnis wieder stimmt :-)


> Das Tolle ist doch, dass einfache, universelle Bausteine wie find und
> grep so schön kombinierbar sind. Hat man nur je zehn find und grep
> Optionen, könnte man bei einfacher Kombination schon 100 Kombinationen
> haben.  [...]

Ja das ist praktisch, aber wie kann man eine übersichtliche 
Dokumentation aller Befehle, Optionen und Kombinationsmöglichkeiten 
aufbauen, evtl. nach häufigkeit/"priorität" geordnet?


> Das einem diese Zusammenhänge nicht so klar sind, ist IMHO Schuld von
> GUIs, wie diesem gnome-search-tool. Dieses Tool ist der Meinung, dass

Da stimme ich Dir zu.

> nicht immer. Und ist schlecht automatisierbar. Wenn Du nun die mit
> gnome-search-tool gewonnene Dateiliste ausdrucken willst?

Ich persönlich benutze eigentlich überhaupt kein gnome-search-tool...


> Aber man kann beschreiben, wie man grosse und/oder alte Dateien findet
> und wie man für eine Liste von Dateinamen ein Kommando ausführt und wie
> man Datei(en) in ein "old" Verzeichnis verschiebt.

Ja, dementsprechend bei jedem Befehl eine Liste aller möglichen Optionen 
und was diese machen, sowie sämtlicher möglichen Parameter und was diese 
an Möglichkeiten enthalten können (das wird oft vergessen!). Mein 
persönlicher Favorit beim "Lack of Documentation" ist ja der 
Mount-Befehl (evtl. auch nur aufgrund der Tatsache, dass ich mich noch 
nie mit find etc. auseinandergesetzt habe): Woher weiß ich dort z.B. wie 
der entsprechende Parameter für ein 
3,5"-Disketten-Dateisystem(/USB-Flashdrive-Filesystem/CF/SD/whatever-card-FS/Spezielle 
CD/DVD-Formate usw.) auszusehen hat? Leider steht sowas nicht genau in 
der "etc/fstab" drin, und ich kann einerseits von Glück reden dass es 
das "Automounting" under X gibt, es andererseits aber auch verfluchen, 
da ich so nicht lerne, was da stehen muss (und was die optionen user, 
noauto, unhide und was da sonst noch so stehen kann bedeuten).
In man fstab steht es zwar ungefähr drin, aber ich weiß nicht, warum mir 
diese seiten zu lesen so "quälend" vorkommt...evtl. wegen der dort 
angewandten logik, die sich von meiner denklogik unterscheidet? evtl. 
auch weil ich kein native english speaker bin... auch ist mir die 
bedienung der man-pages zwar rudimentär klar (ich weiß, dass die unter h 
ganz gut erklärt wird, ist mir aber alles zu viel zum lernen, muss mir 
erstmal raussuchen was ich davon nutzen will/benötige), aber so richtig 
fit bin ich darin noch nicht...


>> Wenn ich nun etwas über die einzelnen Teilbefehle eher grundlegendes
> Das sind keine "Teilbefehle". Es sind Befehle. Eigentlich ist auch nur
> find der Befehl. Im Gegensatz zu vielen GUI-Suchen durchsucht das
> natürlich nicht den Inhalt, weil das Blöd ist und nicht passt. Das
> machen die GUIs ja auch nur, weil man kein "-exec grep" reinschreiben

ich glaube, hier unterscheidet sich einfach unser beider' definition von 
"befehl". für mich ist ein Befehl das, was ich in der Kommandozeile 
eingebe und mit enter dessen ausführung anstoße, und der etwas ganz 
spezielles macht. wenn dieser befehl aus den befehlen "find" und "grep" 
oder anderen zusammengesetzt ist, spreche ich hier von "teilbefehlen", 
da diese eigentlichen befehle eben nur in einer bestimmten art und weise 
miteinander verknüpft werden - in dem letztlich eingegebenen 
kommandozeilenbefehl.

> Na ja, das ist sicherlich alles richtig, normal und gängig, klar, aber
> es gibt ja extrem viele Anwendungsbeispiele. Ein paar einfache sind
> vielleicht häufig zu finden, aber es gibt auch sehr viele, die jeder nur
> einemal im Jahr oder weniger oft benutzt :-) Da kann man kaum einen
> Index machen, weil jeder ein bisschen was anderes macht. Das System
> passt sich an den Benutzer an (im Gegensatz zu GUIs, wo sich der
> Benutzer ans System anpassen muss, obwohl die GUIs genau das Gegenteil
> behaupten :-)).

ich sehe in beiden bedienungsmethoden eine starke erfordernis des 
Benutzers, sich an das System anzupassen - bei Kommandozeilen könnte man 
evtl. noch sagen, der Benutzer passt das System auf sich an (z.B. indem 
er aliasse für häufig benutzte befehle anlegt), aber: auch da muss er es 
selber tun.
Und das ist der große Widerspruch, den GUI-Bedienung und deren 
Optimierung in den letzten Jahrzehnten in die IT-Welt eingebracht hat: 
GUIs gaukeln dem Benutzer vor, er müsse bei der Bedienung des Rechners 
nicht mehr (mit-)denken; moderne GUIs verhindern sogar das Mitdenken idR 
durch Verschleiern der meisten Abläufe. Stattdessen muss man sich "nur" 
noch mit der grafischen Umsetzung der PC-Umgebung auseinandersetzen, was 
aber häufig ebenfalls bereits als nicht-trivial angesehen wird.


>> Geplante Aktion:
>> Bestimmte Verzeichnisse löschen
> [...]
> Also schon erstaunlich: so ein super-spezielles Beispiel, aber dennoch
> mindestens drei Fehler bzw. Annahmen drin... :-)

Ich habe das Beispiel völlig willkürlich ausgewählt, ohne auf dessen 
praktischen Nutzwert zu achten, einzig anhand der darin vorkommenden Art 
von Verknüpfungen einzelner Befehle, die ich teilweise einordnen konnte 
und teilweise nicht.

> Na ja, dass wird ja dann auch nur ein 10000000 Seiten Buch, wo tausend
> Mal drin steht, was eine Pipe kann, oder?

Genau dafür gibts dann doch so nette spielerreien die sich "hypertext" 
nennen, also "hyperlinks". papier ist dafür als Medium allerdings in der 
Tat ungeeignet, höchstens evtl. noch über die Druckempfindlichkeit 
bedienbares ePaper.

> mmm... Es ist nicht klar, dass das Wort "xargs" ein Programmname ist,
> wie find und rm auch?

Stimmt, ich hätte es anhand des nicht-vorhandenen Bindestrichs bzw. 
sonstigen Operanden (das Leerzeichen ist kein Operand ;-)) erkennen 
können als solchen. Müsste also in der tat mal "man xargs" eingeben, 
oder xargs --help oder sowas...

>> Ja, sowas ist komplex zu bewerkstelligen und geht wahrscheinlich nur
>> in HTML. 
> Links zu den Kommandos und vielleicht auch kontextabhängige
> Schalter/Optionssuche klingt für mich jedenfalls nicht schlecht. Sowas
> wäre wohl auch nicht sooo komplex, müsste man sogar automatisch ziemlich
> gut hinkriegen. Vielleicht gibts sowas ja auch? Vielleicht aber auch
> nicht, weil die, die es realisieren könnten vielleicht ähnlich mir der
> Meinung sind, dass sich das für die wenigen Beispiele, wo es viel Sinn
> macht, kaum lohnt.

Das wäre schade, denn im Grunde wäre ein solches Dokument für Anfänger 
(erst recht wenn sie reine GUI-Umsteiger sind - ich bin da in sofern im 
Vorteil, als dass ich unter DOS schonmal mit sowas ähnlichem wie ner 
Kommandozeile gearbeitet habe) genau das richtige, um einen apropriaten 
(?war das jetzt denglisch?) Umgang mit der Kommandozeile zu lernen...

>> Aber ein solches Dokument würde das Lernen der
>> Linux-Bedienung/-Einrichtung meiner Meinung nach ungemein
>> vereinfachen...
> Ich weiss nicht; es gibt vielleicht 50 Standardkommandos, vielleicht nur
> 25, die man kennen muss - finde, das ist so viel nicht. So ein Dokument
> würde ja nur in den ersten Tagen helfen - danach muss man dann doch
> wieder googlen, weil in den einfachen Erklärungen der Find-Parameter
> "-regex" dann doch wieder nicht vollständig erklärt ist :)

Also sollte man die am häufigsten benötigten Möglichkeiten auf der 
ersten Seite auflisten, und auf weiteren Unterseiten die als weniger 
wichtig eingeordneten...

>>> Merke: 
>>> googeln hilft meist weiter!
>> Ja, wenn man die richtigen Suchbegriffe zu wissen im Stande ist...
> Na ja, und dann aus den Millionen Treffern (Heuhaufen) die wenigen
> brauchbaren (Nadeln) findet... Man muss ja manuell die Suchergebnissen
> durchsuchen...

Ja, das ist ein weiterer Faktor.

 >> Ja, die Seite kenne ich auch. Aber für ein Nachschlagewerk, also ein
 >> Hilfedokument wo ich reinschaue, wenn ich eine konkrete
 >> Problemstellung habe und wissen will, wie ich diese unter linux
 >> lösen soll, ist es IMHO ebenfalls ungeeignet, da es auch an den
 >> absoluten Basics anfängt.
 > Na gut, ein Werk auf /genau Deinem Niveau/, also nicht zu leicht und
 > nicht zu schwer, wird es vermutlich kaum geben. Und wenn, dann hat es
 > "morgen" für Dich "die absoluten Basics" :-)

Da ist evtl. zwar was dran, aber das ist mir bei selfhtml nicht so 
gegangen. dennoch empfinde ich es als unnötig, beim Kernel kompilieren 
anzufangen, wenn ich möglichst schnell die Bedienung z.B. der Bash 
lernen möchte, um möglichst schnell auch produktiv damit arbeiten zu 
können. (wobei das bei mir komplett in der GUI läuft - naja, je nachdem 
was man als produktive arbeit betrachtet...)

 >> Ich persönlich bevorzuge eher den Weg, mir die Basics über die
 >> Anwendung der Software anzueignen
 > ... was leider der Weg ist, falsch zu lernen. Vermutlich kam es über
 > solche Wege, dass heute Leute annehmen, ein angesteckter USB-Stick
 > müsse automatisch gemountet werden, eine Sekretärin müsse Drucker
 > installieren können, Filesysteme nach Dateien und Dateien nach
 > Inhalten durchsuchen wäre das gleiche usw :)

Hmm, also ich habe meiner Meinung nach immer so gelernt, schon damals am 
386er anfang der 90er. Allerdings war die Materie da auch noch nicht so 
komplex...Soundkarten fingen z.B. gerade erst an, als Zubehör verkauft 
zu werden, heute sind sie standardmäßig eingebaut etc.
Aber davon abgesehen: Ich kann keine der Annahmen nachvollziehen, außer 
das mit dem USB-Stick, denn das ist einfach *praktisch*. Wenn er nicht 
automatisch gemountet werden würde, müsste er zumindest automatisch als 
angeschlossenes Gerät erkannt werden und die frage kommen, mit welchem 
protokoll/treiber (z.B. generic USBdrive oder ähnliches) das Gerät 
angesprochen werden soll - bei Laufwerken sollte dann auch zumindest 
ebensoeinfach eine möglichkeit zu mounten bestehen wie z.B. bei 
CD-Laufwerken, deren FS-Type usw. schon in der fstab stehen - d.h. durch 
einen einfachen befehl wie "mount /dev/sda0 
/home/Username/MountVerzeichnis" ohne noch großartig Parameter und 
Optionen raussuchen zu müssen...ich kann mit Mount immernoch nicht 
richtig umgehen, und kann linux daher nur benutzen, während ich für die 
automount-funktionen von kde dankbar bin! Natürlich würde ich es gerne 
lernen, aber gleichzeitig bin ich zu faul zum suchen einer anleitung - 
siehe google-foo oben usw...meist sind die anleitungen die man dort 
findet wieder nur ganz spezielle anleitungen, und keine allgemein 
gehaltenen. die aufspaltung des themas in "fstab" und "mount", was man 
eigentlich zusammen "als eins" lernen muss, erschwert es imho zusätzlich.


Viele Grüße,

Norman