[linux-l] Re: [linux-l] GUIs und anderes Getier (was: Kommando für das Programm "Nach Dateien suchen" gesucht)
Norman Steinbach
steinbach.norman at web.de
Fr Dez 15 00:10:43 CET 2006
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
Mehr Informationen über die Mailingliste linux-l