tags:

views:

177

answers:

5

Whenever I alter (or even just resave without altering) a Perl file, it completely takes down our backend. I have no idea what the problem could be. Permissions are correct. Encoding is correct. Encoding is UTF-8. Transfer mode was ASCII.

I might not deal with Perl too much but I have no idea what the problem could be. The network admin hosting our website has no idea what the problem could be.

Text editors I tried: Dreamweaver, TextMate, Vim Operating systems I tried: Mac OS X, Linux (Ubuntu) FTP clients I tried: Transmit (Mac), Filezilla (Linux (Ubuntu))

It's not that it's bad code, I even tried to open and solely save and my backend still goes down.

The network admin told me that he ran the files through a dos2unix converter and it worked immediately. I of course tried this and it did not, more so it wouldn't make any sense, since I tried this in some of the most respected editors and I don't think it would make such drastic changes to the file type without any user input. (when I say respected editors Dreamweaver is not included in that sentiment).

I personally think it is some sort of server-side issue because I have crossed my t's and dotted my i's in regards to any possible client side issue but I have tried everything. Any opinions as to what the root of this problem is, and any possible solutions? Thanks in advance.

+1  A: 

You do not say what kind of framework/server you are using.

Maybe the server reloads the file while it is still being written by FTP or whatever? (I.e. that the file is not complete when the server reads it?)

Will a server restart fix the problem once the file is uploaded?

rebra
A: 

Response to rebra: No frameworks are used, and I don't know what kind of server this is on. This is basically a one man project on a shared host which was pretty horribly maintained and I'm trying to clean house.

Yeah that does make sense and I asked the server people about that, one of my first questions actually, but even if that is the case, I can't reboot via Plesk (kind of like cPanel). But thanks for that, you put into technical words/explanation what I was thinking of the whole time.

+1  A: 

It sounds like you are using dos2unix before the transfer but the network admin is using it after. Perhaps it's doing something different in that case.

How many lines are in the file? What is the file size before and after you save it, after you transfer it, and after transfer and running dos2unix on it?

If this is just a line ending problem, you might point your network admin at http://www.perlmonks.org/?node_id=586942.

ysth
+4  A: 

Try setting binary mode in your FTP client. That will allow you to experiment with different line endings (dos2unix) on the client side, without worrying about them being translated during transfer.

Rich
I've seen this before and it's always been do to ascii mode ftp in the text editor. Please note that it's a good idea to change all the \r\n to \n as well in the file as bin mode just sends the file as is. Any carriage returns will still be sent.
Mark Nold
+3  A: 

I've had this problem in the past and line-feeds were indeed the culprit. Your editor and/or FTP program may be mangling the linefeeds. Running dos2unix on the server is a good test as to the problem but not the cause.

Generate an MD5 hash of the file after each step in saving and transport to find where it changes.

Chris Nava