[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] MacPerl cgi-script question



haakona@ifi.uio.no writes:
>At 10:22 11-03-96, Charles B. Cranston wrote:
>>You might try \r instead of \n on the theory that if \n
>>which is LF on Unix is mapped to CR on the Mac (because
>>the Mac standard is to use CR betwen lines) then the
>>logical map for \r which is CR on Unix would be LF on
>>the Mac.  At least this is what most Mac C compilers do...

Correct.

>I=B4m a bit vague on how it actually works, but it seems to me it *SHOULD*
>work like this:
>\n = local line end convention

Correct.

>\r = Carriage Return

I disagree. See below.

>\l = Linefeed

There is no \l as far as I know.

>I just ran this though
>printf "%x %x %x %x",ord "\n" ,ord "\l",ord "\r", ord "\f";
>
>and got this result:
>d 0 a c
>
>:-(

Looks good to me.

>Once I've got K&R open, thought I'd mention the ansi standard states
>explicitly that \n is "newline NL (LF)" and \r is "carriage return CR". As
>far as I know "NL" is not an actual character, but rather refers to
>whatever is the charcter used to signify newline in your locale. According
>to this \r should be unambiguous.

My copy of the ANSI C standard says that:

 - \n is "new line". Moves the active position to the initial position of the
   next line. When writing to a file, this should generate the preferred line
   terminator on a platform (\015 on a Mac, \012 on Unix).
 - \r is indeed "carriage return", BUT, the standard *requires* that \r and
   \n be internally coded with different values, so it makes sense to code
   \r as whichever of \015 and \012 which is not taken up by \n.

The Mac compiler choice of \n == \015 and \r == \012 therefore makes sense.

>No mention of \l :-(, though I think it's a splendid idea, if I say so myself.

CRs and LFs are rather obsolete concepts nowadays. What people really want is
end of line. The ANSI & Perl concepts of \n et. al. are intended to map to
platform specific characters, and thus using them for protocols like Telnet
and HTTP where certain octet values are mandated is a bad idea IMHO.

We've been through this discussion too many times, and I'm getting tired of it.

>PS, a smart thing to do when working with textfiles from other platforms is
>to transfer them as text, that way they=B4re converted to the local line end
>convenion and you avoid such hassles.

Generally good advice, but not applicable in the present case, where the data
came from the Web.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
  "Tossing around Slavic swearwords?  Tsk tsk.  Nekulturny peasants."
                                      -- Paul J. Zanca <pjz@sccsi.com>