FTP doesn't add Carriage Return from VMS to NT?

[p5pRT]

Migrated from rt.perl.org#23305 (status was 'resolved')

Searchable as RT23305$

[p5pRT]

From mjoneal@bpa.gov

:​::​::PROBLEM​::​::​:: When I tried to use NET​::FTP to transfer text files from VMS to NT (GET command using ASCII mode\,) FTP would add the Linefeed\, but not the required carriage return. Windows NT/2000 requires the CR/LF at the end of each line. VMS uses neither. When I transfer the files in binary\, NO line terminations are added\, as expected. I'm using Windows 2000 with the ActiveState Perl vers 5.8.0. I scoured the newsgroups and discovered this is a fairly common problem. I even posted a request in comp.lang.perl.misc with the same subject as the one in this email. No-one had an answer.

:​::​::SOLUTION​::​::​: I discovered a solution that works for transfers from VMS to NT\, but may not be general purpose. I located the A.pm module in the perl\lib\net\FTP directory on the pc and commented out the (octal) substitution line (it's the only one like it) as follows​:

# $readbuf =~ S/\015\012/\n/sgo;

:​::​::CLOSING​::​::​: It appears that this substitution is not needed and is causing the trouble (at least in my case.) I can now transfer ASCII files from VMS systems to my Win2K box\, and the CORRECT CR/LF is present on the destination Windows systems. No UNIX2WIN post-processing necessary. If this substitution is actually needed in other cases\, maybe a test should be made that skips this line for VMS to NT transfers? Maybe an environment variable or flag? Perhaps this could be looked at and incorporated in the next release. I know it could help a lot of people.

Mike O'Neal Bonneville Power Adm mjoneal@​bpa.gov

[p5pRT]

From nick@ing-simmons.net

Michael J - Tos-Ditt2 O'Neal \perl5\-porters@​perl\.org writes​:

# New Ticket Created by "O'Neal\, Michael J - TOS-DITT2" # Please include the string​: [perl #23305] # in the subject line of all future correspondence about this issue. # \<URL​: http​://rt.perl.org/rt2/Ticket/Display.html?id=23305 >

​::​::​:PROBLEM​::​::​:: When I tried to use NET​::FTP to transfer text files from VMS to NT (GET command using ASCII mode\,) FTP would add the Linefeed\, but not the required carriage return. Windows NT/2000 requires the CR/LF at the end of each line. VMS uses neither. When I transfer the files in binary\, NO line terminations are added\, as expected. I'm using Windows 2000 with the ActiveState Perl vers 5.8.0. I scoured the newsgroups and discovered this is a fairly common problem. I even posted a request in comp.lang.perl.misc with the same subject as the one in this email. No-one had an answer.

​::​::​:SOLUTION​::​::​: I discovered a solution that works for transfers from VMS to NT\, but may not be general purpose. I located the A.pm module in the perl\lib\net\FTP directory on the pc and commented out the (octal) substitution line (it's the only one like it) as follows​:

# $readbuf =~ S/\015\012/\n/sgo;

This might be a side effect of a mis-feature of Net​::FTP on perl5.8 it was calling sysread/syswrite which bypasses the :crlf handling which would have converted the "\n" to CRLF on Win32.

​::​::​:CLOSING​::​::​: It appears that this substitution is not needed

It is for Unix machines - FTP has \015\012 as part of the protocol specification for TEXT mode. But UNIX machines only want _their_ \n (which happens to be \012). Traditional MacOS would want \n too but there it would be \015. So waht is supposed to happen is the s/// converts protocol's \015\012 ro \n and the PerlIO converts \n to what platform expects in a file.

and is causing the trouble (at least in my case.) I can now transfer ASCII files from VMS systems to my Win2K box\, and the CORRECT CR/LF is present on the destination Windows systems. No UNIX2WIN post-processing necessary. If this substitution is actually needed in other cases\, maybe a test should be made that skips this line for VMS to NT transfers? Maybe an environment variable or flag? Perhaps this could be looked at and incorporated in the next release. I know it could help a lot of people.

Mike O'Neal Bonneville Power Adm mjoneal@​bpa.gov

[p5pRT]

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'