Heute ist zwar kein Freitag, aber dennoch... Ich benutze Linux und (Neo)Vim als Texteditor. Und ich habe noch eine saubere Linux-Kopie zum Experementieren (mit VirtualBox) installiert. Und auf diesem System will ich natürlich weiterhin meinen Editor benutzen. Mit allen Einstellungen, die ich vorgenommen habe. Also habe ich die config-Datei per Email an mich selbst geschickt. Dann die "nackte" Linuxversion hochgefahren, dort die Email geöffnet und die config-Datei (als Email-Anhang) runtergeladen. Dann habe ich meinen Editor gestartet und bekam nur Fehlermeldungen! Die gleiche config-Datei, die unter gleichem Betriebssystem mit gleichem Texteditor bereits einwandfrei funktioniert ;-) Das "Entschlüsseln" der Fehlermeldung ergab, dass alle Zeilen mit Windows-Style (CR-LF) abgeschlossen wurden. Und tatsächlich, nachdem ich die Datei neu erzeugt und dann den Inhalt dorthin kopiert habe, funktioniert alles wieder einwandrei. Das funktioniert auch auf dem gleichen System: Einfach die config-Datei per Email an sich selbst verschicken, dort wieder runterladen und schon gibt es diese Fehlermeldungen. Mal doof gefragt: woher kommen diese Windows-Sachen her? Doch nicht von meinem Email-Anbieter oder? ;-)
:
Gesperrt durch Moderator
stranger thinks schrieb: > Das funktioniert auch auf dem gleichen System: Einfach die config-Datei > per Email an sich selbst verschicken, dort wieder runterladen und schon > gibt es diese Fehlermeldungen. Bei mir nicht. Hast du deinen E-Mail-Account vielleicht bei outlook.com? ;-)
WTF?! Ein E-Mail Anbieter darf doch nicht den Inhalt von Anhängen verändern.
Hallo, nach dem was Du schreibst kann es eigentlich nicht am vim liegen. Trotzdem der Hinweis, dass es bei vim Einstellungen wie fileformat und fileformats gibt. Die sind in Deiner sauberen Linux-Umgebung nicht aus unerklärlichen Gründen auf "dos" gesetzt, oder?
Yalu X. schrieb: > Hast du deinen E-Mail-Account vielleicht bei outlook.com? ;-) web.de und gmx.net
1 | Error detected while processing /home/me/.config/nvim/init.vim: |
2 | line 2: |
3 | E492: Not an editor command: ^M |
4 | line 3: |
5 | E492: Not an editor command: ^M |
6 | line 5: |
7 | E492: Not an editor command: ^M |
8 | line 7: |
9 | E492: Not an editor command: ^M |
10 | line 9: |
11 | E492: Not an editor command: ^M |
12 | |
13 | usw.... |
Alexander S. schrieb: > Die sind in Deiner sauberen Linux-Umgebung nicht aus > unerklärlichen Gründen auf "dos" gesetzt, oder? Nein, im Prinzip kann jetzt die richtige config-Datei (die einwandfrei funktioniert) an mich selbst verschicken, auf dem gleichen System öffnen und es wird nicht mehr funktionieren. Schon komisch. Dann kopiere ich alles manuell oder rufe den Befehl :w ++ff=unix (geklaut im Netz) im Editor auf. Und dann funktioniert wieder alles.
stranger thinks schrieb: > Yalu X. schrieb: >> Hast du deinen E-Mail-Account vielleicht bei outlook.com? ;-) > > web.de und gmx.net Vorhin habe ich es mit GMX probiert, daran liegt es also nicht. Schau dir doch mal die rohe E-Mail an, in der der Anhang Base64-kodiert enthalten ist. Wenn du diesen Base64-Abschnitt herauskopierst und ihn separat dekodierst, enthält er dann ebenfalls die CRs? Dasselbe kannst du auch mit der gesendeten E-Mail machen, die sicher noch in irgendeinem Sent-Ordner steckt.
Interessant. Forschen: Datei lokal speichern und dann im andern BS öffnen. Bleibt der Effekt? Anmerkungen: Schlechter Stil. 1. Benutzer. Eine Datei auf einem entfernten Rechner speichern, nur um die dann gleich wieder zu holen. 2. Betriebssysteme. Zeilenanfang nächste Zeile ist CR-LF (oder LF-CR, was einige windows-Editoren durcheinanderbringt). 3. Editor. Umwandlung muß natürlich in beide Richtungen gleich funktionieren. oder 4. entferntes System (sehr unwahrscheinlich): Wer mitliest, könnte auch mitschreiben ;)
Yalu X. schrieb: > Vorhin habe ich es mit GMX probiert, daran liegt es also nicht. Nach Mail veränderte Files hatten wir vor Jahren im Zusammenspiel zweier Firmen, also ohne GMX oder M$-Mail. Die Ursache haben wir nie ergründet, Datei vor dem Versand einpacken (zip, 7z, rar) und fertig. Hat noch den Nebeneffekt, dass das Änderungsdatum der Datei erhalten bleibt, was bei Laborsoftware durchaus hilfreich sein kann.
Bei vielen Internetprotokollen ist CR LF als Zeilenende spezifiziert. LG, Sebastian
Sebastian schrieb: > Bei vielen Internetprotokollen ist CR LF als Zeilenende > spezifiziert. > > LG, Sebastian Gegenfrage: Dürfen die Internetprovider angehängte Files eigenmächtig umcodieren?
Erwin D. schrieb: > Gegenfrage: > Dürfen die Internetprovider angehängte Files eigenmächtig umcodieren? War es denn ein Anhang, und nicht einfach nur Text ... LG, Sebastian
Sebastian schrieb: > War es denn ein Anhang, und nicht einfach nur Text ... Ja, steht im allerersten Beitrag: stranger thinks schrieb: > (als Email-Anhang)
Erwin D. schrieb: > Sebastian schrieb: > >> War es denn ein Anhang, und nicht einfach nur Text ... > > Ja, steht im allerersten Beitrag: > stranger thinks schrieb: > >> (als Email-Anhang) Ich würde die gesendete Email ja gern mal sehen. In voller Schönheit mit allen Headern...
Sebastian schrieb: > Erwin D. schrieb: >> Sebastian schrieb: >> >>> War es denn ein Anhang, und nicht einfach nur Text ... >> >> Ja, steht im allerersten Beitrag: >> stranger thinks schrieb: >> >>> (als Email-Anhang) > > Ich würde die gesendete Email ja gern mal sehen. In voller Schönheit mit > allen Headern... Falls es dir nicht aufgefallen ist: Ich bin nicht der TO
Erwin D. schrieb: > Gegenfrage: > Dürfen die Internetprovider angehängte Files eigenmächtig umcodieren? Gegenfrage: Wie kommst Du darauf, dass sie es tun würden? Der Knackpunkt ist, dass hier eine Textdatei per Mail versendet wurde. Die meisten Mail-Clients machen daraus automatisch (entweder wegen der Extension oder wegen des Inhalts) ein text/plain-Attachment, und lt. MIME-Standard muss dann als Zeilenende CR/LF verwendet werden. Der empfangende Mail-Client speichert es dann üblicherweise so ab, wie es unter dem verwendeten Betriebssystem üblich ist - und wenn man Webmail-Zeug verwendet, wohl in dem Format, das die meisten verwenden, nämlich CR/LF. Abhilfe: Entweder in ein Archiv einpacken oder den Mail-Client davon überzeugen, dass es sich um ein Binary handelt, das als application/octet-stream verschickt wird und empfängerseitig 1:1 so ankommt, wie es abgeschickt wurde.
Hmmm .. schrieb: > Der Knackpunkt ist, dass hier eine Textdatei per Mail versendet wurde. Das sollte dem Emailprogramm egal sein. Der sollte das behandeln wie auch jede andere Datei. Egal ob da als Endung .txt oder sonst was steht.
Gustl B. schrieb: > Das sollte dem Emailprogramm egal sein. Der sollte das behandeln wie > auch jede andere Datei. Egal ob da als Endung .txt oder sonst was steht. Das ist Deine persönliche Auffassung, der MIME-Standard sieht das anders. Zum einen geht es darum, dass der Empfänger unabhängig vom Dateinamen den Typ erfährt, also z.B. auch auf Systemen, wo Extensions unüblich sind - ich glaube, bei MacOS <10 war das so. Zum anderen will man erreichen, dass eine Textdatei unabhängig von den Systemen von Absender und Empfänger immer als solche gelesen werden kann. Hast Du mal versucht, eine Unix-Textdatei mit Notepad zu öffnen? Dasselbe findet übrigens auch bei FTP statt, wenn man im ASCII-Mode überträgt.
Hmmm .. schrieb: > Hast Du mal versucht, eine Unix-Textdatei mit Notepad zu öffnen? Der Fluch des Zeilenumbruchs. Hier liegt noch ein uralt Kommandozeilentool "Unix2Dos.exe" (2004 oder älter), was die Unix-Textdateien für Windows ergänzt. Das Problem hatte ich auch in der Firma, Textfiles vom Kollegen aus der Entwicklung hatten unter Windows keine Zeilenumbrüche. Nachdem wir das besprochen hatten, konnte er die Dateien passend erzeugen, damit waren sie sowohl auf Unix als auch Windows klaglos benutzbar.
Beitrag #6761452 wurde von einem Moderator gelöscht.
stranger thinks schrieb: > woher kommen diese Windows-Sachen her Kaputtes Linux bzw. zu wenig Erfahrung in der korrekten Nenutzung zur Umgehung der Quirks. Dein eMail-Programm konvertiert nicht richtig.
Hmmm .. schrieb: > Gustl B. schrieb: >> Das sollte dem Emailprogramm egal sein. Der sollte das behandeln wie >> auch jede andere Datei. Egal ob da als Endung .txt oder sonst was steht. > > Das ist Deine persönliche Auffassung, der MIME-Standard sieht das > anders. So ist es, da ist explizit CRLF geforder. Und eine Textnachricht ist in der Regel eben keine Anlage sondern ein Teil der Messege und somit sollte der EMail-Client auch dafür sorgen das diese richtig codiert wird beim senden. - https://datatracker.ietf.org/doc/html/rfc2045#section-2.10
Thread beobachten
Seitenaufteilung abschalten