[linux-l] Quoting und so

[Norman Steinbach]

Steffen Dettmer wrote:
> Mit ">>>>>" zu quoten ist für die Leute ohne bunten Editor nicht so gut,
> weil man als Mensch das schlechter sieht wenn keine Leerzeichen
> dazwischen sind. Mich persönlich stört eigentlich am Meisten, dass der

Aber es ist doch NACH der Reihe an >>>>en ein Leerzeichen, also zwischen
>>> und Text gibts eins - reicht das nicht? Klar, dass es GANZ ohne
leerzeichen scheiße aussieht - aber wofür die Platzverschwendung,
> > hinter
> jedem
> > > Quotingzeichen ein Leerzeichen zu machen - das erschwert IMHO wie
> bereits
> > > gesagt die Lesbarkeit des Textes wegen der vielen unnötigerweise
> eingefügten
> > > Zeilenumbrüche extrem!
>>> während es so wie in diesen 2 Zeilen schön und einfach erkennbar,
>>> sozusagen "perfekt" ist ;-)

Das nur mal als Beispiel...


> Ja klar, wenn automatisch umbrechen, dann natürlich mit den
> entsprechenden Quotierungszeichen. Macht mein vim richtig, aber Outlook
> macht es z.B. wohl falsch - bekomme oft kaputte Outlook-Mails. Das ist
> natürlich unabhängig, ob man "> " oder ">" verwendet. Beim vim ist das
Theoretisch gibt es dann also als Unterfall von ">" noch zwei weitere
Fälle, nämlich einmal ">>>Text", und einmal ">>> Text". Dass ersteres
ebensolcher Bullshit ist wie "> > > > Text", ist klar.

> Die neue Zeile hat doch genau die übernommenen "> " Zeichen, da muss
> doch nix geändert werden?
Außer, sie ist durch den Zeilenumbruch bzw. den zuvor weggenommenen
(weil durch Quoting "verschobenen") Zeilenumbruch nun nochmal am Ende
umgebrochen.

> Kenne nix, was sowas kann. Kann mir auch nicht vorstellen, wie man das
> Unterscheiden möchte - man weiss ja nicht, ob umgebrochen wurde, weil zu
> breit oder weil der Autor das extra wollte.

Ja, dafür müsste vor dem Quoten die Mail einmal durchsucht werden und
der Algo sich dann merken, wo die Umbrüche die auch schon vorher da
waren dann sitzen.

>> 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)
> mmm... Löschen? mmm... Ich hab die gerade mit Finden/Ersetzen wieder
> "repariert" ... :)
Was bin ich so froh, dass das Mnenhy-Plugin bei SeaMonkey mir diese
"Reparatur" abnimmt: Wie man sieht, nur perfektes Quoting: Keine
unnötigen Leerzeichen zwischen den einzelnen Quote-charakters, aber
zwischen allen Quote-Chars und dem Text sitzt es ganz brav - das nenn
ich übersichtlich ;-D


>> 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.
> Versteh ich nicht. Einerseits möchtest Du eine Leerzeile mehr unter
> Deinem Text, andererseite ist schon eine Leerzeile eine Spaghettimail?
Okay:
Ich sehe keinen Sinn darin, das, worauf ich antworte, durch eine
Leerzeile von meiner Antwort darauf abzutrennen. Zumal diese dann, wenn
man bei zusätzlichen Quotings nicht andauernd Leerzeilen dazwischen
haben will
(Beispiel:
>>> Text 1
>>
>> Text 2
>
> Text 3

Antwort/Text 4 im Spaghetti-Style)
sowieso manuell wieder entfernt werden müssen.
Eine Optische Abtrennung meines geschriebenen vom darauffolgenden
Quoting macht natürlich sinn - dafür reicht aber eine einzelne
Leerzeile. Außer, man wird gezwungen, auch über das geschriebene noch
eine Leerzeile einzufügen, dann müssen es - um es optisch wieder zum
darüberstehenden Textblock zugehörig zu markieren - eben 2 Leerzeilen
sein, weil obendrüber ja schon eine unnötige herumschimmelt...
Wenn man diese Leerzeilen-Manie konsequent durchführt, hat man
Spaghetti-Mails wie im obigen Beispiel. Außer, man bereinigt die
Leerzeilen manuell.
Dann sollte IMHO sowas dabei rauskommen:
=======================================
>>> Text 1
>> Text 2
> Text 3
Aktuelle Antwort/Text 4

>> Text A
> Text B
Aktuelle Antwort/Text C

>>> usw.
>> etc.
> pp
was solls.
=======================================

>>> 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. 
> Aber so entsteht doch ein schön "flüssiger" Text, oder?
Flüssig wäre er dann, wenn mit Leerzeilen möglichst sparsam umgegangen
würde, eben z.B. keine zwischen Zitat & Antwort und eine (völlig
ausreichend bei keiner zwischen Zitat&Antwort) unter der Antwort/vorm
nächsten Zitat.

> Na ja, vermutlich auch viel Gewöhnungssache. Ich bin es so sehr gewohnt,
> dass ich alles andere erstmal unterbewusst korrigieren möchte :).
Ja, ARGH, das automatisch mechanistische Tier-Denken (auch Intellekt
genannt)...

> Na ja, in der aktuellen SelfLinux-Version scheint jedenfalls kein Index
> drin zu sein.

...was mir absolut unverständlich ist, denn schließlich wäre ein solcher
das absolute Killerfeature, was die freie Auswahl der Nutzer des
Dokuments anbelangt, welchen Teil sie davon nun lesen möchten.

> Analog dazu hätte man eine Glossary machen können und (halb) automatisch
> Worte an Textstellen auf diese verlinken können.
> Irgendwie hat das wohl nicht so geklappt; naja.

Index & Glossar, ja, das wären 2 absolut notwendige Dinge die ich an
einer Dokumentation haben wollen würde. Damit wäre wahrscheinlich auch
schon das meiste abgedeckt, was ich an "sonderwünschen" haben könnte ;-)


>> Die "Handvoll Befehle" sind ja nur der Anfang, bzw. wenn man dann vom
>> schwierigkeitsgrad her tiefer in die materie einsteigt, wirds ja
>> automatisch mehr. 
> Na ja, aber dann wird's schnell schwierig mit "Aufgabenorientiertheit"
> weiter zu kommen, glaub ich.

Wieso? Aufgabenorientiert, sortiert nach Häufigkeit der benötigten
Aufgaben - wo ist das Problem?


> oder ein Wiki? Ich glaube, da gibt es sogar einige solcher Projekte.
Ja, ein Wiki böte sich hierfür fast optimal an. Das einzige, was dann
noch fehlen würde, wäre eine entsprechende Gliederung (ich habe
zumindest noch nie bewusst ein Wiki mit Gliederung wahrgenommen) und
eine entsprechende "information review", so dass nicht jeder sonstwas da
reinschreiben kann.

> ("selbst compilen" kommt natürlich vor "Einrichten/Administrieren", weil
> es einfach ist, meist reicht ja "make", aber "Einrichten/Administrieren"
> ein Fass ohne Boden sein kann :))

Wenn ein Compile-Vorgang mit einem "make" getan ist, wie kann dann die
Einrichtung sonderlich schwerer sein? Mit "selbst compilen" meinte ich
natürlich auch das entsprechende Wissen, um auch änderungen am Code
vornehmen zu können - ansonsten wäre "Compilen" natürlich als Trivial
anzusehen. Das ist z.B. etwas, was ich von einer Lösungsorientierten
Dokumentation erwarte: Dass sie bei solchen "Anforderungsprofilen"
keinen Unterschied zwischen "Compilen" und "Coden" macht. Sprich: Wer
"Compilen" lernen will/muss, muss dafür auch "Coden" lernen/können,
ansonsten wäre es bullshit, überhaupt den make-befehl zu erläutern.
Aber manchmal kommt es mir so vor, dass Leute, die durch modular
aufgebaute Software modular zu denken gelernt haben, dann allzu modular
denken und den Blick fürs Ganze aus den Augen verlieren ;->


> Aber eigentlich ist es komisch. Es gibt viel Dokumentation zu
> Linuxgeschichten. Gerade Einsteigerdoku ist doppelt und dreifach
> vorhanden. Also, eher zehn oder hundertfach. Aber Autoren für so
> "mehrschichtige Texte" zu finden (was ja nicht nur Texte und nicht nur
> Hypertexte, sondern Texte mit Sichten sind!), ist scheinbar schwierig.

Auch hier wieder mein geliebter Hinweis auf das "SNAFU-Prinzip"...


> Denkbar wäre ja auch ein Tutorial-Lernprogramm. Da kann man dann üben,
> wie man meinetwegen Christina Aguilera Lieder findet, auch wenn man sich
> nicht sicher ist, ob sie sich mit q oder g schreibt oder so. Sieht z.B.
> aus wie ne Shell, sagt aber richtig oder falsch und kann Hinweise geben
> - oder irgendsowas.

Ja, das wäre sicherlich einerseits ganz praktisch, andererseits wage ich
aber zu bezweifeln, wie der Lerneffekt durch einmaliges Abtippen einer
Befehlszeile zustande kommen soll?


> Ja ja, genau. Die Funktionalitäten sind und sollen ja unabhängig von
> einander sein. Solche Modularität ist ein wichtiges Feature, obwohl der
> Anwender davon nichts merkt (merken sollte). Da mount gar nicht wissen

Modularität ist sicherlich genial. Das Problem ist, wenn jedes Modul
seine eigene Dokumentation hat, und der Anwender aber eigentlich im
laufenden Betrieb nichts von der Modularität merken soll. Dann ist
nämlich die Dokumentation am Anwendungsalltag vorbei dokumentiert worden ;-)
Jaja, der Blick fürs Ganze fehlt noch ganz gewaltig...

>> Naja, es fehlt die erklärung, welcher der "vfstype" nun wofür stehen
>> soll, vor allem bei Disketten (diesen alten 1,44MB-Dingern...) -
> (1.44 sind doch die *neuen* Disketten - 2.88 gabs wohl kaum wirklich,
> 1.2 oder gar 360 KB waren die *alten* :-))

Ähm, die Teile sind inzwischen auch schonwieder so alt, dass sie nicht
mehr wirklich neu sind. Natürlich sind die 180kB- bis 1,2MB-Disketten
noch ne Nummer älter, aber ich spreche aus heutiger Zeit betrachtet. Und
da gibt es eben (wenn auch keinen direkten nachfolger) inzwischen massig
Technologien und Möglichkeiten, die die gute alte 1,44MB-Diskette
abgelöst haben - allen voran der USB-Flash Memory.


> nee, usbfs ist was anderes, kein filesystem Typ.

ARGH, da fängt der Hirnkrampf schon wieder an!!! WARUM steht USBFS dann
in einer Reihe mit allen anderen FILESYSTEMEN in der Dokumentation für
Mount/fstab? Warum wird nicht extra darauf eingegangen, was man anstatt
von filesystem typen da noch angeben kann, wann es sinn macht, welchen
typ anzugeben und was wofür undsoweiter ist?
Und ich möchte hierfür eben *nicht* erst zig manpages durchsuchen.
Meistens lese ich so lange in manpages herum, dass mir, bis ich die
stelle gefunden habe, an der die von mir gesuchte information dann auch
tatsächlich gelesen werden kann, die Lust vergangen ist, mich weiter
damit zu beschäftigen. Sowas ist von der Dokumentation her kurz gesagt
dann einfach nur noch: KRAMPF!


> Nein, es heisst dass man USB Geräte wie Dateien ansprechen kann. Googel
> fand
wenn es dateien sind, was haben diese dann beim mounten von
datenträgern(Massenspeichern) zu suchen? ja, ich weiß, dass der
massenspeicher, um als datei angesprochen werden zu können, erstmal dem
system als speicheradresse bekannt gemacht werden muss - trotzdem stellt
das imho einen sonderfall von "mount" dar, der in einem gesonderten
dokument (z.b. "wenn sie speichermedien nicht als verzeichnisse im
Dateisystem einbinden wollen") behandelt gehört, da er mit dem "alltag"
(gerät anschließen/datenträger einlegen; mounten; benutzen) nix zu tun
hat. In der dokumentation darf auch gerne auf die modularität und die
funktionen der einzelnen module hingewiesen werden, aber für mich haben
die schreiber der dokumentation eindeutig aus den augen verloren, wie
jemand, der von der modularität als anwender nichts mitbekommt, mit dem
system umzugehen lernt.


> Wird beim mounten kein filesystem typ angegeben, wird geraten. Das
> klappt meist ganz gut. Es klappt nicht, wenn man exotische Sachen hat,
> aber wenn man exotische Sachen hat, weiss man das meistens auch :)

Woran erkenne ich exotische Sachen, wenn ich sie haben sollte?

>> Vielleicht ist es auch der verkehrte Aufbau der Erklärung dieser 5 
>> fstab-Felder in man mount?
> Weiss nicht was Du meinst. Ich meinte, Zielgruppe ist nicht klar (und es
> müsste ja etliche geben) und diaktisch sind die meisten man pages auch

Siehe hierzu die zuvor geschriebenen Abschnitte, wo ich mich über die
fehlende Begrenzung des modularen Denkens aufgeregt habe ;-)

>> Ja, so ein Tutorial müsste anhand der Häufigkeit von bestimmten in einem 
>> Linux-Anfängerforum aufgebaut werden ;-)
Huch, hier ist mir ein Teil des Satzes beim Schreiben durch die
(frontalen Schädel)Lappen gegangen. Sollte heißen: anhand der Häufigkeit
von bestimmten in Linux-Anfängerforen *gestellten Fragen* aufgebaut werden.

> Na ja, aber ob Linux-Anfänger nun die idealen Autoren sind? Na ja, alles
> schwierig. Jedenfalls gibt es mehr Linux-Anfänger als gute Tutorials
Die Anfänger sind keine guten Autoren - aber sie sind gute Taktgeber
dafür, was in einer Guten Dokumentation als erstes abgehandelt werden
sollte. Siehe Korrektur meines letzten Satzes.

>> 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.
> mmm... Ich fand es sehr nervig, in MSDOS genug "unteren Speicher"
> freizukriegen und so. Klar, wochenlanges Einrichten gabs kaum, weil die
> Software nicht so anpassbar war.

Also 628kB waren immer drin - mehr brauchte dann aber auch fast keine
Anwendung. Ansonsten mussten halt QEMM und ähnliche Spielereien ran ;-)


> Was nicht heisst, dass ext3 auf Flash ne gute Idee ist (wg.
> Flash-Zell-Alterung etc). Auf keinen Fall atime auf flash benutzen :)

Was ist "atime"? Die automatische Defragmentierung von ext-Filesystemen?
Dann: Aua, ja klar...

> Ja, genau. Kann aber auch sein, dass er bei anderem Filesystem nicht
> startet oder sich automatisch selbst formatiert, wer weiss; oft sind
> solche Dinger halt für Windows gemacht und genau nur das geht ein
> bisschen lol

Ja, es ist geradezu brechreizfördernd, wenn man sieht, wie viel Macht
"da wo's Kapital sitzt" auf unsere Alltagswelt hat.


>> Ich dachte, "Secure" sei in dem Falle eher auf die Datensicherheit,
>> also die "Haltbarkeit" des Mediums (Flash-Speicherchips) bezogen, alls
>> auf die Zugriffssicherheit...
> Nee, dann würde man eher "safe" als "secure" sagen. Bei SD sind
> irgendwelche TCPA Gverwandten Geschichten dabei oder sowas.

Also das einzige, was ich als "Sicherzeitsmaßnahme" diesbezüglich auf
SD-Karten gesehen habe, war ein kleiner Schalter, der einen
Schreibschutz aktivieren/deaktivieren kann. Ob das MMC-Karten und andere
auch haben, keine Ahnung. Aber mit Leseberechtigung usw. ist da wohl
wirklich essig.
Sicherlich gäbe es Anwendungsfälle für SD-Karten, die ihre Daten nur
preisgeben wenn der darauf Zugreifende sich mit einem entsprechenden
"Private Key" authentifizieren kann, und zum Beschreiben gäbe es dann
einen Public-Key, wobei noch zusätzlich sichergestellt werden müsste,
dass nur mit dem Private Key auch vorher bereits geschriebene Daten
darauf verändert werden dürfen - aber: In wie vielen Fällen machte so
etwas sinn, verglichen mit der Insgesamten Einsatzhäufigkeit solcher
Karten? Und: In welchen Digitalkameras/sonstigen mobilen Endgeräten
würden solche Karten dann heute noch funktionieren?

> Ein Beispiel ist diese Vodafone "Easybox Zuhause". Das ist ein USB UMTS
> Modul mit Massenspeicher (paar MB). Über "autoplay" wird bei Windows ein
> Treiber installiert. Steckste als bloss an, dann wird Treiber
> installiert, gibste Deine UMTS PIN ein und bist im Internet.

Ist ja ein tolles Feature, wenn das unter einem Betriebssystem
funktioniert....
Will sagen: Hallo, dies ist eine Linux-Liste? Was ist, wenn ich das Teil
an einen Linux-PC anstöpsele?
=> Sowas ist IMHO in der Praxis nur mit einem proprietären
Software-Monopol möglich. Oder meinst Du, jeder WLAN-Datenstick sollte
auch nochmal 128MB Speicher haben, damit 64MB davon mit Treibern für
Windows, 50MB mit Mac-Treibern und die verbleibenden 13,irgendwas MB mit
Linux/BSD/sonstwas-Unix-Treibern gefüllt werden können?

> (natürlich blöd, wenn jemand den Treiber gegen einen Trojaner getauscht
> hat ;) - autoplay hat auch Nachteile ;))

Hat autoplay auch Vorteile?


>> Warum ein Flash und kein EEPROM, damit es auch sicherer wäre?
> Ja OK, Flash ist vielleicht blöd, k.A.. Man muss auch gucken, was billig
> ist.  Ich glaub, Flash ist beliebt als Firmwarespeicher, weiss nicht, ob
> was hier ideal wäre.

Ich glaube, Flash ist als Firmwarespeicher vor allem deshalb so beliebt,
weil es bedeutet, dass man bei der Programmierung von Firmwares nicht so
viel in Qualität und Stabilität investieren muss, weil man ja die Fehler
nachträglich noch leicht durch Firmware-Updates ausbessern kann.
Da es die EEPROM-Technik schon länger gibt als Flash-Speicher, wäre
meine nächste Frage: Wieso sollte Flash billiger sein als EEPROM? Weil
es massenhafter produziert wird?

>> 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.
> Man kann auch einfach das Floppy ausbauen und die USB Anschlüsse
> versiegeln...
Ja, damit würde man ein völlig anderes Sicherheitsszenario realisieren
als mit einem "geschützten" USB-Massenspeicher...

> Sowas gibt's standardmässig bei USB meines Wissens nach nicht. Aber es
> /geht/. Über USB kann man ja auch Netzwerk machen etc.
Klar, ich kann auch übern RS232-Port 2 PCs miteinander verbinden und
Daten übertragen....

> Ja, schon klar. Vermutlich liest diesen langen Thread auch kein anderer
> auf der Liste, aber vielleicht antwortet ja doch jemand, wer weiss :)

Möchstes Du damit ausdrücken, dass der Thread hier eigentlich
überflüssig ist? Dann sag das doch bitte direkt! :-)

Viele Grüße,

Norman