The file on your unix box is bad.
Text files in Windows end with CRLF.
Text files in unix end with LF.
You should have:
| Windows file length | 1351 |
| Linux file length | 1335 |
| Windows var length | 1335 |
| Linux var length | 1335 |
If it's not a text file, you should be using binmode on the file handle. That'll prevent the CRLF<->LF conversion.
| [reply]
[d/l] |
You should call binmode $filhandle after open and before the first read. | [reply] |
First, listen to what ikegami and others have said.
Second, remember that if you're using anything other than FTP ascii-mode file transfer on a text file, you'll have to run something like dos2unix or unix2dos against your file to make the line endings right. That includes FTP binary mode, scp, rsync, FTPing a tar or zip file then extracting, sending and email attachment as anything but ASCII, etc. They all preserve the carriage returns. There are Dos2Unix file formater, Remove the ^M Character from a Document, Re: How the perl converts LF into CRLF, No Control M, Converting DOS perl to Unix, Removing Windows newlines, Re: ftp script problem .. bad interpreter?, bad interpreter: No such file or directory, and (OT) Fixing Line Endings among many more about how to handle line-ending problems with Perl and otherwise.
Third, and perhaps the most important Perl-related point, is that if you're doing all of this just to get the length of the file, don't. If you really need to open and read the file for some other reason, that's fine. If you just need to get the filesize on disk, use -s or stat. | [reply] |
Did data get encoded in transit? E.g., on Windows: '><&'' on Linux: '><&"'?
| [reply]
[d/l]
[select] |