CRLF problem.

I create a small perl file on a Windows platform and all the lines will end
CRLF. I upload the file to server A and it runs OK. I upload the same file
to server B and I get the 500 error message. If I chande all the CRLF to
LF the program works OK on server B.
Both servers are on Linux platforms. How can I automatically convert CRLF
to LF on server B. Or, what is server A doing that server B is not.

Regards
John

Re: CRLF problem.

"John" writes:

> Both servers are on Linux platforms. How can I automatically convert CRLF
> to LF on server B. Or, what is server A doing that server B is not.

My guess would be that you upload to A using FTP in ASCII-mode and
upload to B in some sort of binary mode.

//Makholm

Re: CRLF problem.

"Peter Makholm" wrote in message
news:87fxwikxdp.fsf@hacking.dk...
> "John" writes:
>
>> Both servers are on Linux platforms. How can I automatically convert
>> CRLF
>> to LF on server B. Or, what is server A doing that server B is not.
>
> My guess would be that you upload to A using FTP in ASCII-mode and
> upload to B in some sort of binary mode.
>
> //Makholm

Using WS-FTP Pro. Settings are identical.
Regards
John

Re: CRLF problem.

On Jan 28, 4:19 am, "John" wrote:
>
> Both servers are on Linux platforms. How can I automatically convert CRLF
> to LF on server B. Or, what is server A doing that server B is not.


On a Unix/Linux platform, you can remove all the CRs from a script
(or any file, really) with the following:

perl -pi.bak -e 's/\cM//g' script.pl

This removes all the CRs from the file named "script.pl", converting
all CRLFs to just LFs. (A copy of the original file will be saved as
"script.pl.bak".)

Also, how are you uploading the file to servers A and B? If you're
using ftp, I recommend using "ascii" mode before "send"ing or
"put"ting. This will convert your Windows line endings to Unix line
endings (so that you won't have to do it yourself later).

Another thing you might try is to call the script with "perl" in
the command line, like this:

perl script.pl

instead of just:

./script.pl

Not using "perl" in the command line will call whatever's specified in
the shebang line, and if the shebang line ends with a CR, like this:

#!/usr/bin/perl^M

the "perl^M" interpreter will be called, which can cause unexpected
things to happen.

(To confuse matters, some text editors will automatically hide the
"^M" characters, making you think they don't exist when in fact they
do.)

Calling your script with "perl" in front of it avoids several other
problems as well (like ones related to executable permissions and
$PATH issues), so I usually recommend that people run Perl scripts as
"perl script.pl" instead of just "script.pl".

So if you aren't already, call your script with "perl" before it
and see if that makes any difference.

I hope this helps, John.

-- Jean-Luc

Re: CRLF problem.

wrote in message
news:38c5c2ea-4e75-443e-8358-f83e57514e90@y5g2000hsf.googleg roups.com...
> On Jan 28, 4:19 am, "John" wrote:
>>
>> Both servers are on Linux platforms. How can I automatically convert
>> CRLF
>> to LF on server B. Or, what is server A doing that server B is not.
>
>
> On a Unix/Linux platform, you can remove all the CRs from a script
> (or any file, really) with the following:
>
> perl -pi.bak -e 's/\cM//g' script.pl
>
> This removes all the CRs from the file named "script.pl", converting
> all CRLFs to just LFs. (A copy of the original file will be saved as
> "script.pl.bak".)
>
> Also, how are you uploading the file to servers A and B? If you're
> using ftp, I recommend using "ascii" mode before "send"ing or
> "put"ting. This will convert your Windows line endings to Unix line
> endings (so that you won't have to do it yourself later).
>
> Another thing you might try is to call the script with "perl" in
> the command line, like this:
>
> perl script.pl
>
> instead of just:
>
> ./script.pl
>
> Not using "perl" in the command line will call whatever's specified in
> the shebang line, and if the shebang line ends with a CR, like this:
>
> #!/usr/bin/perl^M
>
> the "perl^M" interpreter will be called, which can cause unexpected
> things to happen.
>
> (To confuse matters, some text editors will automatically hide the
> "^M" characters, making you think they don't exist when in fact they
> do.)
>
> Calling your script with "perl" in front of it avoids several other
> problems as well (like ones related to executable permissions and
> $PATH issues), so I usually recommend that people run Perl scripts as
> "perl script.pl" instead of just "script.pl".
>
> So if you aren't already, call your script with "perl" before it
> and see if that makes any difference.
>
> I hope this helps, John.
>
> -- Jean-Luc

Hi

Problem solved. The clue was 'ascii mode'. Server B uses vsftpd as the ftp
program.
Once I added ascii_enabled_download=YES and ascii_enabled_upload=YES all was
well.
Many thanks for pointing me in that direction.
Regards
John

Re: CRLF problem.

On Jan 28, 7:54 pm, "John" wrote:
> wrote in message
>
> news:38c5c2ea-4e75-443e-8358-f83e57514e90@y5g2000hsf.googleg roups.com...
>
>
>
> > On Jan 28, 4:19 am, "John" wrote:
>
> >> Both servers are on Linux platforms. How can I automatically convert
> >> CRLF
> >> to LF on server B. Or, what is server A doing that server B is not.
>
> > On a Unix/Linux platform, you can remove all the CRs from a script
> > (or any file, really) with the following:
>
> > perl -pi.bak -e 's/\cM//g' script.pl
>
> > This removes all the CRs from the file named "script.pl", converting
> > all CRLFs to just LFs. (A copy of the original file will be saved as
> > "script.pl.bak".)
>
> > Also, how are you uploading the file to servers A and B? If you're
> > using ftp, I recommend using "ascii" mode before "send"ing or
> > "put"ting. This will convert your Windows line endings to Unix line
> > endings (so that you won't have to do it yourself later).
>
> > Another thing you might try is to call the script with "perl" in
> > the command line, like this:
>
> > perl script.pl
>
> > instead of just:
>
> > ./script.pl
>
> > Not using "perl" in the command line will call whatever's specified in
> > the shebang line, and if the shebang line ends with a CR, like this:
>
> > #!/usr/bin/perl^M
>
> > the "perl^M" interpreter will be called, which can cause unexpected
> > things to happen.
>
> > (To confuse matters, some text editors will automatically hide the
> > "^M" characters, making you think they don't exist when in fact they
> > do.)
>
> > Calling your script with "perl" in front of it avoids several other
> > problems as well (like ones related to executable permissions and
> > $PATH issues), so I usually recommend that people run Perl scripts as
> > "perl script.pl" instead of just "script.pl".
>
> > So if you aren't already, call your script with "perl" before it
> > and see if that makes any difference.
>
> > I hope this helps, John.
>
> > -- Jean-Luc
>
> Hi
>
> Problem solved. The clue was 'ascii mode'. Server B uses vsftpd as the ftp
> program.
> Once I added ascii_enabled_download=YES and ascii_enabled_upload=YES all was
> well.
> Many thanks for pointing me in that direction.
> Regards
> John

.... or you could use dos2unix which is on most unix platforms. It
converts CRLFs to LFs.