And It would seem that this translation happens between perl and the OS. That is, $/ is "\n" on windows.

Provided you have the file open in text mode, that is :-) update: that's when the translation happens, I mean. $/ doesn't change when you switch to binary mode.

In any case this behaviour (probably not coincidentally) is exactly the same for C:

The C programming language provides the escape sequences '\n' (newline) and '\r' (carriage return). However, contrary to popular belief, these are in fact not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two things:

1. Each of these escape sequences maps to a unique implementation-defined number that can be stored in a single char value.

2. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. (Note that a C implementation is allowed not to store newline characters in files. For example, the lines of a text file could be stored as rows of a SQL table or as fixed-length records.) When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, the second mode of I/O supported by the C library, no translation is performed, and the internal representation of any escape sequence is output directly.

Apparently a "\n" can be multiple characters on the way out

In most operating systems, lines in files are terminated by newlines. Just what is used as a newline may vary from OS to OS. Unix traditionally uses "\012", one type of DOSish I/O uses "\015\012", and Mac OS uses "\015".

Perl uses "\n" to represent the "logical" newline, where what is logical may depend on the platform in use. In MacPerl, "\n" always means "\015". In DOSish perls, "\n" usually means "\012", but when accessing a file in "text" mode, STDIO translates it to (or from) "\015\012", depending on whether you're reading or writing. Unix does the same thing on ttys in canonical mode. "\015\012" is commonly referred to as CRLF.

The line endings are extremely annoying if one is on a dual boot box (Win/*nix) and trys to tweak CGI supposed to run on Apache/*nix as well as on IIS/Win.

Whenever one writes textmode *\n* to a file on booted Win and later boots the other OS reading the same file on *nix it ends up to be \r\n.
Extremely annoying imho. Sometimes one forgets about it and then wonders why things don't work as expected .

Well, you're not alone :-). Here, comments from inside Lincoln Stein's CGI.

# Define the CRLF sequence.  I can't use a simple "\r\n" because the m
+eaning
# of "\n" is different on different OS's (sometimes it generates CRLF,
+ sometimes LF
# and sometimes CR).  The most popular VMS web server
# doesn't accept CRLF -- instead it wants a LR.  EBCDIC machines don't
# use ASCII, so \015\012 means something different.  I find this all
# really annoying.
[download]

---

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!