in reply to Re^12: Native newline encoding
in thread Native newline encoding

I didn't know there was a single RFC in question.

That explains a lot.

You didn't bother to read the post to which you responded, or follow the links it contained; just knee-jerked a pointless response to a closing comment that had little to do with the main text of that post.

And now try to further distract with a bunch of meaningless, irrelevant statistics unrelated to anything in particular.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

The start of some sanity?

Replies are listed 'Best First'.
Re^14: Native newline encoding
by sauoq (Abbot) on May 28, 2012 at 21:36 UTC
    I see. Well, in my defense, it was easy to read:
    Things (will) get far more messy once the RFCs start dealing with Unicrap.

    And think that by using the plural "RFCs" you were talking about more than one... like all of them in general. Or, at the least, all of them related to FTP.

    Of course, it's unlikely that the FTP RFCs will be greatly affected by "unicrap" because unicode is just binary.

    If you still don't see where I was coming from, there's no point in continuing. Truly.

    -sauoq
    "My two cents aren't worth a dime.";
[reply]
[reply]
        And when ftping XML documents, it is normal to do so in using the ftp ascii mode so that the embedded newlines are handled correctly for cross-platform transfers.

        Instead, you should transfer in binary and then just choose an editor that can handle the encoding properly for you.

        hth

        -sauoq
        "My two cents aren't worth a dime.";
[reply]
    		[reply]

    In Section Seekers of Perl Wisdom