Skip to main content

After account transfer (transfer tool), Perl scripts won't run



  • swbrains
    Ok, so I figured out what was going on, but I don't know why it happens. On the main domain account, I had done a transfer as usual but then I had updated a bunch of scripts because Perl changed from 5.16 on the old server to 5.26 on the new server and some additional code changes were needed. When I uploaded the modified files to the new server, I logged in using FileZilla as "root" and changed to the domain's cgi-bin dir and uploaded them. On my local PC, my scripts have CR/LF at the end of every line when I edit them and look at the local copy in hex mode. Uploading to the server using FileZilla while logged in as root seems to keep the CR/LF which causes the Perl interpreter to issue the "no such file or directory" error. If I then log in to the domain account with FileZilla but as the user id for that account, then uploading the same script from my local PC, the file is somehow translated from CR/LF to just LF, which Perl likes and runs the script properly. The strange part is, if I log into the account as "root" and just open and view a remote Perl file from the server, it shows up as "UNIX" format in my editor and in hex mode it only has a LF character. But if I then log into the account as the user id and just open and view a remote Perl file from the server, my editor says "PC" format (CR/LF in hex mode). I can even modify it and re-upload it to the server and it still works, even though the editor shows CR/LFs when I edit it. Somehow, being logged in as "root" vs. the account's user id changes how the FTP process uploads the file in FileZilla (or so it seems), since I know my local hard drive copy has CR/LF in every file. It seems that FileZilla might be rewriting the CR/LFs during the upload in the case of the user id login, but not in the case of the "root" login. I do have separate saved logins for the user id login vs the root server login. However, all of my login configurations in FZ have the remote server type set to "Default (autodetect)", so that doesn't seem to be an issue. Since I didn't re-upload any script on the new server for the other hosted accounts I transferred, they ran properly. I only modified the main domain's scripts and re-uploaded them as root, which did not translate the CR/LFs, so only that account had the issue. What also threw me off was that the scripts executed properly from the shell; just not from the browser. So my guess is that this is something in my FileZilla configuration but I haven't found out what it could be. I don't know of any server-side transliteration that would occur during uploading of files, so I assume this is an FTP app (FileZilla) thing. I'm curious, though, where the setting is that is doing that translation in some cases... UPDATE: It looks like my account login in FileZilla uses FTP and the root login used SFTP, so that may be the difference in how the server handles the CRLF translation...
  • cPRex Jurassic Moderator
    I'm glad you found that issue!

Please sign in to leave a comment.