hi @Rolf B
von Perl und seinen spezifischen Problemen habe ich ja keine Ahnung. Aber bei dem, was hier diskutiert wird, habe ich doch die Stirn, sie zu runzeln.[^1]
Windows hat ein Problem mit Textdateien und open(). Die Lösung ist ein sysopen() call mit dem Flag O_BINARY was IO::File importiert.
Windows? Oder Perl für Windows?
Es ist ein Windows Problem. Und es wurde hier vor ungefähr 10 Jahren mal durchgenommen.
Wie mir ein Mönch verriet, wird Perl-intern das Zeilenende durch \n repräsentiert, und der :crlf Layer übersetzt unter Windows deshalb jedes \n beim Schreiben in \r\n. Aber wenn man dann einen String hat, der nicht den Perl-Konventionen entspricht (wie es bei beat der Fall ist, seine Zeilen sind \r\n terminiert), dann gibt's \r\r\n Gemüse. Weil der :crlf Layer von korrekten Perl-Zeilenumbrüchen ausgeht.
Nun, das mag sein. Aber es löst das Problem nicht, weil mit open() das Kind bereits in den Brunnen gefallen ist. So lautet die Löung eben sysopen() mit dem Flag O_BINARY.
Der Fehler wäre daher in $cgi->param oder im Umgang damit zu suchen.
Nein. Mit CGI:: param() hat das Ganze nun wirklich gar nichts zu tun.
Eine Zeile wird in Perl durch \n terminiert,
Auch falsch. Es gibt eine Voreinstellung für chomp() und die ist mit $/ = "\n"
als Default festgelegt (INPUT_RECORD_SEPARATOR).
Mit Perl kann man seinen Code vorzüglich plattformunabhängig machen: Indem man IO::File
nutzt womit die benötigten Flags gleich als Konstanten importiert werden.
Man muss sie nur nutzen,
O_BINARY vergessen:
my $fh = IO::File->new;
$fh->open("d:/tmp/f.txt", O_RDWR|O_TRUNC|O_CREAT) or die $!;;
$fh->print("\n");
print $fh->tell(); # 2
$fh->close;
Aus jedem "\n" entsteht "\r\n"
MfG