This is more of an OS issue more than Perl. If you want the same routine to run on both then I'd suggest using the $^O variable and toggling behaviour on the value.
I use Samba a lot and here's what they say about the issue in one of their Faq's
CRLF-LF Conversions
We get many requests for CRLF/LF format conversion handling by samba.
The problem is that there is no clean way to determine which files
should / could be converted and which MUST not be.
Since Unix and DOS/Windows uses alike will use .txt to represent a
file containing ASCII text we can not reliably use the file extension.
The same applies to the .doc extension.
Samba operates around the premise that we should leave all files uncha
+nged.
By not implmenting CRLF/LF conversions we can not be guilty of damagin
+g
anyone's files.
When someone comes along with a sound implementation that guarrantees
+file
integrity we will jump at the opportunity to implement this feature. U
+ntil
such time there is no prospect for action on this topic.
| [reply]
[d/l] |
Working with perl on my windows machine :
$file = $ARGV[0];
chomp $file;
open ( TXT , "< $file" ) or die " Could not find file : $file\n";
open ( NEW , "> $file.ttt" );
# must use binmode on the open filehandles
binmode TXT;
binmode NEW;
while ( <TXT> ) {
print NEW $_ if s/\r\n$/\n/;
}
print "converted to file : $file.ttt\n";
| [reply] |
I'm not quite sure what behavior you're trying to get out of this. ASCII (text) files are, by their very nature, different than binary files not only in that they tend to contain only readable data, but this data is broken up into multiple lines. Each OS handles newlines differently, as I'm sure you know. Tools written for one OS should (for major compatibility reasons) adapt to that OS's mechanism for interpreting newlines (as Perl does with \n). If you are using tools under Windows that work with text files yet do not honor Windows' newline convention, I would consider that a bug with the tools.
Along the same line, if you FTP files from one OS to another, you do so using the ASCII protocol, which correctly adapts your text file's newlines to match the conventions of the other OS, so that tools on the new OS can correctly read the lines of your file. Again, if the new OS incorrectly uses conventions from your source OS instead of the newline conventions of the OS they're running on, that is anomalous behavior that should be corrected.
If you truly need Perl to treat a file as anything but a simple text file (allowing you to set your own newline conventions), you should use binmode and treat the file as a binary file:
binmode(FH);
local $/ = "\cM\cJ"; # CRLF
print FH "A line of pseudo-ASCII text$/";
while (<FH>) {
# This might actually work, given that it honors $/
}
If you do something like this, avoid \n, which literally means "newline", which will behave differently under different operating systems, counter to what you seem to want. | [reply]
[d/l]
[select] |