Quote

Ich fasse es mal zusammen:
1.) Das Argument CGI.pm entspricht meiner Annahme.
Wenn beim Mac das \n ein \015 wäre und das \r ein 012 gäbe die Kombination \r\n den unsinnigen Construct \012\015 was im Netz nun wirklich kein Linebreak ist.
HTTP-Clienten müssen \015\012 sowie \015 und \012 verarbeiten (RFC) aber niemals \012\015.

Nein, CGI.pm entspricht eben NICHT deiner Annahme. Schau doch mal was der her Lincoln D. Stein (Author von CGI.pm und dem Buch Netzwerk Programmierung) da haben möchte. Er möchte eine CRLF Variable haben. Und hier gibt es genau 3 Unterscheidungen. Einmal VMS und einmal EBCDIC und einmal den Rest.

Einfach "\r\n" kann er nicht nutzen da das "\n" ja je nach System zu etwas anderen Portiert wird, je nachdem was auf diesen System ein logisches Newline ist.

Für ein VMS ist anscheind ein "\n" bereits ein CRLF. EBCDIC hat ein anderen Charset so das er \015\012 nicht nutzen Kann. Allerdiengs zeigt ein \r richtigerweise auf das wirkliche CR und \n auch auf das richtige LN.

Und jetzt kommen alle anderen Systeme! Dadrunter fällt auch Mac und MacOSX, sowie Windows und alle Mögliche Unix, BSD Derivate ein CRLF wird auf diesen System durch "\015\012" Also in ASCII (13 10) dargestellt.

Wenn MacOS da etwas vertauscht hätte, müsste es einen Sonderfall für MacOS geben, den gibt es aber nicht!!! \015 also ASCII 13 ist also ebenfalls auf einen MacOS somit ein CR Zeichen, also das "\r" Zeichen.

Also entspricht das was in CGI.pm steht genau nicht deiner Annahme! "\r" ist ist das ASCI zeichen 13 auf Linux, und auf Mac.

Quote

2.) perldoc perlport bestätigt meine Annahme, schaut euch die Tabelle doch mal an, - oben gepostet - und erzählt mir nicht was \015 bzw. \012 bedeuten auch das steht im Posting oben.

Du meinst diese Tabelle?

Okay, dann schau dir doch mal genau an was da steht!

Als erstes hast du oben eine Definition was CR und LF ist.

CR ist Oktal \015, dann steht da der Hex Wert, Escape Zeichen, und dann die ASCII Darstellung. Und CR ist immer das ASCI Zeichen 13.

Und dadrunter siehst du jetzt ein Mapping was Perl macht wenn du ein "\n" schreibst. Ein "\n" wird unter Linux zu einem LF sprich \012 und unter Mac wird es ein CR also \015.

Das ist genau das was ich oben geschrieben habe! "\n" gibt das Logische Newline des OSes aus. Auf Mac ist dies ein CR, und CR ist dadrüber definiert und ist \015 oder ASCII 13.

Also wieder kein Beweis für deine These.

Quote

3.) recode ist seit Urzeiten das Programm auf *xen zur Konvertierung von Charsets.
Wenn man sich die Translation-Tables ansieht gibt es in Bezug auf Linebreaks keinen Unterschied zwischen *x und Mac.
man recode bzw. info recode.

Wie wärs wenn du dir einfach mal ne simple Textdatei erstellst. mit 3 oder 4 Zeilen.

Dann tippst du "recode mac textfile.txt" ein. Danach die Datei öffnen und mit Hex Editor anschauen. Da wo jetzt ein Line Ending stehen sollte ist jetzt das Zeichen "0x0D" was ASCII 13 ist also CR. ASCII 13 ist für den ganz normalen Unix Zeichensatz CR. Also zeigt sich wiedermal das Unix und Mac die gleiche Codierung für CR Nutzen und da nichts verdreht ist.

4) und 5) wolltest du ja auslassen.
Ist auch nicht gut für dein Mentor. ;)

Quote

Lassen wir 4 und 5 mal beiseite, ihr könnt mich nur überzeugen, wenn ihr es mir zeigen könnt.

Ich hab dir jetzt genug Erklärt das es nicht so ist wie du es meinst. CR ist auf Unix sowie auf einem Mac das Zeichen 0x0D bzw. ASCII 13.

Genau diese Info findest du in Büchern bei Wikipedia...

Quote

Wo ist die Text-Datei vom Mac, die am Zeilenende ein (aus Unix-Sicht) \r hat?

Mit deinem recode Tool kannst du dir so eine Datei erzeugen. Ansonsten müsstest du noch jemand finden der ein MacOS9 benutzt. Ich glaub das OS sollte wohl mitlerweile so gut wie keiner mehr nutzen? Bzw. nur wohl sehr sehr wenige...\n\n

<!--EDIT|sid burn|1181770892-->