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

Re: [MacPerl] When is \r really \n in MacPerl!?



At 10.33 1998.02.10, Mark F. Murphy wrote:
>Just for the record, I converted over a script which auto determines the
>line feed seperator for a data file.  It broke under MacPerl because of
>these escaped chars being reversed.  So now I must use \x0D\x0A instead if
>I want to program around MacPerl's difference in the Perl community.

So you want MacPerl to write text files in non-Mac format?  That makes no
sense to me.  \n is defined as "local line separator," not "Unix line
separator."  It does what it is meant to do.  If you want to determine
exactly \012, then don't use \n.  It is *wrong*.


At 10.25 1998.02.10, Mark F. Murphy wrote:
>I do plenty of development on the Mac... and it doesn't make "sense" to
>switch around common escape characters that are pretty well defined in the
>ascii namespace.

No, \n is not a defined ASCII character.  That is where you are mistaken.

>What makes "sense" is for the a Mac program to understand what \r and \n
>are and to do the right thing for the end user's visual result.  Changing
>the meaning in a programming language can be disastrous.

The meaning was not changed, you misunderstand the meaning.

>Of course, I've been down this similar path on this mailing list before and
>I already know what will happen.  There will be a bunch of people proclaim
>how MacPerl does it the Mac way, how we all ought to be glad Perl is even
>on the Mac... how much work the programmer has put into the product...
>yadda yadda yadda.

/kick

>The sad part is that MacPerl *could* do the right thing on the Mac.  It
>could recognize a perl script to have DOS, Unix, or Mac line endings.  It
>could print out a newline to it's screen as a CR.

You don't know what you are talking about.  This has been discussed at
length, and no, there is no good way to do it at the moment.  If you think
it can, the source is available; do it yourself and submit a patch.

>Most other language based products do so on the Mac (since the Mac is the
>*most* flexible computer around).  MacPerl isn't flexible... it just cheats
>by tweaking well defined things around.

If you think \n and \r are well-defined, then you suffer the consequences.
I don't feel bad for you, as you keep making the same error.  It is not
difficult; even the Unix perl folks on IRC that have discussed this have
conceded that \r\n is wrong, that if the code is expected to work on all
platforms you must use \015\012.

I am trying not to flame here, but you are being insulting and hardheaded
about something that has already been gone over before, you continue to
assert your error is correct, and Matthias last time sent a lengthy post
about why it is the way it is and about how this discussion is OVER, not to
be brought up again.  Please do NOT respond to the list about this.  I am
resending Matthias' previous post.

--
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey=('B76E72AD',[1024,'0824 090B CE73 CA10  1FF7 7F13 8180 B6B6'])
#==               New Book:  MacPerl: Power and Ease               ==#
#==    Publishing Date: Early 1998. http://www.ptf.com/macperl/    ==#



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch