1. FTP performed incorrectly in binary mode, not text mode
2. Windows
3. Mac or Unix

Windows and Unix systems use different end-of-line characters. The ^M bit you're seeing is from a Windows system, and isn't needed on the Unix system.

Thanks for the dos2unix tip as it solved a problem for me.

You might try which (or where or whatever your OS/distro decrees to find perl in some other location; you might also try perl -v from /usr/bin/perl/ and see if it spits back version info and a short note on finding help.

No, it means that /usr/bin/perl^M cannot be found. Please read the error message correctly. The ^M is the key to the entire problem, it's not something that just can be ignored.

dos2unix /usr/local/bin/sr_server

# or more perlish

perl -pi -e 'tr[\r][]d' /usr/local/bin/sr_server

[download]

#!/usr/bin/perl --
[download]

#!/usr/bin/perl -- works for me, but #!/usr/bin/perl ^M -- doesn't.

On what OS does -- tell the kernel to chop off a character from the path following the #!?

Isn't the point that if the original shebang (on *nix) is:

#!/usr/bin/perl --
[download]

And the file gets downloaded to win in binmode it will become:

#!/usr/bin/perl --^M
[download]

And the ^M will then be ignored!

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)

'--' isn't used to 'chop off' any characters - when used, as BrowserUk implied earlier, it flags the end of the CLI option list to the script/executable and thus whatever follows (in this case the ^M) is/are arguments to the script/executable.

The 'classic' usage is when grep'ping for a string containing dash(es) &/or minus(es) e.g. grep -- this-string some_file - which tells grep that 'this-string' is a string and not a malformed CLI option.

A user level that continues to overstate my experience :-))