[linux-l] Quoting und so (was: GUIs und anderes Getier)

Fr Dez 15 22:59:17 CET 2006

Steffen Dettmer wrote:
>> 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.

nach einer Reihe von > > > > >s erfolgt eine Umbruch schneller, als nach 
einer Reihe von >>>>>>>s und einem Leerzeichen dahinter. Dadurch wird 
bei fast jedem erneuten Quoting wieder ein einzelnes Wort + 
Zeilenumbruch-Zeichen in eine neue Zeile geschrieben.
Ich stelle aber gerade fest, dass mein Mailprogramm es anscheinend auch 
gesittet kann - liegt vielleicht daran, dass ich das Mnenhy(?)-Plugin 
kürzlich installiert habe, das hat ne menge sinnvoller features drin...

> ihh, ja das ist blöd. vim kann das sogar formatieren.
> (iss automatisch auf 65er Breite formatiert:)

leider muss man für vim so viel lernen...ich lerne gerne, aber in allen 
bereichen, nicht nur in einem speziellen...

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

Nein, ich dachte eher an: Wenn am Anfang einer Zeile noch kein >-Zeichen 
steht, ein "> " voranstellen, ansonsten ein ">". Wenn durch die 
Voranstellung eines ">"- oder "> "-Zeichens das letzte Wort der Zeile 
durch den automatischen Umbruch nach n Zeichen in die nächste Zeile 
übernommen wird, automatisch dieselbe Anzahl von ">"-Zeichen+Leerzeichen 
vor diese neue Zeile setzen, den Zeilenumbruch am Ende des Wortes sowie 
sämtliche weiteren ">"- bzw. "> "-Zeichen (bis auf ein Leerzeichen) vor 
dem Text der weitergehenden, zuvor nächsten, Zeile löschen und diesen 
Vorgang wiederholen bis das ganze wieder von der 
Zeilenlänge/Quote-Zeichen-Länge passt. Dazu müsste ein solcher 
Algorithmus auch noch erkennen, wann in dem zu quotenden Text schon vor 
dem eigentlichen "Zeilenende" ein Umbruch war, und diesen behalten, 
sowie die Entsprechenden Schritte nur so lange machen, wie es sich um 
dieselbe anzahl an ">"- bzw. "> "-Zeichen handelt (Die IMHO unnötigen 
Leerzeichen vor dem letzten ">" in jeder Zeile werden natürlich 
gelöscht, wenn sie vorhanden sind)

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

Die Anzahl der Leerzeilen muss man so oder so selbst bestimmen - oder 
man lebt mit einer in die länge gezogenen spaghettimail, bei der 
zwischen jedem gequoteten Stück immer eine Leerzeile steht.

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

Okay, die Lese-Richtung könnte in der Tat ein Argument sein. Aber: Ich 
finde es vom optischen her nicht nötig und eher suboptimal, wenn der 
neue Text gleichweit von dem darüber und dem darunter abgesetzt ist. 
Eigentlich bräuchte ich eben keine leerzeile zwischen dem neuen und dem 
gequoteten Text, weil man doch ohnehin am anfang der zeile sieht, wo der 
neue Text anfängt Eine Leerzeile nach dem Ende des neuen macht sinn. 
Wenn nun auch noch eine davor gefordert wird, ist mein sinn für optische 
harmonie gestört ;-)

> man gewöhnt sich
> ja an "einen" Stil.

Das wirds sein.

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

Mal so, mal 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.

Das könnte man ja sogar im Grunde nachträglich noch einbauen, nämlich 
indem man anfängt, in dem Text Hyperlinks auf alle "Worte" zu setzen, 
die einem Anfänger nicht klar sind (Ich meine nicht nur Befehle, sondern 
auch angefangen bei "Was ist eine Variable" usw). Nur müsste dafür 
wahrscheinlich noch einiges neu geschrieben werden...

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

Die "Handvoll Befehle" sind ja nur der Anfang, bzw. wenn man dann vom 
schwierigkeitsgrad her tiefer in die materie einsteigt, wirds ja 
automatisch mehr. auch wäre es interessant, andere anwendungsgebiete 
ähnlich wie repositories an so eine dokumentation anzubinden, mit dem 
Zweck, dass eine Dokumentation für Linux und jedes darauf basierende 
Projekt entsteht, die auf dem Level "Anwenden" anfängt, Grundkenntnisse 
langsam aufbaut und dadurch dann bei Bedarf tiefer hineingeht in das 
Level "Einrichten/Administrieren" bis hin möglicherweise zum Level 
"selbst compilen".

> Obwohl das weniger mount als Kerneloptionen sind.

Naja, aber alles in allem ist die Dokumentation dafür etwas zerstückelt, 
je nachdem welchem Funktionsbereich des Systems die entsprechende 
Information zugehörig ist.

> man 8 mount; Deine Beispiele find ich da eigentlich alle schön erklärt.

Naja, es fehlt die erklärung, welcher der "vfstype" nun wofür stehen 
soll, vor allem bei Disketten (diesen alten 1,44MB-Dingern...) - 
wahrscheinlich MSDOS, aber drinstehen tuts nicht. Genauso stelle ich mir 
die Frage, wie man z.B. eine 300GB-USB-Festplatte mounten will - mit 
usbfs? Und als welches Filesystem wird sie dann von dem im USB-Gehäuse 
verbauten Controller angesprochen? Oder heißt usbfs etwa, dass es ein FS 
ist was am USB-Port hängt, und der Mount-Befehl daher automatisch 
erkennen soll, was er da mounten kann?

> 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 :)
Vielleicht ist es auch der verkehrte Aufbau der Erklärung dieser 5 
fstab-Felder in man mount?

> 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
Hmm, okay. less benutze ich auch bei überlangen kommandozeilenausgaben...

> 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

Das sieht man dann bei Windows ;-)

> (hier gibts eigentlich viel mehr zusagen, z.B. ... etc).

Genau.

>> 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 möchte genau diese Hintergründe mir selektiv aneignen, während ich 
weiterhin die GUI für Anwendungen benutze. Dafür ist sie ungemein 
praktisch. Was mich halt an ihr etwas stört, ist die Tatsache, dass sie 
den User im Unklaren darüber lässt, was das System tut. Daher eigne ich 
mir eben diese Hintergründe so nach und nach an...

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

Ja, so ein Tutorial müsste anhand der Häufigkeit von bestimmten in einem 
Linux-Anfängerforum aufgebaut werden ;-)

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

Gut, ich muss dazu sagen, ich habe nie Programmieren gelernt. Aber 
installationen, auch MS-DOS-Einrichtung mit Config.sys und Autoexec.bat 
hab ich damals als ziemlich trivial empfunden, zumindest die Standardfälle.

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

Schade. ich könnte also theoretisch meinen 1GB USB-MP3-Player mit ext3 
formatieren und unter Linux als Datenträger benutzen? (dass er dann 
keine MP3-Dateien mehr abspielen würde ist klar, das OS des Gerätes kann 
ja nur FAT oder was da drauf ist...)

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

Ich dachte, "Secure" sei in dem Falle eher auf die Datensicherheit, also 
die "Haltbarkeit" des Mediums (Flash-Speicherchips) bezogen, alls auf 
die Zugriffssicherheit...

> 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

Wie meinst du das? Was für "bestimmte Informationen"? Wie groß das 
kleine Flash? Warum ein Flash und kein EEPROM, damit es auch sicherer wäre?

> möchte ich vielleicht auch verhindern, dass ein Benutzer von diesem PC
> überhaupt Daten "runter kriegt" und vor allem nicht "rauf kriegt" (Viren
> etc).

Es gibt - lustigerweise meistens nur unter Windows lauffähige - 
Spezialhardware, die das kann. USB-Festplattengehäuse mit 
Fingerabdrucksensor, oder die erst ein bestimmtes Zertifikat von einem 
am PC angeschlossenen SmartCard-Reader benötigen usw.

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

Hmm. Das gibt mir zu denken. Ist es möglich, mit ext3-Partitionen 
formatierte Festplatten in ein USB-Gehäuse zu stecken und extern zu 
verwernden, oder die Daten davon herunterzukopieren?

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

Ja, das wäre auch völlig okay.

> 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
Ich kann Dir die Fragen leider nichtmal beantworten, da ich eben leider 
überhaupt keinen Einblick darin habe, wie diese Funktion in Wirklichkeit 
abläuft.

Viele Grüße,

Norman