In article <[EMAIL PROTECTED]>, Lars Henrik Mathiesen <[EMAIL PROTECTED]> writes: >> Date: Sat, 8 Jun 2002 22:10:46 +0000 (UTC) >> From: [EMAIL PROTECTED] (Ton Hospel)
...snip some boring stuff about \0.. >> >> Actually it's a browser bug. newlines in text fields MUST be sent >> as cr/lf. It's in the standard. > > And that was what all the browsers did --- even though the programs > might not have had any crs in the editor window they were pasted from. > >> But by default you should take what's in the text field, replace >> cr lf by \n and store in a file. > > Did you read all I wrote? There were submissions that would stop > working if that was done. Since they worked on Windows, and when moved > to Unix without changing the newlines, there is an OS issue. Mmm, i'd like to know if this was 5.6.1 (the \r stripping hasn't been there always), and if any of them was maybe compiled with PERL_STRICT_CR (which changes this behaviour) ? I don't really don't see anything in the docs or the source that would give rise to an OS issue. > >> Now perl actually has a weird rule that \r before \n is in fact >> dropped by the parser. Which is how perl works and has nothing to do >> with transfer issues. > > Except that it does not always work --- most of the time, leaving > cr/lf inside strings worked just fine, but in a few examples there'd > be spurious cr's in the output on Linux, and changing cr lf to lf in a > string would make it work. Possibly a Perl bug, but the issue exists. I tried it before sending my mail, and could not find cases where perl did not behave as described in the docs. But of course that could very well mean I didn't test enough. I'd be very interested if you can give me a counterexample. > > On this course, I don't think anyone was trying to have literal > carriage returns in their programs, so \r\r\n isn't that relevant --- > but it's still an issue if you do newline canonicalization on Unix: > \r\r\n from browser -> \r\n when stored -> \n when parsed -> \n when Basically agreed. cr cr lf from browser, cr \n when sent to (text mode) filehandle, cr lf on disk, cr lf when read, \n when parsed, \n when sent to STDOUT, lf when entering the tty driver, os cursor goes left and one down > printed, but \r\r\n from browser -> \r\r\n when stored -> \r\n when > parsed -> \r\r\n when printed on Windows (textmode assumed). Right? Basically disagreed. cr cr lf from browser, cr \n when sent to (textmode) filehandle, cr cr lf on disk, cr lf when read, \n when parsed, \n when sent to STDOUT, (I don't know about windows screen driver), os cursor goes left and one down The source seems to say the script is opened in textmode, unless overridden with compiler definitions: perl.h:#define PERL_SCRIPT_MODE "r" So I assumed textmode for the perl source read (again, I don't have windows to really check my understanding) > > What I'm really after is a way to ensure that the referees won't have > to test on both Windows and Unix. The 'correct' way would probably be Absolutely, that would suck. > to specify (and checked by submit.cgi) that the program as sent must > have CR/LF newlines, which will be stored as-is on Windows, and as LF > only on Unix --- and the same goes for newlines in input files and > expected output, of course. If it then fails on one platform, it's > rejected under the rule that says that solutions must work everywhere. No. I think that the right way is to replace cr lf by \n, and then store into a file in textmode. (and also translate lone lf to \n (which is likely the same on your server) for the browsers that get even the cr lf wrong. This should work on both windows and linux. I really don't think any extra buttons should be needed, nor do we really want it for something this obscure. The "normal" escape mechanism discussed should be enough for the very rare exceptions. Quick perusal of toke.c doesn't show me anything special going on with cariage return (though there are a few (non standard ?) compile time options you can set to get differing behaviours). Are maybe windows perls compiled with such options ? > > I think that's the same as you're saying, in fact. But it would be > good to know when there can actually be a difference, so approval > doesn't depend on which ref does the testing. Flag -F at line end is The -F thing is simply a perl parsing bug, but it's there on both unix and windows as far as I know (I'm only sure for unix, don't have windows to check). It's simply that it forgets to drop the \n when reparsing the #! line if I remember the discussion on p5p correctly. The fact that the file is opened in textmode should not let the parser ever see any carriage return. > one such case, literal cr at line end might be another. I don't *think* so. Prove me wrong with a counterexample ! A perl -V for the failing and succeeding perls would also be fascinating. Also the respective sources as a binary type attachment would help to make the discussion less theoretical.
