[27023] in Perl-Users-Digest
Perl-Users Digest, Issue: 8946 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 12 18:06:05 2006
Date: Sun, 12 Feb 2006 15:05:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 12 Feb 2006 Volume: 10 Number: 8946
Today's topics:
Re: Absolute Novice (Mac Tiger) Needs Help <ben.usenet@bsb.me.uk>
Re: Absolute Novice (Mac Tiger) Needs Help <tadmc@augustmail.com>
Re: Absolute Novice (Mac Tiger) Needs Help (James Taylor)
Re: Absolute Novice (Mac Tiger) Needs Help (James Taylor)
Re: Absolute Novice (Mac Tiger) Needs Help <noreply@gunnar.cc>
Re: Absolute Novice (Mac Tiger) Needs Help <jwkenne@attglobal.net>
Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Pe (Anno Siegel)
Re: Perl vs. Python <rutski89@gmail.com>
Re: Perl vs. Python <io@localhost.localdomain>
Re: Perl vs. Python <eflorac@imaginet.fr>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 12 Feb 2006 16:11:36 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <pan.2006.02.12.16.11.35.972864@bsb.me.uk>
On Sun, 12 Feb 2006 05:43:50 +0000, James Taylor wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> On Sat, 11 Feb 2006 22:55:58 +0000, James Taylor wrote:
>>
>> > Surely, the point of \n is that it represents a newline on *any*
>> > platform. MacOS X is (NextStep/BSD unix) so newlines are linefeeds
>> > like any other sensible operating system.
>>
>> Sadly no.
>
> Err... haven't we just established that \n *does* change to reflect the
> local newline? On most sensible systems newline=linefeed but on some weird
> ones it is a different character or character sequence.
I've done a bit of reasearch and we are both partly right and both partly
wrong. I think the position is a mixed one, because old MacPerl can
(and did) try to "fix" things by making \n mean \x0d (\r) but Perl on
Windows didn't do the same because line the termination is two characters
so \n meant \x0a as on most other systems. On Windows ports of Perl, the
IO system mapped \n <=> \r\n during IO to and from text files. MacPerl
did not need to do any mapping because \n was aready \x0d. Now, of
course, Perl on a Mac does what is does on any other *nix system. This
must be "right", but will cause problems when using Perl to read old Mac
text files.
>> Sort of There are several places in Perl where "the right thing
>> happens" depending on where the script is running. Non-binary file IO
>> is one.
>
> Yes, I thought as much. So why was it necessary to muck about with \n?
I doubt that it was done with any deliberate intent. It is quite possible
it is just what happend with the C library/compiler used to port Perl to
the old MacOS. I have certainy seen hints that this is why it happened.
Certainly the mixed effect on Windows (\n meaning \x0a as usual but
mapping to \r\n on IO) just mirrors what C compilers and libraries had
historically done on Windows.
>> Other places include ^ and $ which match (sometimes) after and before a
>> line ending. As far as I know, the meaning of \n and \r remain the
>> same, however.
>
> Do they? They certainly should, but I'm not so sure they do.
No, you are right. I doubt that \r meant anything but \x0d on old
MacPerl, but you are right that \n *did* mean \r on old MacPerl. \n did
not change its meaning on Windows. The \n => \r\n mapping on IO was very
limited (for example writing the string "\r\n" produced only "\r\n" and
not "\r\r\n" as you might expect if \n had somehow changed its meaning).
> Really? Oh cool, then it's not as bad as I thought.
I think the only thing that was as bad as you thought was old MacPerl that
*did* make \n mean \r! Everything else was as sane as it could be.
> people have offered different interpretations of this that I'm not going
> to believe it until I can test it on a dodgy newline system such as
> Windows or MacOS Classic.
Quite! I have tried to find out as much as I can from a paper study,
because I did not want to add further to the confustion. I hope I have
clarified rather further obfuscated the matter.
>> BTW, this is simplified in Perl 6. \n matches "line end"
>><snip>
> The Perl6 zero-width assertions are certainly better, but I don't think
> that has any bearing on \n. You say that Perl6's \n matches "line end",
> but that sounds like its meaning will be different on every system which
> is just what's wrong with Perl5's \n. Couldn't they use a different
> backslash escape for the magically changing newline sequence and leave
> the old \n and \r with their traditional values?
OK, but as I read the current proposals, \n mean "line end" only in
matches -- there is no idea that it will mean something OS defined when
in a literal string (the gap between literal string and regexes has
widened in P6 so this won't feel odd). Maybe you should suggest a new
escape name? It does make sense to me to have one. Of course \x0a is
always available and can be made readable in Perl 6 with a rule name like
/abc<nl>/.
<portability arguments snipped>
>> The fundamental problem is hard and it is not obvious what solution
>> yealds the most useable results with the fewest surprises for
>> programmers.
>
> Really? Can you think of anything better than having the whole newline
> issue made transparent to the program because the IO layer handles the
> transliteration?
No I can't. I don't want to argue this point too strongly, but, as an
example of what I was thinking about when I said it is a hard problem, how
would a CGI program generate (portably) \r\n line endings for HTTP if \n
is mapped in the IO subsystem?
I don't want to press this point -- I can see a solution as can you, no
doubt. I only wanted to defend my position that the "line end" problem
is not as trivial as "map \n when doing IO".
> More to the point, can you think of anything worse than
> breaking the meaning of \n and \r in all existing software?
Well of course I can, but you don't mean that, I know! When I wrote I
was only sure of Linux, Unix, MacOS X and Windows 95/98 Perl
behaviour. I don't think MacPerl's solution is (was) the best one but
it is not without some small advantages.
I hope this has helped rather than hindered the debate!
--
Ben.
------------------------------
Date: Sun, 12 Feb 2006 13:14:03 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <slrnduv27r.kh4.tadmc@magna.augustmail.com>
James Taylor <usenet@oakseed.demon.co.uk.invalid> wrote:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>> Wes Groleau wrote:
>>
>> > BBEdit defaults to old-style linebreaks (\r)
>> > so the kernel treated the entire file as the shell command,
>> > leaving perl nothing to execute.
>>
>> I'm not a Mac user, but I thought that \r does represent a newline on
>> Mac, at least according to "perldoc perlport".
I cannot find that anywhere in perlport.
What specific wording did you see that led to that conclusion?
> Surely, the point of \n is that it represents a newline on *any*
> platform.
> At least, that's how it *should* be, but I have a nagging feeling I
> overheard people on this group describing it quite differently.
Can't comment on that without seeing the context.
> Can anyone put my mind at ease that the design of Perl is sensible, as
> described in the first paragraph, and not broken as described in the
> second paragraph? Thanks.
The "Newlines" section in perlport has this handy table:
| Unix | DOS | Mac |
---------------------------
\n | LF | LF | CR |
\r | CR | CR | LF |
\n * | LF | CRLF | CR |
\r * | CR | CR | LF |
---------------------------
* text-mode STDIO
Does that ease your mind?
Or are we only more confused because it hasn't been updated (has it?)
for Classic vs. OS X?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 12 Feb 2006 19:48:56 +0000
From: usenet@oakseed.demon.co.uk.invalid (James Taylor)
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <1hanuk0.xcq7631ty30zpN%usenet@oakseed.demon.co.uk.invalid>
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> OK, but as I read the current proposals, \n mean "line end" only in
> matches -- there is no idea that it will mean something OS defined when
> in a literal string (the gap between literal string and regexes has
> widened in P6 so this won't feel odd).
Well, I still think having \n change its meaning depending on platform
is a really bad idea for portability and will mean that programmers
cannot use \n safe in the knowledge it means what they think it means. I
think there's a principle of least surprise that applies here.
> Maybe you should suggest a new escape name?
> It does make sense to me to have one.
Yes, it would be much better to have a new escape for the new behaviour.
It doesn't matter what it is as long as it doesn't clash with an
existing escape and is reasonably memorable. Hmmm... how about \j ? It
has a shape similar to the arrow on some Return keys, and it reminds me
of ^J (linefeed). It's also easy to type a 'j' as it's one of the home
keys. Can you see any objections to \j being used?
> Of course \x0a is always available and can be made readable
> in Perl 6 with a rule name like /abc<nl>/.
Yes, a <nl> rule would be a good flexible way to do things.
However, I see \j working both in regexes and literal strings.
> I don't want to argue this point too strongly, but, as an example
> of what I was thinking about when I said it is a hard problem, how
> would a CGI program generate (portably) \r\n line endings for HTTP
> if \n is mapped in the IO subsystem?
Because you'd have a trait/property on the socket file handle explicitly
saying that \r\n was the newline sequence for this channel.
> I don't want to press this point -- I can see a solution as can you, no
> doubt. I only wanted to defend my position that the "line end" problem
> is not as trivial as "map \n when doing IO".
Isn't it? Surely every file handle can have a different newline
property, and if necessary these could be changeable at runtime.
> I hope this has helped rather than hindered the debate!
Sure! And just in case it wasn't clear, I agree with *nearly* everything
you've said. ;-)
--
James Taylor
------------------------------
Date: Sun, 12 Feb 2006 20:06:58 +0000
From: usenet@oakseed.demon.co.uk.invalid (James Taylor)
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <1hanx13.3hkmcw16bt86mN%usenet@oakseed.demon.co.uk.invalid>
Tad McClellan <tadmc@augustmail.com> wrote:
> James Taylor <usenet@oakseed.demon.co.uk.invalid> wrote:
>
> > Can anyone put my mind at ease that the design of Perl is sensible, as
> > described in the first paragraph, and not broken as described in the
> > second paragraph? Thanks.
>
>
> The "Newlines" section in perlport has this handy table:
>
> | Unix | DOS | Mac |
> ---------------------------
> \n | LF | LF | CR |
> \r | CR | CR | LF |
> \n * | LF | CRLF | CR |
> \r * | CR | CR | LF |
> ---------------------------
> * text-mode STDIO
Oh that is handy, thanks.
> Does that ease your mind?
No, sadly, it only confirms the worst, that Classic MacPerl is duff
because it mucks about with the meaning of \n and \r within the program
not just at the IO level.
> Or are we only more confused because it hasn't been updated (has it?)
> for Classic vs. OS X?
I assume everyone who needs to know already knows that $^O eq 'darwin'
is a unix like environment.
--
James Taylor
------------------------------
Date: Sun, 12 Feb 2006 21:18:03 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <459jhnF5jmqdU1@individual.net>
Tad McClellan wrote:
>>Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>>>Wes Groleau wrote:
>>>>BBEdit defaults to old-style linebreaks (\r)
>>>>so the kernel treated the entire file as the shell command,
>>>>leaving perl nothing to execute.
>>>
>>>I'm not a Mac user, but I thought that \r does represent a newline on
>>>Mac, at least according to "perldoc perlport".
>
> I cannot find that anywhere in perlport.
>
> What specific wording did you see that led to that conclusion?
Well, I guess it was the sentence: "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." However, there were (at least) two
mistakes embedded in my remark.
1) I wasn't aware of the fact that Mac OS X is a Unix based OS.
2) Based on the incorrect assumption that we were talking about Mac
Classic, and assuming that Wes actually meant that BBEdit uses \015 by
default as the newline character, I meant to say that the OS should have
recognized \015 as a newline char.
My apologies for any confusion my remark may have caused. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 12 Feb 2006 16:22:10 -0500
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <8GNHf.2477$cq4.1158@fe09.lga>
James Taylor wrote:
> John W. Kennedy <jwkenne@attglobal.net> wrote:
>
>> James Taylor wrote:
>>
>>> Surely, the point of \n is that it represents a newline on *any*
>>> platform. MacOS X is (NextStep/BSD unix) so newlines are linefeeds like
>>> any other sensible operating system. Classic MacOS used carriage returns
>>> as newline markers. It was my understanding that the difference between
>>> binmode and err... "textmode" was that textmode performed the
>>> translation of newline chars so that the Perl programmer didn't have to
>>> concern himself with this issue. The Perl programmer could just read a
>>> text file and then be able to use \n to refer to newlines within the
>>> data in memory whether it had come from a file or anywhere else. So \n
>>> and \r retain their traditional C style meaning within Perl programs
>>> regardless of what the external OS happens to use in text files.
>>>
>>> At least, that's how it *should* be, but I have a nagging feeling I
>>> overheard people on this group describing it quite differently. The way
>>> they described it was that, instead of the abstraction being in the file
>>> IO layer, the meaning of \n and \r would change depending on the
>>> operating system that the Perl program was running on. Yeuck! That's
>>> clearly a portability maintenance disaster, and if this is really the
>>> case, you'd end up having to avoid the broken \n and \r in favour of
>>> \x0a and \x0d, not to mention spending a good deal of you time hunting
>>> down bugs caused by the assumption that \n was a linefeed and \r a
>>> carriage return.
>>>
>>> Can anyone put my mind at ease that the design of Perl is sensible, as
>>> described in the first paragraph, and not broken as described in the
>>> second paragraph? Thanks.
>> This seems confused.
>>
>> "\n" is always \x0A or \u000A in RAM. (Unless, perhaps, on EBCDIC.)
>>
>> "\r" is always \x0D or \u000A in RAM. (Unless, perhaps, on EBCDIC.)
>
> I assume you mean \u000D there.
Yes.
>> The file system, properly speaking, is always neutral.
>>
>> But the file functions/methods of various compilers/libraries, in text
>> mode, may translate inbound \x0D0A (DOS-Windows-OS/2) or \x0D (MacOS
>> Classic) into \x0A, and outbound \x0A into \x0D0A (DOS-Windows-OS/2) or
>> \x0D (MacOS Classic) into \x0D. (On IBM mainframes, file-system record
>> boundaries are used similarly.)
>
> That's exactly what I would expect, and is exactly what I described in
> my first paragraph. Which bit of my first paragraph did you think was
> saying something different?
You were winding through enough alternatives that I wasn't sure where
you had settled down.
> I don't see why this area confuses people so much because it really just
> boils down to where the abstraction takes place: It's either at the file
> i/o layer, or by mucking about with \n. Clearly the former would be
> sensible and the latter would be crazy. However, I've seen the
> luminaries of this group claim that \n does not mean linefeed on all
> platforms and that it is therefore necessary to use \x0A or similar if
> you want to be sure you're creating or matching a real linefeed rather
> than whatever the local newline marker is. If it really is true that
> some idiot porter decided to muck about with the meaning of \n instead
> of abstracting the translation to the file i/o layer, then the result is
> that we should all stop using \n throughout our code unless we know for
> sure that we want a character sequence that changes according to the
> platform our code happens to be running on.
It is necessary to use \x0A instead of \n only when working in a
non-ASCII-based coding (which, nowadays, is pretty much limited to
EBCDIC), and you absolutely, positively want the binary value \x0A as such.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
------------------------------
Date: 12 Feb 2006 16:48:17 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
Message-Id: <dsnosh$sa6$2@mamenchi.zrz.TU-Berlin.DE>
brian d foy <brian.d.foy@gmail.com> wrote in comp.lang.perl.misc:
> In article <vxaHf.458$Eq.141@trnddc02>, Jürgen Exner
> <jurgenex@hotmail.com> wrote:
>
> > PerlFAQ Server wrote:
> > [...]
> > > --------------------------------------------------------------------
> > >
> > > 4.18: Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
> >
> > By now the new Millenium is 5 years old. Isn't it time to retire this entry?
>
> It could probably be retired, but it isn't do much harm for the moment.
> Maybe I should just come up with a better title, such as "How does Perl
> handle year values?" or something similar.
I like the way the FAQ, in its oblique way, conserves some of the history of
the community. I think it's a good thing that FAQ articles don't easily go.
Anno
--
$_='Just another Perl hacker'; print +( join( '', map { eval $_; $@ }
'use warnings FATAL => "all"; printf "%-1s", "\n"', 'use strict; a',
'use warnings FATAL => "all"; "@x"', '1->m') =~
m|${ s/(.)/($1).*/g; \ $_ }|is),',';
------------------------------
Date: Sun, 12 Feb 2006 14:32:02 -0500
From: "Patrick M. Rutkowski" <rutski89@gmail.com>
Subject: Re: Perl vs. Python
Message-Id: <T2MHf.2463$cq4.2164@fe09.lga>
Emmanuel Florac wrote:
> Le Sat, 11 Feb 2006 21:44:14 +0000, Abigail a écrit :
>
>> You mean both Bush and Osama Bin Laden get their orders from the
>> same god?
>
> Yes. Isn't it a nice hint there isn't any god after all ? :)
>
I think it's just a nice hint that neither Bush nor Bin Laden know what
they're doing.
------------------------------
Date: 12 Feb 2006 18:59:28 -0200
From: io <io@localhost.localdomain>
Subject: Re: Perl vs. Python
Message-Id: <87bqxc2szz.fsf@localhost.localdomain>
Bart Lateur <bart.lateur@pandora.be> writes:
> Patrick M. Rutkowski wrote:
>
> >I'm currently learning Perl from the Camel Book and I'm totally loving
> >it. I did stumble upon this article though, and I wanted to know if you
> >guys on c.l.p.misc agree with Eric's views:
> >
> >http://www.linuxjournal.com/article/3882
>
> So, apparently, Eric S. Raymond isn't totally comfortable with Perl, and
> his discomfort grows with program size, so he says.
>
> He's equally discomfortable with Python, actually, a lot of his grudges
I'm new to Perl. Perl isn't easy, but from what I'm reading in Object
Oriented Perl, Higher Order Programming With Perl, and Advanced Perl
Programming, it doesn't look to me as if Eric Raymond fully groks
Perl. I think his assessment is very limited. It seems so far that
you can do a whole lot more with Perl in terms of advanced features
without modifying the compiler, like the Python guys. Perl is just
that flexible.
However, those books deal with advanced stuff, and to be frank, I'm
more used to seeing Smalltalkers and Lispers immerse themselves in
those issues than your average Java or Python programmer.
I would also add Bruce Eckel to the list of people who
don't really know what their talking about. Perl, it looks from
Conway's book, has a perfectly capable, sane and flexible object
system.
Cheers.
------------------------------
Date: Sun, 12 Feb 2006 23:59:29 +0100
From: Emmanuel Florac <eflorac@imaginet.fr>
Subject: Re: Perl vs. Python
Message-Id: <pan.2006.02.12.22.59.29.753309@imaginet.fr>
Le Sun, 12 Feb 2006 14:32:02 -0500, Patrick M. Rutkowski a écrit :
>
> I think it's just a nice hint that neither Bush nor Bin Laden know what
> they're doing.
Come on... D'you mean... ? Nooooo... :)
--
entia non sont multiplicanda praeter necessitatem.
John Ponce of Cork.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8946
***************************************
