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

[Steffen Dettmer]

* Norman Steinbach wrote on Fri, Dec 15, 2006 at 00:10 +0100:
> Wenn dann hinter jedem ">" auch immernoch ein Leerzeichen steht, sind 
> die Zeilenumbrüche bei längeren, gequoteten Abschnitten wiederum sowas 
> von zerrissen und unlesbar,

mmm... Versteh ich jetzt nicht.

> dass ich persönlich das Quotig manchmal sogar per Hand berichtige,
> weil mein Maileditor das leider nicht kann...  

ihh, ja das ist blöd. vim kann das sogar formatieren.

(iss automatisch auf 65er Breite formatiert:)
----------------------------------------------------------------|
> > > > > dass ich persönlich das Quotig manchmal sogar per Hand
> > > > > berichtige, weil mein Maileditor das leider nicht
> > > > > kann...
> > > > dass ich persönlich das Quotig manchmal sogar per Hand
> > > > berichtige, weil mein Maileditor das leider nicht kann...
> > > dass ich persönlich das Quotig manchmal sogar per Hand
> > > berichtige, weil mein Maileditor das leider nicht kann...
> > dass ich persönlich das Quotig manchmal sogar per Hand
> > berichtige, weil mein Maileditor das leider nicht kann...
> dass ich persönlich das Quotig manchmal sogar per Hand
> berichtige, weil mein Maileditor das leider nicht kann...

oder sowas :-)

> 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...

Ist doch einfach, vor jede Zeile "> " stellen. Fall jetzt Blöcke zu
breit werden, 80 Zeichen oder mehr sind IMHO schlecht, formatiert man
auf z.B 72 (kann man wieder paarmal zitieren).

> > > 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 haut dann aber nicht hin, wenn ich was einfüge bzw. muss ich dann
eine der beiden Zeilen löschen, weil mein Text hier ja wieder dazu
gehört?

Da man ja von oben nach unten liest, ergibt sich glaube ich, dass sich
unten auf oben bezieht (und nicht umgekehrt).

Aber da ist auch viel Gewohnheit dabei. Wenn "alle" oben keine oder
unten zwei Leerzeilen, wäre mir das auch recht, klar, man gewöhnt sich
ja an "einen" Stil.

Die zusätzliche Leerzeile stört mich z.B. nicht. Hast Du die eigentlich
absichtlich nicht immer verwendet oder ist das Zufall?

> >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?

Na ja, wenn es keine Referenz (alphabetisch?) sein soll, ist das
schwierig. Prioritäten sind ja für jeden ein bisschen anders. Ich z.B.
verwende find -exec kaum, nehme eigentlich immer xargs. Ich nehme sogar
lieber find|xargs perl als -exec. Weiss nicht, wohl Gewohnheit oder
Unsicherheit oder so.

Und wenn man "ordnet", wie es ja SelfLinux versucht hat, ist es auch nur
"Willkühr". Da hatten wir damals auch Diskussionen drüber. Eigentlich
sollte SelfLinux ja eher sowas werden, wie Du Dir wünscht (falls ich
Recht verstehe): ein Tutorial (also nicht Referenz oder Buch, sondern
halt praktisch orientiert) mit Hyperlinks für sowas wie Du meintest. Für
den "Schwierigkeitsgrad" gab es eine "Runlevel Idee". Es sollten die
Infos von 1 bis 5 oder so gewichtet werden, man hätte dann je nach
Wunsch 1 und 2 (leicht) oder 3 und 4 oder vielleicht nur 5 lesen können.

Sehr schwierig und aufwändig (oder komplex wie Du es ausdrücktest) für
ein "ganzes Linuxbuch". Und ob das für ne Handvoll Befehle lohnt, weiss
ich nicht.

Na ja, bei SelfLinux hat alles nicht so geklappt. Am Ende ist's dann
wohl nur "noch eine" HOWTO-Sammlung geworden, in dem Schwerpunkte nach
Autorenvorlieben liegen und nicht nach Wichtigkeit. Das Niveau ist auch
nicht einheitlich, klar, naja und so weiter...

> >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!). 

Naja, die Möglichkeiten von find's "-exec" sind doch unbegrenzt, alles
ist möglich - was soll man da schreiben?

> 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?

In der manpage unter "FILESYSTEM SPECIFIC MOUNT OPTIONS" nachlesen?

Obwohl das weniger mount als Kerneloptionen sind.

Ganz schlimm ist das bei Java. Da werden dann alle
"subsystem.a"-Optionen an Sub-System A übergeben und man kriegt nie
raus, was eigentlich alles wie geht.

Ist zum Glück unter Linux nicht so üblich.

> Leider steht sowas nicht genau in der "etc/fstab" drin, 

na doch, in der manpage fstab steht je ein Verweis auf mount(8) und
nfs(5) usw. Gut, dem Verweis kann man nicht automatisch folgen etc. aber
immerhin. Es hilft, falls man z.B. gar nicht weiss, dass mount die fstab
auswertet oder so.

Obwohl beim Booten selbst die Doku meist aufhört. Man kann irgendwas aus
dem SuSE-Bootkram hinter "man" schreiben und kriegt immer "No manual
entry for ..." lol

> 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).  

man 8 mount; Deine Beispiele find ich da eigentlich alle schön erklärt.
Blöd ist nur, wenn man nicht weiss, dass es noexec und nosuid usw gibt
und dass man mindestens eins davon möchte, wenn User mounten dürfen.
Aber gut, wenn man sowas nicht weiss, muss man halt fragen - da kann man
ja noch viel viel mehr falsch machen...

> 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? 

ich glaub, die fstab man page ist mehr für mount-Programmierer und eher
ne Spezifikation als ein Handbuch - vielleicht daher so schwer
verdaulich. Eigentlich steht da ja nur, dass es 5 Felder hat, die in man
mount erklärt werden :)

> 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...

Na, dass ist ja bloss ein "less", was da werkelt. less kann cursor
hoch/runter, bild hoch/runter, mit "/" und "?" suchen, space scrollt ne
seite (wie ein Browser das macht). less kann noch 1000 Sachen aber das
wären dann die Dinge, die weiter hinten im Linuxtutorial stehen sollten
;)

Ich finde "info" immer wieder verwirrend, selbst für einfache Sachen -
obwohl "info info" und "h" das prima erklärt, aber benutz ich zu selten.
Eigentlich nur für "make" und da geht oft auch google :)

> >>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. 

achso, ja, für mich wären das mehrere kombinierte Befehle.

> 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.

mmm... ja, ok, stimmt, er muss das System an sich anpassen. Stimmt,
wichtiger Unterschied. Vielleicht auch gar nicht so schlecht. Würde sich
das system wirklich anpassen hätte man sicherlich viel Freunde daran,
wenn es mal falsch rät, was den Mensch will lol

> 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.

Ja, genau, es bleibt aber komplex. Ist wie beim (politischen) Wählen. Es
ist recht einfach, so einen Stimmzettel auszufüllen. Aber was kreuzt man
nu an? Oder hier: Nimmt man NetBIOS oder nicht, was ist ein
Baynes-Filter, brauch ich DNS wenn ich DHCP mache usw? 

> >>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.

Ja, war auch nicht als Kritik an Dir gemeint, sondern als Beispiel, wie
komplex es doch ist, wenn man es richtig erklären will.

Meiner Meinung nach darf man "temporär" zum Erklären vereinfachen, aber
eben nur vorrübergehend - sonst besteht ja die Gefahr, dass "Falsches"
als richtig angenommen wird (z.b. so könne man immer diese Verzeichnisse
löschen).

> >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...

achso, nee, hier erkennt man das im Westenlichen daran, dass xargs nach
"|" kommt. 

Man kann auch "find . xargs echo" schreiben, aber dann sind "xargs" und
"echo" Verzeichnisnamen (die entweder nicht existieren und es ist egal
oder in "." mit dabei sind und es ist egal). (Dieses Kommando ist
gleichwertig mit "find .")

nach "|" kommt das nächste Kommando (hier gibts eigentlich viel mehr
zusagen, z.B. dass auch erst Variablenzuweisungen kommen dürfen etc).

Da geht

  date|xargs echo

was das gleiche ist wie

  echo `date`

was man üblicherweise kurz als

  date

schreibt :-)

Geht hier natürlich auch mit cat statt "xargs echo":

  date|cat
  date|cat|cat
  date|cat|cat|xargs echo

xargs ist nur so schlau, echo ggf. mehrfach zu starten, falls
Eingabedaten zu lang für eine Kommandozeile sind. Falls man das bei
aktuellen Linuxen überhaupt noch beachten muss.

> >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...
(denglisch? weiss nicht... apropriaten --> angemessenen?)

mmm... Ich bin mir nicht sicher, ob das ein guter Weg ist. Wer nur GUIs
kennt, kennt oft die Hintergründe nicht und ist ein anderes Denken
gewohnt. Warum sollte ein GUI-User überhaupt umsteigen wollen/sollen?

> >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...

Ja, so in der Art sollte SelfLinux mal werden, glaube ich - und nach
"Was will man tun" geordnet (Aufgaben / Tutorial). Aber das funktioniert
dann nicht so einfach. Ist das .xvpics-löschen ein sinnvolles Beispiel
oder weniger wichtig? usw.

> 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...)

Kernel kompilieren... Noch besseres Beispiel ist IMHO hier die
Installation. Das ist immer anders, schnelllebig und im Handbuch
erklärt, es ist trivial (wenns geht) oder unerklärbar und fordert
Extrem-Profi-Wissen (wenn man Kernelpatchen muss und noch paar C sourcen
anpassen muss, weil Konflikte :)) würde ich persönlich in ein Tutorial
gar nicht gross reinbringen. Naja, hier streiten sich natürlich die
Geister und scheiden sich... 

> > ... 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.

Na ja, einfach war's damals auch nicht, auch mit DOS nicht - gab auch
kreplige und komplexe Software. Was so ein 386 kann, ist schon Wahnsinn,
technisch mein ich. naja.

> 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 

Na ja, das macht man *jetzt* so, weil die USB Sticks auf bestimmte Art
Windows-Optimiert sind. "Laufwerk" sagt schon alles.

Warum kann ein USB Stick nicht immer intelligente Funktionen, z.B.
Zugriffsschutz? SD Speicherkarten werden unter Win automatisch
gemountet, obwohl SD ja Secure Digital heisst. Sehr "secure": schiebste
rein und lieste aus, super.

USB Geräte könnten immer ein kleines Flash für bestimmte Informationen
haben, ohne das man den Kram immer gleich mouten möchte. Ausserdem
möchte ich vielleicht auch verhindern, dass ein Benutzer von diesem PC
überhaupt Daten "runter kriegt" und vor allem nicht "rauf kriegt" (Viren
etc).

Ein schlaues USB Gerät - also intelligente Hardware - könnte auch vom FS
abstrahieren. Das kann man dann entweder mit ext3 direkt ansprechen oder
über eine Art SMB Protokol - warum nicht, bei IDE Platten hat die
Geometrie ja auch nix mehr mit der Geometrie zu tun :-)

Ausserdem geht das gar nicht "wirklich automatisch". Bei Win kriegt man
ein Laufwerk, aber das tut gar nichts. Man muss da aktiv was mit machen.
Warum nicht einfach aktiv auf das USB-"symbol" oder weiss ich was
"ziehen", dann wird gemountet und wenn das nicht klappt, kommt ein
Fehler?

> Mount immernoch nicht richtig umgehen, und kann linux daher nur
> benutzen, während ich für die automount-funktionen von kde dankbar
> bin!

mmm... ich hab sowas meist einfach mit "mount /dev/sonstwas /mnt"
gemountet, keine speziellen Optionen, nix, und ging soweit ich mich
erinnere. KDE macht auch nicht mehr oder? Ist das gnome-automount
anders? Baut das auf diesem Kernel und hald Kram auf? Na, eigentlich
auch egal ;)

> 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.

Ich denke, man müsste man ein system zu Fuss von Hand booten. Dann
schreibt man sich die mount-Kommandos auf. Vorn lässt man das "mount"
weg und schreibts in /etc/fstab - viel mehr ist das ja nicht. Sehr
pragmatisch und geht noch ohne XML. Heute undenkbar. SCNR :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.