It is normal that the "\015\012" stuff works on linux, precisely because
of what the ":crlf" filter does.
But the way the test is written, it is bound to fail on EBCDIC machines
(if that matters at all for mod_perl), because CR LF doesn't spell out
that way in EBCDIC.
When the perl code writes out a single "\n" (LF) on a handle that has
"crlf" translation on, it becomes CR LF which spells out as "\015\012"
in ASCII.
Reading the same data back from a handle that does not have that
translation (the apr handle in this case), we read back the two
characters.
But when there is a translation on the handle that is being read
(further down in the test code), we don't see the CR, but just the LF.
For the test to work in EBCDIC machines as well, take a look at the hack
at the top of CGI.pm. Here is the snippet :
# Define the CRLF sequence. I can't use a simple "\r\n" because the
meaning
# 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.
$EBCDIC = "\t" ne "\011";
if ($OS eq 'VMS') {
$CRLF = "\n";
} elsif ($EBCDIC) {
$CRLF= "\r\n";
} else {
$CRLF = "\015\012";
}
-----Message d'origine-----
De : Stas Bekman [mailto:[EMAIL PROTECTED]
Envoyé : mardi 30 septembre 2003 21:20
À : Randy Kobes
Cc : Ayhan Ulusoy; [EMAIL PROTECTED]
Objet : Re: RE : [mp2] PERLIO_K_RAW in apr_perlio.c
Randy Kobes wrote:
> On Sun, 28 Sep 2003, Ayhan Ulusoy wrote:
>
>
>>I am worried about this.
>>Does 'PERLIO_K_RAW' also make the following call "do nothing" ? :
>> binmode($apr_f, 'utf8');
>
>
> That's a good point ... The binmode($apr_f) call (without a
> layer) seems to "do nothing", in the sense of not being
> needed as far as apr goes, but PERLIO_K_RAW is necessary in
> order to be able to put in a binmode($apr_f). However, with
> utf8 data the binmode($apr_f, ':utf8') call is necessary on
> the perl side. I added a test for this below - without the
> binmode($apr_f, ':utf8') calls, the utf8 test fails for me,
> but with these calls, they pass.
Great job, Randy! The test passes on linux.
I have a few comments
> + my $data_dir = 'docs/user/handlers';
> + local $/;
> + my ($rfh, $wfh, $pfh);
> + for my $file ('general.pod', 'filter_logic.png') {
> + my $in = catfile $vars->{top_dir}, $data_dir, $file;
We can't rely on having docs/ dir, since it's not a part of the
modperl-2.0
repository, it's just a magical checkout. Besides any of the above two
files
could be renamed in the future, so relying on these is not a good idea.
Instead please create dedicated files under t/htdocs/perlio.
> + my $dat = catfile $dir, "dat$$.dat";
why do we need $$? we will need to cleanup after ourselves, so having a
constant filename will help. The cleanup process is now sort of
semi-working.
Hopefully will fix it at some point.
> + open $wfh, ">:crlf", $dat
From 5.8.1's perldelta.pod:
The "CR CR LF" problem of has been fixed, binmode(FH, ":crlf")
is now effectively a no-op.
You need to tell me, what is it about ;) but should we we run that only
if
perl < 5.8.1. at the very list would be nice to put a comment that it's
a noop
on 5.8.1+ as a reminder.
> + ok t_cmp(2000,
> + count_chars($text, "\015\012"),
> + 'testing for presence of \015\012');
I wonder how this works on linux then. After all you did write "\n", not
"\r\n". Also why do you use "\015\012" and "\n"? and not "\r\n"/"\n" or
"\015\012"/"\012" everywhere? just to make different tests?
Finally what happens on Mac where we have only "\r" (\015)?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
