---

Hallihallo,

hatte grade einen wirklich kaum zu findenden Fehler. Habe mit einem Makro ähnlich Anslist.lsp eine Textdatei rausgeschrieben und einem Kollegen per Email geschickt (einfaches Attachment via Thunderbird).
Dasselbe Makro, das auf meinem Rechner tadellos diese Datei weiterverarbeiten kann, hat beim Kollegen nicht funktioniert.
Des Rätsels Lösung:
Wo vorher am Ende jeder Zeile in schlichtes <LF> war, gabs durch das Verschicken auf einmal ein <CR><LF>  und die gesamte Datei wurde in einem Rutsch anstatt zeilenweise eingelesen

------------------
meine LISP-Makros sind auf osd.cad.de
Disclaimer
Grüße aus Wien

Walter
DC4 Technisches Büro GmbH

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mit welcher Modeling-Version habt Ihr versucht, die "transformierte" Datei einzulesen?

------------------
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Version 15, die ist ja eigentlich schon "international" 

------------------
meine LISP-Makros sind auf osd.cad.de
Disclaimer
Grüße aus Wien

Walter
DC4 Technisches Büro GmbH

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wobei das hier nichts mit Internationalisierung zu tun hat, nur mit unterschiedlichen Zeilenenden je nach Betriebssystemplattform und Editor. Ich hätte gedacht, dass das spätestens mit v15 einfach tun sollte; ich hatte ab und an selbst in der Gegend zu tun. Aber wer weiss das schon so genau, schliesslich war das in einem früheren Leben 8-)

------------------
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Also Walter,
Du hast nicht die LSP datei durch die Gegend geschickt sondern (das Äquivalent zur) Ansichtsliste. Richtig verstanden?

geschrieben wird diese Liste via

Code:

---

(format strm "~a~%" ..)

---

gelesen wird mit

Code:

---

(read-line strm nil 'eof)

---

dann duerfte in der Zeile statt '/p1' ein '/p1<cr>' gestanden habe. Damit liefert (sd-pathname-to-obj str)... verständlicherweise ein NIL.

Wenn ich solche Dinge mache, loesche ich nach dem lesen immer alle <cr>  via string-replace.  Interessant zu wissen, wie eine MAC Datei dann gelesen werden würde. 
----------
Kurz Info:
WINDOWS:  EOL= cr lf  (CarriageReturn plus LineFeed)
UNIX:  EOL=lf (LineFeed)
MAC: EOL=cr (CarriageReturn)

siehe auch wikipedia Zeilenumbruch

------------------
● Seamonkey Firefox Thunderbird ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Der Effekt von unterschiedlichen Zeilenenden ist ja durchaus verständlich, bemerkenswert fand ich eigentlich, dass eine schlicht per Attachment versandte Datei überhaupt modifiziert wird 

------------------
meine LISP-Makros sind auf osd.cad.de
Disclaimer
Grüße aus Wien

Walter
DC4 Technisches Büro GmbH

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Er muss die Datei modifizieren, da eine eMail nach Standard nur Zeiches des 7-Bit-ASCII-Zeichensatzes enthalten kann. Alle anderen Inhalte, wie z.B. Grafiken und Textanhänge müssen transcodiert werden (Stichwort MIME-Protokoll). Da hüpft dann schon mal ein <CR> rein.   
-> also Codeschnipsel lieber zippen, raren, arjeten oder sonstwas...   

entsprechende Stelle im RFC:
2.3.  Body

   The body of a message is simply lines of US-ASCII characters.  The
   only two limitations on the body are as follows:

   o  CR and LF MUST only occur together as CRLF; they MUST NOT appear
      independently in the body.
   o  Lines of characters in the body MUST be limited to 998 characters,
      and SHOULD be limited to 78 characters, excluding the CRLF.

      Note: As was stated earlier, there are other documents,
      specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
      [RFC4288], [RFC4289]), that extend (and limit) this specification
      to allow for different sorts of message bodies.  Again, these
      mechanisms are beyond the scope of this document.

So würde ich es mir jedenfalls erklären.

EDIT: Link ähnlicher Fall

------------------
Grüße aus Sachsen
pw

[Diese Nachricht wurde von Patrick Weber am 15. Sep. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Patrick Weber:
Er muss die Datei modifizieren...
entsprechende Stelle im RFC:
2.3.  Body

---

Walter aber schrieb:

Zitat:

---

per Attachment versandte Datei

---

Nu Butter bei de Fisch, Walter: Body oder Attachment? 

------------------
● Seamonkey Firefox Thunderbird ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ein aehnliches Problem hatte ich schon mal mit einer MI-Datei.
Da war auch meine Annahme, dass eine reine Text-Datei unveraendert
als Anhang ueberlebt.
Jedoch ist da ploetzlich an einer Stelle oder an zwei Stellen ein
zusaetzliches Zeichen reingekommen und damit war die Zeichnung
nicht mehr ladbar.

Mag sein, dass da auch eine Virenschutz-Programme Aenderungen
vornehmen.

Daher sende ich Anhaenge nun meistens gezippt.

Gruss

WoHo

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat aus Wikipedia:
Ein Dateianhang (engl.: attachment) ist eine Datei, welche im Body einer E-Mail verschickt wird. Dies wird durch das MIME-Protokoll ermöglicht, welches die Unterteilung des Bodys und die Kodierung der Datei regelt.

Wenn er (Thunderbird) also den Text als MIME-type text/plain codiert und in den Body integriert, was kommt beim Empfänger raus? Interessiert mich jetzt, muss ich zu Hause mal ausprobieren. 
Outlook ersetzt bei mir jedenfalls das LF nicht mit CRLF.

------------------
Grüße aus Sachsen
pw

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Es kommt nicht nur auf den Client, sondern auch auf den Server an.
Exchange ändert definitv!

Roman

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP