[22902] in Perl-Users-Digest
Perl-Users Digest, Issue: 5122 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 14 14:10:33 2003
Date: Sat, 14 Jun 2003 11:10:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 14 Jun 2003 Volume: 10 Number: 5122
Today's topics:
rename to existing filename? <notspam@spamfree.dud>
Re: rename to existing filename? <ndronen@io.frii.com>
Re: rename to existing filename? <mbudash@sonic.net>
Re: rename to existing filename? <notspam@spamfree.dud>
Re: request in print<<test; (Tad McClellan)
Re: require specific version as opposed to > than versi <eric-amick@comcast.net>
Re: Search through Array and evaluate the two <jkeen@concentric.net>
Re: Search through Array and evaluate the two <jkeen@concentric.net>
Re: setOutput in Perl (big__smile)
Re: Tad McClellan <nobody@dev.null>
Re: Tad McClellan <flavell@mail.cern.ch>
Re: Tad McClellan <jurgenex@hotmail.com>
Re: Tad McClellan (Tad McClellan)
Re: Tad McClellan <jkeen@concentric.net>
Re: Tad McClellan <wsegrave@mindspring.com>
Re: Tad McClellan (Sam Holden)
Re: variables printed are the same yet fail equality te <flavell@mail.cern.ch>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 14 Jun 2003 13:35:18 GMT
From: Sean O'Dwyer <notspam@spamfree.dud>
Subject: rename to existing filename?
Message-Id: <notspam-F65EC6.09351814062003@syrcnyrdrs-03-ge0.nyroc.rr.com>
Hello,
I have a largeish database file (20,000 records) that needs to be acted
on and altered by the contents of a Web form.
My problem is that the client sometimes clicks the PROCESS button on the
Web form more than once, calling the processing script several times and
acting on the database severally and concurrently. Very bad.
My script used to be...
#get a copy of entire database
open(READLEEDZ,"<thedata/leedz$file_name_tag.txt");
@extantleads=<READLEEDZ>;
close(READLEEDZ);
#then get working on database and write the whole thing back when done
I'm thinking of changing it to...
#get a copy of entire database
open(READLEEDZ,"<thedata/leedz$file_name_tag.txt") or die "Couldn't find
database. Process already underway. Try again in a couple of seconds.";
@extantleads=<READLEEDZ>;
close(READLEEDZ);
#rename current file to .bak so new processes can't find it
rename("thedata/leedz$file_name_tag.txt",
"thedata/leedz$file_name_tag.bak");
I know this is a kludge and not good procedure. I wrote the original
scripts a couple of years ago when I was learning/cutting teeth, and
don't have time now to go back and do a major overhaul. Just need
something that works.
So my question is (and thanks for reading this far): what happens if I
rename a file to a filename that already exists. Is the previous .bak
file simply overwritten? That would be fine. Or does it cause problems,
in which case I should be sure to unlink the .bak file at the end of my
script.
Thanks in advance,
Sean
------------------------------
Date: 14 Jun 2003 14:24:39 GMT
From: Nicholas Dronen <ndronen@io.frii.com>
Subject: Re: rename to existing filename?
Message-Id: <3eeb3027$0$202$75868355@news.frii.net>
Sean O'Dwyer <notspam@spamfree.dud> wrote:
SOD> Hello,
SOD> I have a largeish database file (20,000 records) that needs to be acted
SOD> on and altered by the contents of a Web form.
SOD> My problem is that the client sometimes clicks the PROCESS button on the
SOD> Web form more than once, calling the processing script several times and
SOD> acting on the database severally and concurrently. Very bad.
SOD> My script used to be...
SOD> #get a copy of entire database
SOD> open(READLEEDZ,"<thedata/leedz$file_name_tag.txt");
SOD> @extantleads=<READLEEDZ>;
SOD> close(READLEEDZ);
SOD> #then get working on database and write the whole thing back when done
SOD> I'm thinking of changing it to...
SOD> #get a copy of entire database
SOD> open(READLEEDZ,"<thedata/leedz$file_name_tag.txt") or die "Couldn't find
SOD> database. Process already underway. Try again in a couple of seconds.";
SOD> @extantleads=<READLEEDZ>;
SOD> close(READLEEDZ);
SOD> #rename current file to .bak so new processes can't find it
SOD> rename("thedata/leedz$file_name_tag.txt",
SOD> "thedata/leedz$file_name_tag.bak");
SOD> I know this is a kludge and not good procedure. I wrote the original
SOD> scripts a couple of years ago when I was learning/cutting teeth, and
SOD> don't have time now to go back and do a major overhaul. Just need
SOD> something that works.
Why not use flock?
SOD> So my question is (and thanks for reading this far): what happens if I
SOD> rename a file to a filename that already exists. Is the previous .bak
SOD> file simply overwritten? That would be fine. Or does it cause problems,
SOD> in which case I should be sure to unlink the .bak file at the end of my
SOD> script.
A directory is (on UNIXy systems, at least) is a set of name-inode
pairs that refer to its child files and directories. When you
rename a file and leave it in the same directory, the name in that
file's name-inode pair changes. That's all. If you rename a file
"into" a different directory, the name-inode pair is removed from
its former parent and added to its new parent. You can't rename(2)
something from one filesystem to another; utilities like mv(1) work
around this for you by performing a copy.
In your case, the second time an impatient user clicks the 'process'
button, "leez$file_name_tag.txt" will usually (not always) have
been renamed to "leedz$file_name_tag.bak" so the open will fail.
The problem with your approach is that it doesn't really solve the
problem. If there's enough of a delay between the open() and the
rename(), a user can click 'process' and re-open() the file.
Look into a locking mechanism like flock.
Regards,
Nicholas
--
"Why shouldn't I top-post?" http://www.aglami.com/tpfaq.html
"Meanings are another story." http://www.ifas.org/wa/glossolalia.html
------------------------------
Date: Sat, 14 Jun 2003 16:14:38 GMT
From: Michael Budash <mbudash@sonic.net>
Subject: Re: rename to existing filename?
Message-Id: <mbudash-C96FE7.09143914062003@typhoon.sonic.net>
In article <3eeb3027$0$202$75868355@news.frii.net>,
Nicholas Dronen <ndronen@io.frii.com> wrote:
> Sean O'Dwyer <notspam@spamfree.dud> wrote:
> SOD> Hello,
>
> SOD> I have a largeish database file (20,000 records) that needs to be acted
> SOD> on and altered by the contents of a Web form.
>
> SOD> My problem is that the client sometimes clicks the PROCESS button on the
> SOD> Web form more than once, calling the processing script several times and
> SOD> acting on the database severally and concurrently. Very bad.
>
> SOD> My script used to be...
>
> SOD> #get a copy of entire database
> SOD> open(READLEEDZ,"<thedata/leedz$file_name_tag.txt");
> SOD> @extantleads=<READLEEDZ>;
> SOD> close(READLEEDZ);
> SOD> #then get working on database and write the whole thing back when done
>
> SOD> I'm thinking of changing it to...
>
> SOD> #get a copy of entire database
> SOD> open(READLEEDZ,"<thedata/leedz$file_name_tag.txt") or die "Couldn't find
> SOD> database. Process already underway. Try again in a couple of seconds.";
> SOD> @extantleads=<READLEEDZ>;
> SOD> close(READLEEDZ);
>
> SOD> #rename current file to .bak so new processes can't find it
> SOD> rename("thedata/leedz$file_name_tag.txt",
> SOD> "thedata/leedz$file_name_tag.bak");
>
> SOD> I know this is a kludge and not good procedure. I wrote the original
> SOD> scripts a couple of years ago when I was learning/cutting teeth, and
> SOD> don't have time now to go back and do a major overhaul. Just need
> SOD> something that works.
>
[snip]
>
> The problem with your approach is that it doesn't really solve the
> problem. If there's enough of a delay between the open() and the
> rename(), a user can click 'process' and re-open() the file.
>
> Look into a locking mechanism like flock.
good suggestion. try something like this:
#----------------------------------------
use Fcntl qw/:flock/;
open (READLEEDZ,"<thedata/leedz$file_name_tag.txt") || die ("Cant open
READLEEDZ: $!");
# lock it up exclusively
flock (READLEEDZ, LOCK_EX);
# rewind
seek (READLEEDZ, 0, 0);
# slurp!
@extantleads = <READLEEDZ>;
# rewind again in preparation for clearing
seek (READLEEDZ, 0, 0);
# clear the file
truncate (READLEEDZ, 0);
# now process the records as necessary
foreach (@extantleads) {
# whatever
}
# write back the remaining records. be sure that each record has
# a newline at its end!
print READLEEDZ @extantleads;
# we're outa here. (note that perl's close also unlocks the file,
# as does the ending of the program, so an explicit flock is n/n
close (READLEEDZ);
#----------------------------------------
hth-
--
Michael Budash
------------------------------
Date: Sat, 14 Jun 2003 17:46:32 GMT
From: Sean O'Dwyer <notspam@spamfree.dud>
Subject: Re: rename to existing filename?
Message-Id: <notspam-75971C.13463214062003@syrcnyrdrs-03-ge0.nyroc.rr.com>
In article <mbudash-C96FE7.09143914062003@typhoon.sonic.net>,
Michael Budash <mbudash@sonic.net> wrote:
> > The problem with your approach is that it doesn't really solve the
> > problem. If there's enough of a delay between the open() and the
> > rename(), a user can click 'process' and re-open() the file.
> >
> > Look into a locking mechanism like flock.
>
> good suggestion. try something like this:
>
> #----------------------------------------
> use Fcntl qw/:flock/;
>
> open (READLEEDZ,"<thedata/leedz$file_name_tag.txt") || die ("Cant open
> READLEEDZ: $!");
>
> # lock it up exclusively
> flock (READLEEDZ, LOCK_EX);
>
> # rewind
> seek (READLEEDZ, 0, 0);
>
> # slurp!
> @extantleads = <READLEEDZ>;
>
> # rewind again in preparation for clearing
> seek (READLEEDZ, 0, 0);
>
> # clear the file
> truncate (READLEEDZ, 0);
>
> # now process the records as necessary
> foreach (@extantleads) {
> # whatever
> }
>
> # write back the remaining records. be sure that each record has
> # a newline at its end!
> print READLEEDZ @extantleads;
>
> # we're outa here. (note that perl's close also unlocks the file,
> # as does the ending of the program, so an explicit flock is n/n
> close (READLEEDZ);
> #----------------------------------------
Thank you both, this is extremely helpful. I've been intimidated by
flock but this clears a couple of things up for me.
Kind regards,
Sean
------------------------------
Date: Fri, 13 Jun 2003 18:40:41 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: request in print<<test;
Message-Id: <slrnbeko7p.6c5.tadmc@magna.augustmail.com>
GhostNr1 <ghostnr1@telia.com> wrote:
> I use CGI.pm and do a request like $q->param('test') and I need to put it in
[snip a double-quotish string]
Your Question is Asked Frequently:
How do I expand function calls in a string?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 14 Jun 2003 13:06:07 -0400
From: Eric Amick <eric-amick@comcast.net>
Subject: Re: require specific version as opposed to > than version
Message-Id: <ndlmevghgp0i38ghnq9rhb046beupne068@4ax.com>
On Fri, 13 Jun 2003 20:59:36 GMT, ktom <abc@nowhere.com> wrote:
>we would place the following command in our perl file to use the module
>info.
>
>use SomeModule 1.23;
>
>which according to the docs indicates that the module $VERSION must be
>1.23 or greater.
>
>what if i want it to use ONLY 1.23, not greater, not lessor?
There's a module called "only" on CPAN that will do the job, and quite a
bit more in fact.
--
Eric Amick
Columbia, MD
------------------------------
Date: 14 Jun 2003 15:46:40 GMT
From: "James E Keenan" <jkeen@concentric.net>
Subject: Re: Search through Array and evaluate the two
Message-Id: <bcfg10$99g@dispatch.concentric.net>
"Martien Verbruggen" <mgjv@tradingpost.com.au> wrote in message
news:slrnbeinou.luq.mgjv@verbruggen.comdyn.com.au...
> On 13 Jun 2003 03:54:34 GMT,
> Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
> [snip]
> > Seriously, though, what do you mean by "print out the hash"?
> > Extrapolate it in a double-quoted context?
>
> This is, of course, not possible with a hash. But the question stands.
>
I simply meant it to be shorthand for the code with which I concluded my
original posting:
foreach (sort keys %seenlast) {
print "Element: $_\tLast seen at index: $seenlast{$_}\n";
}
------------------------------
Date: 14 Jun 2003 16:16:59 GMT
From: "James E Keenan" <jkeen@concentric.net>
Subject: Re: Search through Array and evaluate the two
Message-Id: <bcfhpr$99j@dispatch.concentric.net>
"Martien Verbruggen" <mgjv@tradingpost.com.au> wrote in message
news:slrnbeiint.luq.mgjv@verbruggen.comdyn.com.au...
> On 13 Jun 2003 02:37:34 GMT,
> James E Keenan <jkeen@concentric.net> wrote:
> >
> > "Steven Kuo" <skuo@mtwhitney.nsc.com> wrote in message
> > news:Pine.GSO.4.21.0306121312350.23188-100000@mtwhitney.nsc.com...
> >> On 12 Jun 2003, James E Keenan wrote:
> >>
> >> (Snipped) ...
> >> > my @barcodes = qw|alpha beta gamma delta alpha epsilon beta zeta
eta
> >> > theta gamma|;
> >> > my %seenlast = ();
> >> > for (my $i=0; $i<=$#barcodes; $i++) {
> >> > if (defined $seenlast{$barcodes[$i]}) {
> >> > $seenlast{$barcodes[$i]} = $i if $i >
> > $seenlast{$barcodes[$i]};
>
> If you have to deal specifically with undefined values in @barcodes,
> you will have to deal with that. How you deal with it depends on what
> that undefined value means.
>
> The following three methods all end up with the same hash contents:
>
Let's modify the original array assignment to include an 'undef', then test:
my @barcodes = ( 'alpha', 'beta', 'gamma', 'delta', 'alpha',
'epsilon', 'beta', 'zeta', 'eta', 'theta', 'gamma', undef );
sub showhash {
my $ref = shift;
print "\nTest\n";
foreach (sort keys %$ref) {
print "Element: $_\tLast seen at index: ${$ref}{$_}\n";
}
}
> my %seenlast1;
>
> for (my $i=0; $i<=$#barcodes; $i++) {
> if (defined $seenlast1{$barcodes[$i]}) {
> $seenlast1{$barcodes[$i]} = $i if $i > $seenlast1{$barcodes[$i]};
> } else {
> $seenlast1{$barcodes[$i]} = $i;
> }
> }
showhash(\%seenlast1); runs without warnings re uninitialized values
> my %seenlast2;
>
> for (my $i=0; $i < @barcodes; $i++) {
> $seenlast2{$barcodes[$i]} = $i;
> }
>
showhash(\%seenlast2); warns about uninitialized values
> my %seenlast3;
> @seenlast3{@barcodes} = (0 .. $#barcodes);
>
showhash(\%seenlast3); warns about uninitialized values
Avoiding uninitialized values was why I used 'defined' rather than 'exists'.
If you go back to the OP, you'll see that he was populating the array via
calls to a database. I did not have a way of quickly reproducing the whole
of his code on my system, so I wanted to exclude the possibility that his
code might return 'undef' values. That's why I tested for definedness in my
code.
------------------------------
Date: 14 Jun 2003 08:43:22 -0700
From: big__smile@hotmail.com (big__smile)
Subject: Re: setOutput in Perl
Message-Id: <299205ff.0306140743.4ce2f8c1@posting.google.com>
"Janek Schleicher" <bigj@kamelfreund.de> wrote in message news:<pan.2003.06.10.17.24.29.731737@kamelfreund.de>...
> big__smile wrote at Tue, 10 Jun 2003 09:09:13 -0700:
>
> > now the xml output is being directed to another file but when i run
> > the cgi script it displays the xml bit (which i don't wanna c)
> > so i found this function called setOutput in perldoc XML::Writer
> > but i get an error saying that the subroutine is undefined!!
> > i use it on a line by itself
> > setOutput($output);
>
> Well, XML::Writer is object oriented.
> Usually, you would use it as something like
>
> use XML::Writer;
> ...
> my $writer = XML::Writer->new;
> ...
> $writer->setOutput($output);
>
> Have you called in that way or did you simply write
> setOutput($output);
> ? (In that way Perl doesn't know that it has to use the setOutput method
> from XML::Writer and apply it to this specific object)
>
>
> Greetings,
> Janek
Thanx Janek!!
But now i have another problem!
i do not use the setOutput thing but try and redirect the out out to a
file
with the OUTPUT in XML::Writer while creating a new instance of writer
but after that i don't want the file displayed on the browser when i
run my cgi script but somehow i can't get it to leave the file alone
and not dosplay it but continue with the code that follows.
Help appreciated!1
thanx in advance!!
------------------------------
Date: Sat, 14 Jun 2003 13:09:48 GMT
From: Andras Malatinszky <nobody@dev.null>
Subject: Re: Tad McClellan
Message-Id: <3EEB1E48.2080607@dev.null>
Graham Smith wrote:
> I'm sure he knows more about Perl than I do, but it is noticeable how
> singularly unhelpful his comments are.
>
Even if Tad did nothing but post the Posting Guidelines he would be one
of the most singularly helpful contributors on CLPM. They (the
Guidelines) explain how to possibly find the answer to your question
yourself, and if you can't, how to ask your question in a smart way in
order to maximize your chances of getting a useful reply.
If you ask a good question, Tad is often the first to answer it. If you
ask a dumb question, Tad will (quite politely) point out how you can ask
your question in a better way the next time, and often answer it
anyway. If you ask an egregious question, he'll tell you to take a
hike. Some people don't like his corrections, but he makes them because
he wants to prevent CLPM from being overwhelmed by dumb and egregious
questions.
If you find him singularly unhelpful, you can always killfile him. The loss will be yours.
------------------------------
Date: Sat, 14 Jun 2003 14:55:24 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Tad McClellan
Message-Id: <Pine.LNX.4.53.0306141451370.29394@lxplus086.cern.ch>
On Sat, Jun 14, Graham Smith inscribed on the eternal scroll:
> but it is noticeable how
> singularly unhelpful his comments are.
The only noticeable thing to me on this thread is how singularly
little benefit some folks are capable of getting from usenet. As
such, one is bound to ask oneself what point there would be in reading
any further questions or contributions from them.
------------------------------
Date: Sat, 14 Jun 2003 14:14:21 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Tad McClellan
Message-Id: <15GGa.13520$Bw2.478@nwrddc03.gnilink.net>
Graham Smith wrote:
> I'm sure he knows more about Perl than I do, but it is noticeable how
> singularly unhelpful his comments are.
Au contraire, mon amie.
Tad's replies are the pure meat, without any garnishings. That may make them
hard to digest for some, but for those who like to get to the core of things
it makes them delightful.
No unnecessary verbage and almost always smack on target down to the point.
jue
------------------------------
Date: Sat, 14 Jun 2003 09:53:01 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Tad McClellan
Message-Id: <slrnbemdmd.7q0.tadmc@magna.augustmail.com>
Graham Smith <grehom@ntlworld.com> wrote:
> it is noticeable how
> singularly unhelpful his comments are.
You won't notice if you make the appropriate killfile entry.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 14 Jun 2003 15:44:38 GMT
From: "James E Keenan" <jkeen@concentric.net>
Subject: Re: Tad McClellan
Message-Id: <bcfft6$99j@dispatch.concentric.net>
"Graham Smith" <grehom@ntlworld.com> wrote in message
news:98eb7f13.0306140428.5277d5e4@posting.google.com...
> I'm sure he knows more about Perl than I do, but it is noticeable how
> singularly unhelpful his comments are.
Au contraire. While on c.l.p.m. I've been corrected by Tad more frequently
than anyone else -- including once within the last hour! Tad's comments are
... terse, but almost always to the point. Being terse, they don't soften
the blow when you learn the errors of your ways -- but if your ego is
vulnerable you shouldn't be posting on c.l.p.m. in the first place. Tad's
comments force my code to be more precise -- and that has been reflected in
more precise instruction of my own Perl students.
------------------------------
Date: Sat, 14 Jun 2003 11:12:31 -0500
From: "William Alexander Segraves" <wsegrave@mindspring.com>
Subject: Re: Tad McClellan
Message-Id: <bcfjcp$kbp$1@slb6.atl.mindspring.net>
"Graham Smith" <grehom@ntlworld.com> wrote in message
news:98eb7f13.0306140428.5277d5e4@posting.google.com...
> I'm sure he knows more about Perl than I do, but it is noticeable how
> singularly unhelpful his comments are.
Hmm. I had noticed Tad was far more helpful with his commentary. With a
Google Groups search for "perl mcclellan segraves" I found confirmation of
Tad's helpful insights, at least for me.
Thanks, Tad. Keep up the great work.
Bill Segraves
------------------------------
Date: 14 Jun 2003 17:13:15 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: Tad McClellan
Message-Id: <slrnbemlta.vdv.sholden@flexal.cs.usyd.edu.au>
On Sat, 14 Jun 2003 12:17:32 GMT,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Julia" == Julia deSilva <jds@trumpetweb.co.uk> writes:
>
>Julia> I have this impression of you sitting on a white cloud firing
>Julia> thunderbolts down to earth every-so-often, in the form of
>Julia> replies to comp.lang.perl.misc.
>
>Julia> Do you have a life.
>
> When Tad's not operating Stonehenge for me, or teaching one of our
> on-site or open-enrollment classes, he answers questions on
> comp.lang.perl.misc, which is why I offered the position to him in the
> first place. I liked the breadth of his knowledge, and his ability to
> peer into the core of the issue and answer respectfully, both
> essential skills in front of a classroom.
The OP was clearly a case of the pot calling the snow black.
Compare Tad's reply and Julia's reply in this thread :
http://
groups.google.com/groups?threadm=01c2864c%246cb47f00%2488498a90%40gmtoomey
[that should be one line, bu tmy newsreader defeated me]
Which one seems helpful? Which one seems like an unprovoked "thunderbolt"?
Sorry for the reply to this post, and not the original, but the OP went
into the killfile back in November.
--
Sam Holden
------------------------------
Date: Sat, 14 Jun 2003 18:06:14 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: variables printed are the same yet fail equality test
Message-Id: <Pine.LNX.4.53.0306141742250.29394@lxplus086.cern.ch>
On Fri, Jun 13, David Sperling inscribed on the eternal scroll:
> Here is a snippet from the utf-8 text file:
> AJ0001,h1,
> AJ0002,h1,
> AJ0003,h1,
Looks to me to be indistinguishable from us-ascii, so far.
[...]
> If I switch the data in the text file around to h1,AJ0001
> and switch $keys and $value variables around it evaluates true;
This smells distinctly fishy... You _are_ sure that you're not
messing with a trailing newline character???
> Any ideas on how to debug this would be greatly appreciated.
First off, Tad's helpful rules of engagement invite you to include a
minimal test program which we can run for ourselves, and which
demonstrates the effect claimed. Seems to me you've included an
incomplete bunch of subroutines, some of which appear to me to contain
extraneous detail i.e not directly pertinent to the problem; and which
can only be run after we've cobbled-in some test harness of our own.
I'd have to suggest that's a sub-optimal way of going about the task
of trouble-shooting.
[code fragments snipped]
I don't know the answer yet, but I have in mind that at
http://www.perldoc.com/perl5.8.0/pod/perluniintro.html#Perl's-Unicode-Model
it says:
The principle is that Perl tries to keep its data as eight-bit bytes
for as long as possible, but as soon as Unicodeness cannot be
avoided, the data is transparently upgraded to Unicode.
Could it be that you have somehow misled Perl into keeping the one
string in us-ascii while "upgrading" the other to Unicode? I don't
know the answer to your problem yet, but haven't time to repair your
omission of an actual runnable test script which I can use as a
starting point: however, I do take note of this statement in the
documentation:
http://www.perldoc.com/perl5.8.0/pod/perlunicode.html#Effects-of-Character-Semantics
[...]
This behavior preserves compatibility with earlier versions of Perl,
which allowed byte semantics in Perl operations only if none of the
program's inputs were marked as being as source of Unicode character
data. Such data may come from filehandles, from calls to external
programs, from information provided by the system (such as %ENV), or
from literals and constants in the source text.
Could it be that you need "use utf8;" to correct this assumption? It's
only a hunch, but as no-one else seems to have responded yet, this is
my best effort.
cheers
------------------------------
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.
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 5122
***************************************
