Hallo, es waere nett, wenn sich mal jemand die Header meiner Mails anschauen koennte, ob sie jetzt in Ordnung sind. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Die, 26 Aug 2008, Heinz W. Pahlke schrieb:
es waere nett, wenn sich mal jemand die Header meiner Mails anschauen koennte, ob sie jetzt in Ordnung sind.
Äh, wann waren die denn nicht in Ordnung? - Die Message-ID ist ungültig Du mußt entweder die /etc/hosts anpassen (ein korrekter FQDN an erster Stelle des ersten 127.0.0.1-Eintrags, so das 'hostname -f' ihn ausgibt), oder deinem postfix/sendmail sagen, es soll die ID überschreiben (und der MTA muß dazu auch korrekt konfiguriert sein), oder, am einfachsten: setze den Hostnamen in der muttrc, z.B.: set hostname='msgid.pahlke-online.de' Die subdomain 'msgid' muß nicht im DNS erscheinen, es geht nur um den Namensraum (guck mal meine IDs an ;) Wenn du die Domain nicht so in den Headern haben willst, und auch nicht in den Received-Headern, mußt du IIRC an die hosts bzw. die postfix/sendmail-Konfiguration ran. Details auf Anfrage. - Das charset ist unnötig "großzügig" (latin1 wo us-ascii gereicht hätte), das deutet auf eine möglicherweise falsche, da feste, Konfiguration des Zeichensatzes auf latin1 hin. Zeig mal die Ausgabe von: egrep 'locale|charset' ~/.muttrc wenn du in der muttrc noch relevante Konfigs per 'source' einbindest, dann greppe auch in diesen Dateien (einfach mit angeben). Achso, schreib auch, welche locale du außerhalb von mutt, d.h. im xterm verwendest (Ausgabe von 'locale'). (aber das ist Mäkelei auf hohem Niveau -- ungültige Message-IDs sind leider häufiger als gültige *seufz*) Schreibe deine Antwort bitte mit zitierten und "neuen" Umlauten im Subject, sowie zitierten und eigenen Umlauten im Body. Mutt kann das weitgehend[1], aber Kontrolle ist besser ;) HTH schonmal, -dnh PS: du kannst auch intern deine Domain verwenden, dazu muß auch nix im DNS stehen. Das einzige Problem ist die MTA-Konfiguration was "lokale" Adressen sind, wenn du an nicht-lokale Adressen in deiner Domain Mails schicken willst. (wenn du domain.tld als lokal definierst, wie verschickst du an foo@domain.tld, wenn diese Adresse nicht lokal ist?). Aber ansonsten brauchst du nur die /etc/hosts oder ggfs. den lokalen Bind anzupassen. Ich arbeite lokal seit Jahren mit '*.dhaller.de' ;) *.priv oder *.lan o.ä. TLDs sind nur notwendig, wenn man eben keine eigene Domain hat. Und AFAIK auch nicht wirklich einfacher zu konfigurieren. Und wer von der '.local' Umstellung betroffen war ... PPS: Edit in der mqueue: das Subject wurde in QP und B64 kodiert, gut fuer Testzwecke *g* [1] scheitert aber an manchen besonders übel kaputten Headern, da muß man manchmal helfen -- 119: Dateimanager cd, ls, cp, mv (Ulli Horlacher) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi David! On Wed, 27 Aug 2008, David Haller wrote:
- Das charset ist unnötig "großzügig" (latin1 wo us-ascii gereicht hätte), das deutet auf eine möglicherweise falsche, da feste, Konfiguration des Zeichensatzes auf latin1 hin.
Zeig mal die Ausgabe von:
egrep 'locale|charset' ~/.muttrc
wenn du in der muttrc noch relevante Konfigs per 'source' einbindest, dann greppe auch in diesen Dateien (einfach mit angeben).
Achso, schreib auch, welche locale du außerhalb von mutt, d.h. im xterm verwendest (Ausgabe von 'locale').
Um es nochmal zu betonen, charset sollte man nicht per Konfig festnageln, da mutt das alleine aus der locale rausliest. Nur falls das wider Erwarten nicht klappt, dann kann man das entsprechend setzen. Um Probleme mit kaputten MUAs zu vermeiden sollten auch die folgenden Sachen gesetzt werden. Ich lass das mal inklusive meiner Kommentare drin: ,---- | # This setting will assume a character encoding of "iso-8859-1" | # if no encoding is specified within the mail | #set assumed_charset="windows-1252:iso-8859-1" | set assumed_charset="windows-1252" | # Handle unknown charsets correctly: | # the first handles us-ascii like ISO-8859-1 | # and the second will try to use iso8859-1 when mutt cannot determine the | # charset itsself | # This is sometimes necessary as broken MUA claim that their mails are | # us-ascii, although it really is ISO-8859-1 | charset-hook us-ascii ISO-8859-1 | charset-hook unknown-8bit ISO-8859-1 | | # This charset defines which one to use for outgoing messages | # Mutt will use the first character set into which the text can | # be converted exactly. | set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8" | # This charset defines the format for text file attachements | set file_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8" | # Explicitly define an ISO-8859-15 Environment. This is usually not | # necessary, only on broken systems | # The //TRANSLIT will let mutt replace the typical annoying chars | # from different encoding by similar one in this encoding | # (e.g. the cp1252 apostroph by ' | #set charset=iso-8859-15//TRANSLIT `---- (das benötigt aber den assumed_charset patch) Beispiel Konfig von mir findet der OP hier: http://www.256bit.org/~chrisbra/configs/mutt/ Mit freundlichen Grüßen Christian -- hundred-and-one symptoms of being an internet addict: 246. You use up your free 100 hours in less than a week. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Wed, 27 Aug 2008, Christian Brabandt schrieb
(das benötigt aber den assumed_charset patch)
Den es aber fuer die Version 1.5.18 noch nicht gibt.
Beispiel Konfig von mir findet der OP hier: http://www.256bit.org/~chrisbra/configs/mutt/
Habe ich mir heruntergeladen und sehe sie mir nachher an. Gibt bestimmt einige Anregungen. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
David Haller wrote:
Hallo,
Am Die, 26 Aug 2008, Heinz W. Pahlke schrieb:
es waere nett, wenn sich mal jemand die Header meiner Mails anschauen koennte, ob sie jetzt in Ordnung sind.
Äh, wann waren die denn nicht in Ordnung?
- Die Message-ID ist ungültig
Du mußt entweder die /etc/hosts anpassen (ein korrekter FQDN an erster Stelle des ersten 127.0.0.1-Eintrags, so das 'hostname -f' ihn ausgibt), oder deinem postfix/sendmail sagen, es soll die ID überschreiben (und der MTA muß dazu auch korrekt konfiguriert sein),
Für die Message-ID muss der Hostname, der für die Erzeugung der Message-ID verwendet wird, kein öffentlich gültiger FQDN sein. Zumindest kann ich in RFC 2822 nichts dergleichen herauslesen. Die einzige Anforderung ist, dass die Message-ID einzigartig sein muss und dafür EMPFOHLEN wird, das in der Message-ID auf der rechten Seite der Hostname steht. Wo hast du diese Info her? Auszug aus RFC 2822: The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. There are several algorithms that can be used to accomplish this. Since the msg-id has a similar syntax to angle-addr (identical except that comments and folding white space are not allowed), a good method is to put the domain name (or a domain literal IP address) of the host on which the message identifier was created on the right hand side of the "@", and put a combination of the current absolute date and time along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number) on the left hand side. Using a date on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts use the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain.
(aber das ist Mäkelei auf hohem Niveau -- ungültige Message-IDs sind leider häufiger als gültige *seufz*)
Solange es nur das ist. Versuche mal, jemandem eine Mail zu schreiben, der alle Mails annimmt, dann die Mails wieder bounced (jedesmal von einem anderen Relayhost) und dabei noch den Inhalt mit Headern verwurstet. Und dann erklär dem User, dass es bei so einem Verhalten praktisch nicht möglich ist, die Mail über Whitelists durchzulassen. (^-°) -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy, Am Mit, 27 Aug 2008, Sandy Drobic schrieb:
David Haller wrote:
- Die Message-ID ist ungültig [..] Für die Message-ID muss der Hostname, der für die Erzeugung der Message-ID verwendet wird, kein öffentlich gültiger FQDN sein. Zumindest kann ich in RFC 2822 nichts dergleichen herauslesen. Die einzige Anforderung ist, dass die Message-ID einzigartig sein muss und dafür EMPFOHLEN wird, das in der Message-ID auf der rechten Seite der Hostname steht.
Wo hast du diese Info her?
Das habe ich auch nicht behauptet. Aber *.priv ist ungültig, da man diesen Namensraum nicht kontrolliert. Mein Vorschlag ist ja auch kein öffentlich gültiger FQDN, aber unterhalb von Heinz' Domain, d.h. er hat die Kontrolle über diesen Namensraum und
Auszug aus RFC 2822:
The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique.
somit kann Heinz diese Anforderung erfüllen. Vergleiche z.B. mit dem Vorgehen von individual.de, die geben den Usern '<eigeneID>.user.individual.de' als "Hostnamensteil" zur Generierung der Messgage-IDs frei. Das ist genau die gleiche Vorgehensweise wie die von mir vorgeschlagene, "user.individual.de" ist auch kein öffentlicher FQDN, aber ein Namensraum unter Kontrolle von individual.de. Auch die großen Mailprovider haben meist ein Schema, ähnliches das man für Msg-IDs verwenden kann. Oder man besorgt sich bei dyndns.org etc. einen Namensraum, der (auch, hauptsächlich) als Subdomain / Hostname fungiert. Man könnte dann z.B. auch nur.fuer.msgids.<NAME>.dyndns.org für die Message-IDs verwenden, Hauptsache eben "unterhalb" von "<NAME>.dyndns.org". -dnh -- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
David Haller wrote:
Hallo Sandy,
Am Mit, 27 Aug 2008, Sandy Drobic schrieb:
David Haller wrote:
- Die Message-ID ist ungültig [..] Für die Message-ID muss der Hostname, der für die Erzeugung der Message-ID verwendet wird, kein öffentlich gültiger FQDN sein. Zumindest kann ich in RFC 2822 nichts dergleichen herauslesen. Die einzige Anforderung ist, dass die Message-ID einzigartig sein muss und dafür EMPFOHLEN wird, das in der Message-ID auf der rechten Seite der Hostname steht.
Wo hast du diese Info her?
Das habe ich auch nicht behauptet. Aber *.priv ist ungültig, da man diesen Namensraum nicht kontrolliert. Mein Vorschlag ist ja auch kein
Uhm, und da bin ich wieder mit der Frage, warum *.priv in einer Message-ID ungültig ist. Anders herum argumentiert: Angenommen, ich kontrolliere den Namensraum für die Domain example.com und habe dort 100 Backend-Server, die im Cluster die Domain example.com bedienen. Dann habe ich zwar eine FQDN Domain, wenn ich jedoch die Server intern alle mx.example.com nenne und nur im DNS die Rechner über mx001..mx100 anspreche, dann habe ich trotzdem das Risiko von Kollisionen, da ich 100 Rechner habe, die für die Message-ID den Hostnamen mx.example.com verwenden. Es hat also nichts mit dem ungültigen Namen zu tun, ob es eine einzigartige Message-ID ist oder nicht. Es muss nur ein einzigartiger Name sein.
Vergleiche z.B. mit dem Vorgehen von individual.de, die geben den Usern '<eigeneID>.user.individual.de' als "Hostnamensteil" zur Generierung der Messgage-IDs frei. Das ist genau die gleiche Vorgehensweise wie die von mir vorgeschlagene, "user.individual.de" ist auch kein öffentlicher FQDN, aber ein Namensraum unter Kontrolle von individual.de.
Nur dann gültig, wenn individual.de ein FQDN ist (und das ist es) und die <eigeneID>.user einzigartig ist. Dieses Schema funktioniert in der Tat.
Auch die großen Mailprovider haben meist ein Schema, ähnliches das man für Msg-IDs verwenden kann. Oder man besorgt sich bei dyndns.org etc. einen Namensraum, der (auch, hauptsächlich) als Subdomain / Hostname fungiert. Man könnte dann z.B. auch nur.fuer.msgids.<NAME>.dyndns.org für die Message-IDs verwenden, Hauptsache eben "unterhalb" von "<NAME>.dyndns.org".
Hier jedoch hinkt der Vergleich. Die Empfehlung der Aufnahme des Hostnamens als Teil der Message-ID beruht auf der Annahme, dass der Host eine offizielle IP hat und diese unter einem öffentlichen Hostnamen eingetragen ist und deshalb einzigartig ist. Einziges echtes Kriterium für die Message-ID ist, dass sie eindeutig sein muss und der Algorithmus zur Erzeugung dies sicherstellen muss. Wegen NAT und mehrerer Rechner hinter dem Router ist dies jedoch nicht gesichert bei einer DynDNS-Domain oder auch größeren Installation hinter einer öffentlichen IP. Zusammenfassung: Egal, ob der Hostname nun ein öffentlich kontrollierter ist oder nicht, es muss sichergestellt werden, dass der Hostname einzigartig ist. "localhost.localdomain" erfüllt dies mit Sicherheit nicht, bei pahlke.pahlke-online.priv sehe ich die Gefahr einer Kollision außer in theoretischer Theorie nicht. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Mit, 27 Aug 2008, Sandy Drobic schrieb:
David Haller wrote:
Am Mit, 27 Aug 2008, Sandy Drobic schrieb:
David Haller wrote:
- Die Message-ID ist ungültig [..] Für die Message-ID muss der Hostname, der für die Erzeugung der Message-ID verwendet wird, kein öffentlich gültiger FQDN sein. Zumindest kann ich in RFC 2822 nichts dergleichen herauslesen. Die einzige Anforderung ist, dass die Message-ID einzigartig sein muss und dafür EMPFOHLEN wird, das in der Message-ID auf der rechten Seite der Hostname steht.
Wo hast du diese Info her?
Das habe ich auch nicht behauptet. Aber *.priv ist ungültig, da man diesen Namensraum nicht kontrolliert. Mein Vorschlag ist ja auch kein
Uhm, und da bin ich wieder mit der Frage, warum *.priv in einer Message-ID ungültig ist.
Ganz einfach: foo.priv "gehört" dir nicht, du hast keinerlei Kontrolle oder Handhabe, wer 'foo.priv' noch verwendet. Du kannst somit den "MUST"-Anforderungen des RfC nicht entsprechen.
Anders herum argumentiert: Angenommen, ich kontrolliere den Namensraum für die Domain example.com und habe dort 100 Backend-Server, die im Cluster die Domain example.com bedienen. Dann habe ich zwar eine FQDN Domain, wenn ich jedoch die Server intern alle mx.example.com nenne und nur im DNS die Rechner über mx001..mx100 anspreche, dann habe ich trotzdem das Risiko von Kollisionen, da ich 100 Rechner habe, die für die Message-ID den Hostnamen mx.example.com verwenden.
Aber du hast die Kontrolle über den Namensraum 'example.com' und DU kannst und mußt dafür sorgen, daß die Server gültige IDs generieren können. Wie ist egal.
Es hat also nichts mit dem ungültigen Namen zu tun, ob es eine einzigartige Message-ID ist oder nicht. Es muss nur ein einzigartiger Name sein.
Und genau das kannst du bei '*.priv' nicht garantieren.
Vergleiche z.B. mit dem Vorgehen von individual.de, die geben den Usern '<eigeneID>.user.individual.de' als "Hostnamensteil" zur Generierung der Messgage-IDs frei. Das ist genau die gleiche Vorgehensweise wie die von mir vorgeschlagene, "user.individual.de" ist auch kein öffentlicher FQDN, aber ein Namensraum unter Kontrolle von individual.de.
Nur dann gültig, wenn individual.de ein FQDN ist (und das ist es) und die <eigeneID>.user einzigartig ist. Dieses Schema funktioniert in der Tat.
Nicht, weil individual.de ein FQDN ist, sondern weil der FU-Berlin der Namensraum individual.de gehört, die Kontrolle über den Namensraum individual.de ausübt und jedem User eine eindeutige ID zuteilt, und diesem User dann jew. den Namensraum <ID>.user.individual.de um Message-IDs zu erstellen. Was der User dann "unter" <ID>.user.individual.de anstellt ist Sache des Users -- nur muß wiederum er garantieren können, daß die generierten IDs eindeutig sind. Es spricht z.B. nix dagegen, 1000 User über einen lokalen Server zu versorgen, und alle eigene IDs generieren zu lassen, z.B. durch: <left-part>@<localUID>.<ID>.user.individual.de Das demonstriert auch wieder, daß der Namensraum einer Message-ID eben genau gar nichts mit realen hostnamen oder IPs zu tun hat, und nur in so weit mit DNS zu tun hat, daß die second (third) level Domain und die TLD registriert sind -- aber auch dazu muß kein Eintrag im DNS sein, nur im Whois.
Auch die großen Mailprovider haben meist ein Schema, ähnliches das man für Msg-IDs verwenden kann. Oder man besorgt sich bei dyndns.org etc. einen Namensraum, der (auch, hauptsächlich) als Subdomain / Hostname fungiert. Man könnte dann z.B. auch nur.fuer.msgids.<NAME>.dyndns.org für die Message-IDs verwenden, Hauptsache eben "unterhalb" von "<NAME>.dyndns.org".
Hier jedoch hinkt der Vergleich. Die Empfehlung der Aufnahme des Hostnamens als Teil der Message-ID beruht auf der Annahme, dass der Host eine offizielle IP hat und diese unter einem öffentlichen Hostnamen eingetragen ist und deshalb einzigartig ist.
Nein. Du schmeißt DNS und Namensraum zusammen.
Einziges echtes Kriterium für die Message-ID ist, dass sie eindeutig sein muss und der Algorithmus zur Erzeugung dies sicherstellen muss. Wegen NAT und mehrerer Rechner hinter dem Router ist dies jedoch nicht gesichert bei einer DynDNS-Domain oder auch größeren Installation hinter einer öffentlichen IP.
Das ist kein Problem. Du registrierst bei dyndns 'example.dyndns.org'. Damit hast du die Kontrolle über diesen Namensraum, und kannst ihn für MsgIDs verwenden. Wie du das machst, ist egal -- du mußt nur dafür sorgen, daß die IDs, die du in diesem Namensraum generierst eindeutig sind. Du kannst z.B. das Schema '@<interner_hostname>.example.dyndns.org' verwenden. Das hat mit IPs, DNS und NAT überhaupt gar nichts zu tun. Es geht nur um die Kontrolle, die du über den Namensraum deiner von dir registrierten (sub-)domain hast.
Zusammenfassung: Egal, ob der Hostname nun ein öffentlich kontrollierter ist oder nicht, es muss sichergestellt werden, dass der Hostname einzigartig ist.
Und genau das meine ich. Das geht nur, wenn du die Kontrolle über den Namensraum hast.
"localhost.localdomain" erfüllt dies mit Sicherheit nicht, bei pahlke.pahlke-online.priv sehe ich die Gefahr einer Kollision außer in theoretischer Theorie nicht.
Du kannst es aber nicht _GARANTIEREN_ wie im RfC gefordert. Nimm einen weniger exotischen domain-part, dann stellt sich die Praxis auch ein (wobei .priv ist schon eher exotisch)... Ob du nun localhost.local[domain] oder foo.bar.priv verwendest ist irrelevant, du kannst die Eindeutigkeit nicht garantieren, da du den Namensraum nicht kontrollierst, ergo ist die Message-ID ungültig. Und - wenn man schon eine Domain _hat_ die man als Namensraum verwenden kann (und die sowieso in den Headern auftaucht)... Achso: guck mir mal in den Header. Die ID is speziell für dich. -dnh -- Mit wine läuft ständig irgendwas jetzt endlich, während irgendwas anderes nicht mehr läuft. In dieser Hinsicht emuliert es Windows perfekt... :-) -- ratti -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Wed, 27 Aug 2008, David Haller schrieb
Am Die, 26 Aug 2008, Heinz W. Pahlke schrieb:
es waere nett, wenn sich mal jemand die Header meiner Mails anschauen koennte, ob sie jetzt in Ordnung sind.
Äh, wann waren die denn nicht in Ordnung?
Mir faellt gerade auf, dass die Liste davon nicht betroffen war. In anderen Mails stand im Return-Path eine nicht existierende Mailadresse.
oder, am einfachsten: setze den Hostnamen in der muttrc, z.B.:
set hostname='msgid.pahlke-online.de'
Die subdomain 'msgid' muß nicht im DNS erscheinen, es geht nur um den Namensraum (guck mal meine IDs an ;)
Okay, habe ich geaendert.
- Das charset ist unnötig "großzügig" (latin1 wo us-ascii gereicht hätte), das deutet auf eine möglicherweise falsche, da feste, Konfiguration des Zeichensatzes auf latin1 hin.
Zeig mal die Ausgabe von:
egrep 'locale|charset' ~/.muttrc
Nichts gesetzt: # set charset="" # Name: charset # and week day names are expanded according to the locale specified in # the variable ``$locale''. If the first character in the string is a # rest of the string are expanded in the C locale (that is in US # ``strftime''; a leading bang disables locales # ``strftime''; a leading bang disables locales # a leading bang disables locales # function ``strftime''; a leading bang disables locales. # set locale="C" # Name: locale # The locale used by strftime(3) to format dates. Legal values are # the strings your system accepts for the locale variable LC_TIME. # set send_charset="us-ascii:iso-8859-1:utf-8" # Name: send_charset # If your ``$charset'' is not iso-8859-1 and recipients may not # being run in UTF-8 locale with a signature file in non-UTF-8 and vice versa. In /usr/local/etc/Muttrc ist uebrigens auch kein charset gesetzt.
wenn du in der muttrc noch relevante Konfigs per 'source' einbindest, dann greppe auch in diesen Dateien (einfach mit angeben).
Nur eine (leere) alias- und eine color-Datei.
Achso, schreib auch, welche locale du außerhalb von mutt, d.h. im xterm verwendest (Ausgabe von 'locale').
LANG=de_DE.UTF-8 LC_CTYPE=en_US LC_NUMERIC=de_DE LC_TIME=de_DE LC_COLLATE=POSIX LC_MONETARY=de_DE@euro LC_MESSAGES=en_US LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= Beste Gruesse, Heinz -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Heinz, Am Mit, 27 Aug 2008, Heinz W. Pahlke schrieb:
Am Wed, 27 Aug 2008, David Haller schrieb
Am Die, 26 Aug 2008, Heinz W. Pahlke schrieb:
es waere nett, wenn sich mal jemand die Header meiner Mails anschauen koennte, ob sie jetzt in Ordnung sind. [..] Zeig mal die Ausgabe von:
egrep 'locale|charset' ~/.muttrc
Nichts gesetzt:
Hm. Wie war nochmal der default? Vermutlich "latin1" ;) Vorschlag: set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8" Die werden dann in der Reihenfolge verwendet, bis einer "ausreicht". Evtl. solltest du noch "charset-hook"s ergänzen, ich verwende hier diese: charset-hook "latin1" "iso-8859-1" charset-hook "ISO-8859-1" "iso-8859-1" charset-hook "ISO-88591" "iso-8859-1" charset-hook "latin9" "iso-8859-15" charset-hook "ISO-8859-15" "iso-8859-15" charset-hook "ISO-885915" "iso-8859-15" charset-hook "X-UNKNOWN" "us-ascii" charset-hook "x-unknown" "us-ascii" "assume_charset" habe ich nicht. Ist eh nur ein Workaround für kaputte Mailer, die den Content-Type nicht oder falsch setzen. Jedenfalls: wenn dann sollte man "CP1252" (halt den Windows Zeichensatz) angeben (und nicht "latin1"), denn das ist er in 99.9% der Fälle (würde ich raten ;).
In /usr/local/etc/Muttrc ist uebrigens auch kein charset gesetzt.
/etc/Muttrc? Wird evtl. auch verwendet, wenn existent (kommt drauf an wie mutt kompiliert wurde).
wenn du in der muttrc noch relevante Konfigs per 'source' einbindest, dann greppe auch in diesen Dateien (einfach mit angeben).
Nur eine (leere) alias- und eine color-Datei.
Ah, ok ;) Ich hab einiges eben der Übersichtlichkeit halber ausgelagert und setze diverse Dinge in Abhängigkeit vom Ordner um (u.a. die locale für de/en Mailinglisten).
Achso, schreib auch, welche locale du außerhalb von mutt, d.h. im xterm verwendest (Ausgabe von 'locale').
LANG=de_DE.UTF-8
Ok, also UTF-8 mit dabei ;) -dnh -- #define QUESTION ((bb) || !(bb)); // Shakespeare -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi David! On Wed, 27 Aug 2008, David Haller wrote:
Hallo Heinz,
Am Mit, 27 Aug 2008, Heinz W. Pahlke schrieb:
Hm. Wie war nochmal der default? Vermutlich "latin1" ;) Vorschlag:
set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8"
Ähm, Dir ist schon klar, dass iso-8859-1 nie getriggered wird? Sprich, Du wirst unnötigerweise immer latin9 verwenden, auch wenn latin1 ausreichen würde. Wenn dann sollte es genau andersrum sein, also: set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8"
Die werden dann in der Reihenfolge verwendet, bis einer "ausreicht".
Eben.
Evtl. solltest du noch "charset-hook"s ergänzen, ich verwende hier diese:
charset-hook "latin1" "iso-8859-1" charset-hook "latin9" "iso-8859-15"
IIRC werden diese automatisch von iconv gehandelt. Sollten nicht notwendig sein.
charset-hook "ISO-8859-1" "iso-8859-1" charset-hook "ISO-8859-15" "iso-8859-15"
Auch diese sind unnötig. charsets sind nicht case sensitiv.
charset-hook "ISO-885915" "iso-8859-15" charset-hook "ISO-88591" "iso-8859-1" charset-hook "X-UNKNOWN" "us-ascii" charset-hook "x-unknown" "us-ascii"
Was erstellt denn solch kaputte charset Deklarationen?
"assume_charset" habe ich nicht. Ist eh nur ein Workaround für kaputte Mailer, die den Content-Type nicht oder falsch setzen. Jedenfalls: wenn dann sollte man "CP1252" (halt den Windows Zeichensatz) angeben (und nicht "latin1"), denn das ist er in 99.9% der Fälle (würde ich raten ;).
Kommt auf dein E-Mail Publikum an, würde ich sagen ;) Mit freundlichen Grüßen Christian -- hundred-and-one symptoms of being an internet addict: 248. You sign your letters with your e-mail address instead of your name. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Mit, 27 Aug 2008, Christian Brabandt schrieb:
On Wed, 27 Aug 2008, David Haller wrote:
Am Mit, 27 Aug 2008, Heinz W. Pahlke schrieb:
Hm. Wie war nochmal der default? Vermutlich "latin1" ;) Vorschlag:
set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8"
Ähm, Dir ist schon klar, dass iso-8859-1 nie getriggered wird?
Wird es nicht? Was ist, wenn ich im Editor (z.B. UTF-8) VULGAR FRACTION ONE QUARTER verwende, aber sonst latin9 verwenden will, zwecks €?
Sprich, Du wirst unnötigerweise immer latin9 verwenden, auch wenn latin1 ausreichen würde.
Äh, woran unterscheidest du die beiden? Wenn du sie unterscheiden kannst (und von anderen latin* Varianten), dann ist es auch sinnvoll, sie in der bevorzugten Reihenfolge aufzuführen.
Wenn dann sollte es genau andersrum sein, also: set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8"
Nö. Ich bevorzuge latin9.
Die werden dann in der Reihenfolge verwendet, bis einer "ausreicht".
Eben.
Gut :)
Evtl. solltest du noch "charset-hook"s ergänzen, ich verwende hier diese:
charset-hook "latin1" "iso-8859-1" charset-hook "latin9" "iso-8859-15"
IIRC werden diese automatisch von iconv gehandelt. Sollten nicht notwendig sein.
IIRC war da mal was (mit nem ältern mutt / noch ohne iconv)... Meine muttrc hat schon ein paar Jährchen auf dem Buckel ;)
charset-hook "ISO-8859-1" "iso-8859-1" charset-hook "ISO-8859-15" "iso-8859-15"
Auch diese sind unnötig. charsets sind nicht case sensitiv.
dito.
charset-hook "ISO-885915" "iso-8859-15" charset-hook "ISO-88591" "iso-8859-1" charset-hook "X-UNKNOWN" "us-ascii" charset-hook "x-unknown" "us-ascii"
Was erstellt denn solch kaputte charset Deklarationen?
Alles schon (hier in der Liste sogar, IIRC) gesehen. Und das ist noch harmlos, was das Thema "kaputte Header" angeht. BTW: die latin1-locale bei 10.2 z.B. ist z.B. 'iso-88591' (oder ohne das '-', weiß grad nicht), so weit hergeholt ist das mit-ohne '-' dazwischen nicht...
"assume_charset" habe ich nicht. Ist eh nur ein Workaround für kaputte Mailer, die den Content-Type nicht oder falsch setzen. Jedenfalls: wenn dann sollte man "CP1252" (halt den Windows Zeichensatz) angeben (und nicht "latin1"), denn das ist er in 99.9% der Fälle (würde ich raten ;).
Kommt auf dein E-Mail Publikum an, würde ich sagen ;)
Be liberal in what you accept, be strict in what you send. Kaputte Deklarationen mappe ich aber mit Absicht auf us-ascii, denn das ist das, was die relevanten RfC als default vorgeben. Dann kann ich gleich viel besser schimpfen, wenn ich nur Zeichensalat sehe ;) -dnh -- Katzen sind Hunde mit Rückgrat. -- Rene Riech -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi David! On Thu, 28 Aug 2008, David Haller wrote:
Hallo,
Am Mit, 27 Aug 2008, Christian Brabandt schrieb:
On Wed, 27 Aug 2008, David Haller wrote:
Am Mit, 27 Aug 2008, Heinz W. Pahlke schrieb:
Hm. Wie war nochmal der default? Vermutlich "latin1" ;) Vorschlag:
set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8"
Ähm, Dir ist schon klar, dass iso-8859-1 nie getriggered wird?
Wird es nicht? Was ist, wenn ich im Editor (z.B. UTF-8) VULGAR FRACTION ONE QUARTER verwende, aber sonst latin9 verwenden will, zwecks €?
Dann wird automatisch utf-8 genutzt. So wie jetzt vermutlich auch schon. ¼ und € gehen halt nicht zusammen in latin1 oder latin9. (Wie es bei den anderen aussieht, weiß ich nicht). Mit windows-1252 würde es gehen, weil das ein Superset von latin1/9 ist.
Sprich, Du wirst unnötigerweise immer latin9 verwenden, auch wenn latin1 ausreichen würde.
Äh, woran unterscheidest du die beiden? Wenn du sie unterscheiden kannst (und von anderen latin* Varianten), dann ist es auch sinnvoll, sie in der bevorzugten Reihenfolge aufzuführen.
Ich persönlich? Mir reicht die Unterscheidung mit €, obwohl ich weiß, dass noch ein paar andere Zeichen sich zwischen latin1 und latin9 unterscheiden. Die sind für mich aber nicht relevant. Meine bevorzugte Reihenfolge ist dabei: Wenn die Zeichen die ich schreibe noch in latin1 passen (also ich Umlaute verwende), dann soll halt auch latin1 als Kodierung genutzt werden, wenn ich zusätzlich noch € benutze, soll latin9 verwendet werden und wenn ich exotischere Zeichen verwende (Editor läuft in utf-8) dann nimm halt utf-8. Ganz einfach ;)
Wenn dann sollte es genau andersrum sein, also: set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8"
Nö. Ich bevorzuge latin9.
Ist ja eigentlich auch egal. Die sind ja eh fast deckungsgleich. Von mir aus könnte dort auch us-ascii:utf-8 stehen.
Be liberal in what you accept, be strict in what you send.
Kaputte Deklarationen mappe ich aber mit Absicht auf us-ascii, denn das ist das, was die relevanten RfC als default vorgeben. Dann kann ich gleich viel besser schimpfen, wenn ich nur Zeichensalat sehe ;)
Das macht mutt doch automatisch, wenn er die Deklaration nicht kennt, oder? Ich persönlich benutze assumed_charset um unbekannte charsets auf windows-1252 zu mappen, das ist in Westeuropa am gebräuchlichsten und erspart mir Streß mich aufzuregen ;) PS: Schon wieder so eine komische Message-ID Mit freundlichen Grüßen Christian -- hundred-and-one symptoms of being an internet addict: 250. You've given up the search for the "perfect woman" and instead, sit in front of the PC until you're just too tired to care. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 28. August 2008 schrieb Christian Brabandt:
Hi David! ... PS: Schon wieder so eine komische Message-ID
Womöglich ist er ein "Anderer" und kommuniziert jetzt über die erste Schicht des Zwielichts... ;-))) SCNR, Michael... ...der sich fragt, was alles zu Tage kommt, wenn er wieder häufiger die Taste "v" unter KMail nutzt ;-) -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@web.de / ________________________________/ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Wed, 27 Aug 2008, David Haller schrieb
Hm. Wie war nochmal der default? Vermutlich "latin1" ;) Vorschlag:
Default: "us-ascii:iso-8859-1:utf-8"
set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8"
Habe jetzt noch ausdruecklich ein set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8" eingetragen. Mal sehen, was mutt jetzt daraus macht. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Heinz! On Thu, 28 Aug 2008, Heinz W. Pahlke wrote:
Habe jetzt noch ausdruecklich ein
set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8"
eingetragen. Mal sehen, was mutt jetzt daraus macht.
Sieht doch gut aus¹. Mich wundert allerdings, dass du Dich in deinen Mails anscheinend auf us-ascii beschränkst. Aber mit Deiner Signatur sorgst Du dann durch das Benutzen von Umlauten für den passenden Charset von iso8859-1 Testweise könntest Du die folgende Zeile nochmal zitieren: UTF-8 macht Spaß: ☻♫≠≡∞ΩẼ⅔ذΨ (Es kann durchaus sein, dass du nur Fragezeichen siehst. Dann liegt das aber an der Schrift, die für diese Codes kein Zeichen bereitstellen) ¹) Ok, irgendwann vorher ist das € im Subject bei Dir mal kaputt gegangen... Mit freundlichen Grüßen Christian -- hundred-and-one symptoms of being an internet addict: 253. You wait for a slow loading web page before going to the toilet. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Christian, Am Thu, 28 Aug 2008, Christian Brabandt schrieb
Sieht doch gut aus¹. Mich wundert allerdings, dass du Dich in deinen Mails anscheinend auf us-ascii beschränkst. Aber mit Deiner Signatur
Stammt noch aus den Zeiten, als ich getelext habe. Und in den Anfangsjahren von Mail war die Umschreibung auch sinnvoll. Sich das jetzt abzugewoehnen, faellt schwer. Meistens kommt dann ein Mischmasch heraus, der sich noch schlechter liest.
Testweise könntest Du die folgende Zeile nochmal zitieren: UTF-8 macht Spaß: ???????????????????????????? (Es kann durchaus sein, dass du nur Fragezeichen siehst. Dann liegt das aber an der Schrift, die für diese Codes kein Zeichen bereitstellen)
Muss mal schauen, welche Schrift ich waehlen muss, damit ich auch UTF-8 lesen kann. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Heinz! On Thu, 28 Aug 2008, Heinz W. Pahlke wrote:
Testweise könntest Du die folgende Zeile nochmal zitieren: UTF-8 macht Spaß: ????????????????????????????
kaputt ;) Kann es sein, dass Dein Editor das als iso8859-1 interpretiert hat?
Muss mal schauen, welche Schrift ich waehlen muss, damit ich auch UTF-8 lesen kann.
Im x-term sollte -misc-fixed-medium-r-normal-*-15-140-75-*-c-*-iso10646-1' schon gute Ergebnisse bringen. Hängt natürlich auch davon ab, welche Schriftzeichen man benötigt. Meines Wissens gibt es keine Schrift, die alle Schriftzeichen von UTF-8 abdeckt. Unter Windows funktioniert die Courier New ganz gut und deckt auch recht viel ab (benutze ich zum Schreiben hier unter putty). Siehe auch: http://www.cl.cam.ac.uk/~mgk25/unicode.html Mit freundlichen Grüßen Christian -- Women are probably the main cause of free software starvation. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Thu, 28 Aug 2008, Christian Brabandt schrieb
On Thu, 28 Aug 2008, Heinz W. Pahlke wrote:
Testweise könntest Du die folgende Zeile nochmal zitieren: UTF-8 macht Spaß: ????????????????????????????
kaputt ;) Kann es sein, dass Dein Editor das als iso8859-1 interpretiert hat?
Moeglich. Noch ist mir naemlich nicht klar, wie man dem vim das beibringt.
Muss mal schauen, welche Schrift ich waehlen muss, damit ich auch UTF-8 lesen kann.
Im x-term sollte -misc-fixed-medium-r-normal-*-15-140-75-*-c-*-iso10646-1' schon gute
Fuer xterm habe ich das mal eingestellt. Lt. gfontsel gibt es eine entsprechende Schrift. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Heinz! On Thu, 28 Aug 2008, Heinz W. Pahlke wrote:
Hallo,
Am Thu, 28 Aug 2008, Christian Brabandt schrieb
kaputt ;) Kann es sein, dass Dein Editor das als iso8859-1 interpretiert hat?
Moeglich. Noch ist mir naemlich nicht klar, wie man dem vim das beibringt.
Irgendwo zwischen Maileingang und Mailausgang muß bei Dir die Mail auf iso-8859-1 umkodiert haben und dabei sind natürlich die Zeichen kaputt gegangen, die in iso-8859-1 nicht darstellbar waren. Wurden denn die Zeichen, als du die mail mit mutt gelesen hast korrekt angezeigt (es sollten 10 Zeichen gewesen sein). Alternativ kannst du die Mail auch einfach mal durch less pipen (das sollte dir dann auch 10 Zeichen anzeigen). was sagt denn im vim :verbose set fencs? enc? fenc? wenn du eine Mail editierst? Eigentlich macht vim das von alleine schon sehr gut. Braucht man eigentlich nicht anpassen. Das liest er dann nämlich aus der gültigen Locale raus. Wichtig ist eigentlich nur fencs. Das gibt eine Liste an Kodierungen an, die probiert werden sollen wenn eine Datei gelesen wird. Die erste die passt "gewinnt" IIRC. Ich hab das hier in meiner Konfig so festgesetzt: ,---- | " how are different fileencodings determined? | " This is a list. The first that succeeds, will be used | " default is 'ucs-bom,utf-8,default,latin1' | set fencs=ucs-bom,utf-8,default,latin9,latin1 `---- Ich fand es auch gleich ganz hilfreich, die Kodierung der Datei in der Statusbar anzuzeigen: ,---- | if has("statusline") | set statusline= | set statusline+=%-3.3n\ " buffer number | set statusline+=%f\ " file name | set statusline+=%h%m%r%w " flags | set statusline+=\[%{strlen(&ft)?&ft:'none'}, " filetype | set statusline+=%{(&fenc==\"\"?&enc:&fenc)}, " encoding | set statusline+=%{&fileformat} " file format | set statusline+=%{(&bomb?\",BOM\":\"\")}] " BOM | set statusline+=%= " right align | set statusline+=%-10.(%l,%c%V%)\ %p%% " offset | endif `---- So sehe ich immer auf einen Blick, welche Dateityp, encoding, ... der aktuelle Buffer hat. Im Compose Screen kannst Du dann nochmal das encoding kontrollieren. Dort steht dann sowas: ,---- | -- Anhänge | - I 1 /tmp/mutt9IMbqk [text/plain, 8bit, iso-8859-1, 2,2K] `---- Dann siehst Du, dass /tmp/mutt9IMbqk als text/plain mit Zeichensatz iso-8859-1 ohne Content-Encoding verschickt werden soll. Mit freundlichen Grüßen Christian -- A bug in the hand is better than one as yet undetected. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Christian, hier war noch ein uralter vim 6.x installiert. Das Update auf die Suse-7.2 brachte leider das obligate Maus-Problem, so dass ich den akutellen vim 7.2 von www.vim.org installiert habe. Mit ihm klappt alles wie ueblich problemlos. Am Thu, 28 Aug 2008, Christian Brabandt schrieb
was sagt denn im vim :verbose set fencs? enc? fenc? wenn du eine Mail editierst?
fileencodings=ucs-bom encoding=latin1 fileencoding=
Eigentlich macht vim das von alleine schon sehr gut. Braucht man eigentlich nicht anpassen. Das liest er dann nämlich aus der gültigen Locale raus. Wichtig ist eigentlich nur fencs. Das gibt eine Liste an Kodierungen an, die probiert werden sollen wenn eine Datei gelesen wird. Die erste die passt "gewinnt" IIRC. Ich hab das hier in meiner Konfig so festgesetzt:
,---- | " how are different fileencodings determined? | " This is a list. The first that succeeds, will be used | " default is 'ucs-bom,utf-8,default,latin1' | set fencs=ucs-bom,utf-8,default,latin9,latin1
In der vim-Konfig? -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Heinz! On Fri, 29 Aug 2008, Heinz W. Pahlke wrote:
was sagt denn im vim :verbose set fencs? enc? fenc? wenn du eine Mail editierst?
fileencodings=ucs-bom encoding=latin1 fileencoding=
Das sieht kaputt aus. Hast Du :verbose set fencs? enc? fenc? angegeben? Wundert mich, denn das sind nicht die Defaults und das sieht aus, als wäre es irgendwo festgenagelt. Das erklärt auch, warum alles nach latin1 umkodiert wird.
Eigentlich macht vim das von alleine schon sehr gut. Braucht man eigentlich nicht anpassen. Das liest er dann nämlich aus der gültigen Locale raus. Wichtig ist eigentlich nur fencs. Das gibt eine Liste an Kodierungen an, die probiert werden sollen wenn eine Datei gelesen wird. Die erste die passt "gewinnt" IIRC. Ich hab das hier in meiner Konfig so festgesetzt:
,---- | " how are different fileencodings determined? | " This is a list. The first that succeeds, will be used | " default is 'ucs-bom,utf-8,default,latin1' | set fencs=ucs-bom,utf-8,default,latin9,latin1
In der vim-Konfig?
Ja, ich dachte, das wäre klar. Mit freundlichen Grüßen Christian -- The greatest lies of all time: (1) The check is in the mail. (2) We have a really challenging assignment for you. (3) I love you. (4) That bug has been fixed. (5) This won't hurt a bit. (6) The Mercedes is paid for. (7) I have just sent you an e-mail about that. (8) Of course I'll respect you in the morning. (9) I'm from the government, and I'm here to help you. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Christian, Am Fri, 29 Aug 2008, Christian Brabandt schrieb
On Fri, 29 Aug 2008, Heinz W. Pahlke wrote:
was sagt denn im vim :verbose set fencs? enc? fenc? wenn du eine Mail editierst?
fileencodings=ucs-bom encoding=latin1 fileencoding=
Das sieht kaputt aus. Hast Du :verbose set fencs? enc? fenc?
Das SIND die Ausgaben der drei.
angegeben? Wundert mich, denn das sind nicht die Defaults und das sieht aus, als wäre es irgendwo festgenagelt.
encoding=latin1 ist default lt. vim-Doku. fenc ist, wenn ich die Doku richtig verstehe, per default nicht gesetzt. Nur fencs verstehe ich nicht, weil ich jetzt ucs-bom,utf-8,default,latin1 erhalte, was ich noch um latin9 vor latin1 ergaenzt habe. Ausserdem habe ich encoding auf utf-8 geaendert. Die Folge ist allerdings, dass die deutschen Umlaute in existierenden Dateien nicht mehr stimmen, wie man auch an dieser Mail sieht :-( Die Frage ist jetzt, wie sich dieses Problem loesen laesst. Da ich Tausende von Dateien in latin1 besitze, ist die jeweilige Anpassung der .vimrc keine Loesung. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Fri, 29 Aug 2008, Heinz W. Pahlke schrieb
Die Folge ist allerdings, dass die deutschen Umlaute in existierenden Dateien nicht mehr stimmen, wie man auch an dieser Mail sieht :-(
Im vim waren (und sind) statt der deutschen Umlaute nur Hieroglyphen zu sehen, aber mutt zeigt sie dann richtig an. Das ist immerhin EIN Trost. Beste Gruesse, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Heinz! On Fri, 29 Aug 2008, Heinz W. Pahlke wrote:
encoding=latin1 ist default lt. vim-Doku.
Nur wenn es nicht von Deiner Locale gesetzt werden kann. Aber Du nutzt Doch de_DE.UTF-8, oder?
fenc ist, wenn ich die Doku richtig verstehe, per default nicht gesetzt.
Jein, damit gibst Du an in welcher Kodierung Du Deine Datei speichern willst. encoding dagegen gibt an, welche Kodierung intern benutzt wird.
Nur fencs verstehe ich nicht, weil ich jetzt ucs-bom,utf-8,default,latin1 erhalte, was ich noch um latin9 vor latin1 ergaenzt habe.
Die Option enthält eine Liste an encodings, die ausprobiert werden, wenn eine Datei gelesen wird. Vim versucht anhand dieser Liste, das richtige Encoding zu erkennen.
Ausserdem habe ich encoding auf utf-8 geaendert.
Das brauchst Du eigentlich nicht setzen. Aber wenn Du Deine eine UTF-8 Locale hast, sollte es auch nicht schaden.
Die Folge ist allerdings, dass die deutschen Umlaute in existierenden Dateien nicht mehr stimmen, wie man auch an dieser Mail sieht :-(
Das heißt, Vim erkennt das Encoding schon richtig? Geh mal auf so einen kaputten Buchstaben und tippe ga? Bekommst Du dann den richtigen Hex-Wert? Versteht Dein Terminal utf-8?
Die Frage ist jetzt, wie sich dieses Problem loesen laesst. Da ich Tausende von Dateien in latin1 besitze, ist die jeweilige Anpassung der .vimrc keine Loesung.
Ich verstehe noch nicht so richtig Dein Problem. Schick mir mal privat eine kleine Testdatei. Überhaupt können wir das evtl per PM besser klären. Mit freundlichen Grüßen Christian -- Life would be so much easier if we could just look at the source code. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, mit Christians Unterstützung funktioniert jetzt alles wie gewünscht. Entscheidend war wohl, dass die LC-Variablen unterschiedlich auf de_DE.utf-8, en_GB.utf-8 und en_GB lauteten. Nachdem die en_GB auf en_GB.utf-8 erweitert waren, klappte es. In yast habe ich zu den Sprachen außerdem noch en_GB.utf-8 hinzugefügt. Die Ursache für solche Probleme sind wohl meine vielen individuellen Anpassungen außerhalb der Distri. Ich konfiguriere fast alles direkt und verwende zudem viele Programme, die nicht zur Suse gehoeren bzw. in neueren Versionen. Beste Grüße, Heinz. -- Buchsatz für Autoren. Vom Manuskript zum Buch www.pahlke-online.de Reiseführer und Reiseberichte: www.erlebnis-osteuropa.de Barrierefreies Webdesign: www.Pahlke-KunstWebDesign.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi David! On Wed, 27 Aug 2008, David Haller wrote:
- Das charset ist unnötig "großzügig" (latin1 wo us-ascii gereicht hätte), das deutet auf eine möglicherweise falsche, da feste, Konfiguration des Zeichensatzes auf latin1 hin.
Weil ich es auch gerade erst gemerkt habe. Das Charset ist schon richtig. Es liegt an der Signatur. Mit freundlichen Grüßen Christian -- hundred-and-one symptoms of being an internet addict: 254. You wake up daily with your keyboard printed on your forehead. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (5)
-
Christian Brabandt -
David Haller -
Heinz W. Pahlke -
Michael Höhne -
Sandy Drobic