Line ending issue

[ontology]

I have files that are on a Linux server, but have Windows CR LF line endings.  If I transfer these files from the server to the Mac in binary mode, I get the CR LF as expected.  If I transfer in ASCII, or Automatic I will get LF LF (with Use Unix line endings checked), or CR CR (with Use Unix line endings unchecked).

I expected the line endings to be unchanged, as CR LF with the Use Unix line endings unchecked.
I expected the line endings to be changed to a single LF with the Use line endings checked.

Am I doing something wrong?

Thanks.

[spacific]

Weird!

Just to be clear: how are you assessing the line endings on your Mac?  Are you using a hex dump of the files, or are you using some text editor. If the latter, are you sure that the editor isn't changing line endings as well?

[JD]

The problem is that this cannot be solved using ASCII mode transfers, because line endings must be represented as CRLF pairs during transmission (as is required by the FTP protocol specification for ASCII transfers), and while this works without problems when the source file has line endings which are native to the platform, in the case of foreign line endings in a source file, you can get unexpected results.

eg:-
Linux (and Mac OS X and all Unix based systems) use LF as a line eding
Windows uses CFLF as a line ending
Mac OS (classic) uses CR as a line ending

So for the Linux server, transferring an ASCII file with CFLF as the line endings in the file, results in the server translating each LF into a CRLF pair, resulting in each line ending with CRCRLF. The only reasonable thing Yummy can do is to translate the CRLF pair back to the platform line ending (Mac OS X uses LF) and that leaves a line with a CR so Yummy replaces that with the platform line ending too.

There's no good way around this other than:

a) Correct the line ending on the server
b) Use Binary mode transfers

[spacific]

There's no good way around this other than:
a) Correct the line ending on the server
b) Use Binary mode transfers

or
c) Don't use Windows!   

(This is all rather disturbing really, isn't it, if you think of it in general terms. That while the computer world has adopted standards for all manner of connectivity, hardware conventions, dns, ip, html, css, ..., it can't agree on a single standard for a line ending  )

[ontology]

So for the Linux server, transferring an ASCII file with CFLF as the line endings in the file, results in the server translating each LF into a CRLF pair, resulting in each line ending with CRCRLF. The only reasonable thing Yummy can do is to translate the CRLF pair back to the platform line ending (Mac OS X uses LF) and that leaves a line with a CR so Yummy replaces that with the platform line ending too.

OK.  Thanks for the update & I understand now.  I will use binary transfers for now.

Note that I have another FTP client that is able to FTP these files from the linux server to the mac, and translate the line endings to a single LF.  But I prefer to use Yummy.

BTW, I am viewing the files on the Mac with a binary file editor.

[paulc]

c) Don't use Windows!   

(This is all rather disturbing really, isn't it, if you think of it in general terms. That while the computer world has adopted standards for all manner of connectivity, hardware conventions, dns, ip, html, css, ..., it can't agree on a single standard for a line ending  )

Ha, you made me almost go on a 10 page rant about "hi-ascii" characters on Redmond software, something that plagued the hell out of my when I was championing all electronic production back in the eighties.