[24612] in Perl-Users-Digest
Perl-Users Digest, Issue: 6788 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 10 14:05:36 2004
Date: Sat, 10 Jul 2004 11:05:06 -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, 10 Jul 2004 Volume: 10 Number: 6788
Today's topics:
Re: Bitwise comparison failing (Anno Siegel)
Re: Code Style -- here-docs -- How do you make them loo (MST)
Re: hash as argument <daedalus@videotron.ca>
Re: hash as argument (Anno Siegel)
Re: hash as argument (Anno Siegel)
Re: hash as argument <abigail@abigail.nl>
Re: hash as argument <abigail@abigail.nl>
Re: hash as argument <daedalus@videotron.ca>
Re: how perl set envirment variable <jurgenex@hotmail.com>
Re: how perl set envirment variable <tadmc@augustmail.com>
Re: how perl set envirment variable (J. Romano)
Re: how perl set envirment variable <jurgenex@hotmail.com>
Re: how perl set envirment variable <mdl@hvc.rr.com>
Re: how perl set envirment variable <1usa@llenroc.ude>
Re: Negation of RegEx (Dan)
Re: Regexp substitution problem - suggestions? <jhalbrook@bjc.org>
Re: Regexp substitution problem - suggestions? <1usa@llenroc.ude>
Re: Regexp substitution problem - suggestions? <noreply@gunnar.cc>
Re: why utf8::upgrade is needed? <pajas@ufal.ms.mff.cuni.cz>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 10 Jul 2004 15:09:55 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Bitwise comparison failing
Message-Id: <ccp0s3$3b1$1@mamenchi.zrz.TU-Berlin.DE>
corky <twistdpair@hotmail.com> wrote in comp.lang.perl.misc:
> I have a function that manages security for various hyperlinks on the
> web. Each user has an integer representation of a binary number (24
> security on/off switches) stored in the database. Each link has a link
> ID associated. This function takes the link ID, looks through a list
> of restricted link ID / security pairs, and denies the user access to
> a link if there is a match.
>
> For instance, GetLinkSecurity (2, <user's security mask as integer>)
> would pass the function a link ID of 2 and the user's security mask.
> The function then looks through the list of link ID / security bit
> pairs to see if the user should be denied access.
>
> The problems started when I added a new security bit with an integer
> value of 8388608 (24 bits). The function stopped working properly for
> users with that security bit turned on.
What does that mean? Explain what you expect to happen when it's
"working properly" and show what is happening instead.
> I don't know if it's some
> overflow condition or something, and I can't find any reference to
> capacity in the camel book.
>
> I'm not a regular Perl programmer, so please forgive me if the
> question is basic.
The problem with the question is not that it's basic, but that we don't
know what the question is.
When I run your code below, it does exactly what I'd expect it to do.
The call
GetLinkSecurity( 2, 8388608)
returns 1 with the given data. That is okay, because none of the masks
has the corresponding bit set. Adding a line "2 838860" to the
data makes the same call return 0, okay again.
Do you see a different behavior? Or is this behavior not what you
expect? Please explain.
Anno
[code for reference]
> The function follows:
>
> sub GetLinkSecurity {
> &LogItem("--> GetLinkSecurity()");
> my ($link, $knowrights) = @_;
> my ($linknum, $badright);
> my ($secflag) = 1;
> open(LINKSEC, "linksec.txt");
> while(<LINKSEC>){
> chomp;
> ($linknum, $badright) = split;
> if ($linknum == $link) {
> if (($knowrights & $badright) == $badright) {
> $secflag = 0;
> }
> }
> }
> close LINKSEC;
> return($secflag);
> }
>
> Here is a sample of data in the linksec.txt file:
>
> 1 8
> 1 131072
> 1 524288
> 2 8
> 2 131072
> 2 524288
> 3 8
> 3 131072
> 3 524288
> 4 8
> 4 131072
> 4 524288
> 5 8
> 5 131072
> 5 524288
> 6 8
> 6 131072
> 6 524288
>
> Thanks,
>
> Corky
------------------------------
Date: 10 Jul 2004 10:10:48 -0700
From: mst@fiftyvolts.com (MST)
Subject: Re: Code Style -- here-docs -- How do you make them look good?
Message-Id: <ec46364f.0407100910.2346bf2@posting.google.com>
Thanks for the advice, as I said I'm not usually treading in CGI land
so my CGI programming style is style being worked out. I didn't
realize that the quote like operators were ok with embedded newlines;
I guess you learn something new every day :)
------------------------------
Date: Sat, 10 Jul 2004 09:59:43 -0400
From: "Daedalus" <daedalus@videotron.ca>
Subject: Re: hash as argument
Message-Id: <BASHc.66502$_p5.1376590@wagner.videotron.net>
> > %% > that there's no interpolation. To me their uses are a matter of
choice. But
> > %% > saying "misuse of double-quotes" or ask to "fix" the thing... Do it
because
> > %% > the majority is doing it, thats not a rule of perl.
> > %%
> > %% It is a more general rule of human interaction. It is often useful
> > %% to do things in one, agreed-upon way, even if there is no rational
> > %% reason why that particular way should be preferred. Traffic
regulations
> > %% (beginning with the side of the road you drive on) are often quite
> > %% arbitrary, but the advantages of adhering to them are obvious.
> >
> > I get the traffic story. Traffic rules are good because there are many
> > people on the road at once, each driving a potentially lethal weapon.
> > I don't come across hundreds of other programmers whose editors could
> > harm me when I write a program.
>
> The consequences of violating a traffic rule are obviously more dire than
> disregarding a programming convention, but that isn't the point of the
> comparison. The point is that the rules are basically arbitrary, but
> it is still preferable to have a rule to having none. Folklore about
> the sword-hand side aside, there is no intrinsic advantage in driving
> on the right side over driving on the left. There is still a distinct
> advantage to agreeing on one or the other. Knowing what to expect
> makes assessment of situations easier. That goes for single/double
> quoting as well.
You should think of quoting more like the highway traffic. There's more than
one way for the same direction. You can choose the one you want, unless you
have reasons that gives you no choice.
I agree with you about conventions, where it's necessary, but seriously
quoting don't need convention. And I'm sure that if some people decided that
the convention was the opposite (double-quotes everywhere it doesn't matter)
you would not agree and you would still use your style and argue about it.
People usualy choose the style that best suits there way of thinking and
working.
And I respect that.
DAE
------------------------------
Date: 10 Jul 2004 14:19:40 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: hash as argument
Message-Id: <ccotts$1na$1@mamenchi.zrz.TU-Berlin.DE>
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach Anno Siegel:
>
> > Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> >> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMCMLXV
> >> September MCMXCIII in <URL:news:ccm3tf$9ra$1@mamenchi.zrz.TU-Berlin.DE>:
>
> [ quoting conventions ]
>
> >> %% Similarly, for a programming community, there are advantages in having
> >> %% conventional preferences for one style over another when technically
> >> %% two (or more) ways would give the same result. By using the conventional
> >> %% style, the author tells the reader "Nothing to see here, move along...".
> >> %% A deviation from the standard tells the reader to look for the reason.
> >> %% That makes such code a lot easier to read.
> >>
> >> The "conventional style"? Are you now claiming that whatever style you
> >> are defending is "conventional" and that the others are "deviating"?
> >> That's quite presumptuous.
> >
> > Presumptuous or not, that's the way a new convention propagates.
> > Deliberately or unconsciously, some people publicly act as if it were
> > already in place. If enough people follow suit, it becomes so.
> >
> > Clpm is one of the places where this process happens.
>
> Just for the record, I'd like to note that this process hasn't yet
> started to happen for me. On the quote issue, I decide from case to
> case. Usually, when I have characters that require escaping in a
> double-quotish context, I use single quotes. When I have something
> to interpolate, I use double ones, even if that requires one or the
> other backspace. Once the amount of backspacing gets annoying, I start
> using heredocs or maybe 'qq'.
s/space/slash/
As long as you *have* reason to prefer one or another quoting mechanism,
there is no need for a convention. The convention comes in when other
criteria are absent.
> I'd say that this quoting issue is too minor to require a convention on
> it. I do agree that conventions and rules are invaluable. That however
> wont hold true for any convention. Now, getting slightly political, when
> I think about the vast amount of bills we have in Germany, I'd really
> say that having fewer of those would be a relief for anyone involved.
Also, was das betrifft... uh, err, never mind.
Now, programming conventions aren't laws that bind you no matter what.
As a programmer, they help me decide what to do in an ambiguous situation,
and help me be consistent about it.
Anecdotally, as an occasional C programmer, the ambiguity of pointer-
and array notation gives me pause each time it comes up, because I don't
have a clear preference. I wish there was a convention...
As a program reader, ideally the programmer uses the same set of
conventions I do, but a different set of conventions is also useful
if consistently applied.
> This group already has quite a few rules, such as using
> strictures, warnings, checking the success of system-calls, lexical
> scoping where applicable etc. All of those serve a very good purpose.
> It's much less obvious (for me anyway) what purpose quoting-rules could
> have.
Having any rule at all can be better than having none, even if the
specifics of the rule aren't provably superior to possible alternatives.
The side-of-the-road-rule exemplifies this for traffic. So I would like to
see a convention for quotes in programming.
The current leaning seems to be "Single quotes when possible, double when
needed". Preferring single quotes is reader-friendly because they are
easier to parse, but less programmer-friendly because (applied strictly)
it calls for frequent changes of quotes during maintenance. I could
also live with the opposite rule, "Double quotes unless they are positively
unwieldy", but at least among the majority of clpm regulars, reader-
friendliness appears to have won.
The downside of conventions is that they are grist on the mill of
pedants and wannabees. That's part of the cost of having them, I
guess. No free lunch, and all that...
> >> %% Thus, a set of stylistic conventions gives a language a dimension of
> >> %% expressiveness it wouldn't have without it. That is a Good Thing.
> >> %% The preference of '' over "" and of sub() over &sub belong in this
> >> %% category.
> >>
> >> I think they aren't equivalent. 'sub()' is used far more often than
> >> '&sub' - that preference has been settled. I highly doubt that the
> >> preference of '' vs "" has been settled.
> >
> > Then it's time to settle it :)
>
> Just keep in mind how certain people react towards rules they don't
> agree with. I, for instance, tend to do the exact opposite of such
> rules, just for the sake of contradiction and for expressing my grudge.
A stance that is both noble and revolutionary :)
> I am totally aware that this is the mindset of a five-year old, but
> sometimes I really don't mind acting like a child. :-)
Oh, certainly. The adoption and rejection of conventions by a group
happens subconsciously most of the time, and that's how we operate on
that level. It works quite well...
Anno
------------------------------
Date: 10 Jul 2004 14:45:42 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: hash as argument
Message-Id: <ccovem$2kb$1@mamenchi.zrz.TU-Berlin.DE>
Daedalus <daedalus@videotron.ca> wrote in comp.lang.perl.misc:
[quoting conventions]
> You should think of quoting more like the highway traffic. There's more than
> one way for the same direction. You can choose the one you want, unless you
> have reasons that gives you no choice.
Conventions are there to make a choice when other criteria are absent.
For the programmer they make the choice easier, without groping for
reasons where there are none. For the reader, the choice becomes
predictable.
> I agree with you about conventions, where it's necessary, but seriously
> quoting don't need convention.
The need for a convention hinges on how often ambiguous situations come
up. The choice of "" or '' is arbitrary often enough for a default to
be useful.
> And I'm sure that if some people decided that
> the convention was the opposite (double-quotes everywhere it doesn't matter)
> you would not agree and you would still use your style and argue about it.
> People usualy choose the style that best suits there way of thinking and
> working.
I believe you're wrong there. If there was serious agreement among
Perl programmers to use double quotes whenever possible, I would adapt,
at least in published code on clpm and the CPAN, and then, for simplicity,
in all code of some substance.
Then again, you don't have to follow every convention on every occasion.
Some functions are more formal than others :)
Anno
------------------------------
Date: 10 Jul 2004 16:33:29 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: hash as argument
Message-Id: <slrncf06io.4g9.abigail@alexandra.abigail.nl>
Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMCMLXVI
September MCMXCIII in <URL:news:ccotts$1na$1@mamenchi.zrz.TU-Berlin.DE>:
**
** The current leaning seems to be "Single quotes when possible, double when
** needed". Preferring single quotes is reader-friendly because they are
** easier to parse, but less programmer-friendly because (applied strictly)
** it calls for frequent changes of quotes during maintenance. I could
** also live with the opposite rule, "Double quotes unless they are positively
** unwieldy", but at least among the majority of clpm regulars, reader-
** friendliness appears to have won.
I think the majority of the clpm regulars have not stated a preference,
only a handful of people did. As for 'readerfriendliness', that too I find
debatable. It may be reader friendly to *you*, because that's what you
are used to. It's not reader friendly to someone with different habits.
And I highly doubt the suggestion that single quoted strings are easier
to parse than double quoted strings. It's not reader friendly towards
those with a C background, for whom 'a' is 97, and not a single character
string. I don't program that often in C, but even I occasionally think
"integer" when seeing a single quoted single character string, instead of
"string".
Abigail
--
BEGIN {$^H {join "" => ("a" .. "z") [8, 13, 19, 4, 6, 4, 17]} = sub
{["", "Just ", "another ", "Perl ", "Hacker\n"] -> [shift]};
$^H = hex join "" => reverse map {int ($_ / 2)} 0 .. 4}
print 1, 2, 3, 4;
------------------------------
Date: 10 Jul 2004 16:35:32 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: hash as argument
Message-Id: <slrncf06mk.4g9.abigail@alexandra.abigail.nl>
Daedalus (daedalus@videotron.ca) wrote on MMMCMLXVI September MCMXCIII in
<URL:news:BASHc.66502$_p5.1376590@wagner.videotron.net>:
::
:: I agree with you about conventions, where it's necessary, but seriously
:: quoting don't need convention.
Here, here! If Larry thought quoting needed a convention, he wouldn't
have given us q and qq.
Abigail
--
:;$:=~s:
-:;another Perl Hacker
:;chop
$:;$:=~y
:;::d;print+Just.
$:;
------------------------------
Date: Sat, 10 Jul 2004 13:18:40 -0400
From: "Daedalus" <daedalus@videotron.ca>
Subject: Re: hash as argument
Message-Id: <5vVHc.71279$_p5.1477273@wagner.videotron.net>
> > > Some more examples of saying that "something special" is going
> > > on when nothing special is going on:
> > >
> > > m/RE/s; # when RE does not contain a dot
> > >
> > > m/RE/m; # when RE does not contain ^ or $ anchors
> > >
> > > printf "%s\n", 'Hello World'; # printf() w/same formatting as
print()
> >
> > It makes me think of one thing. Funny how the perl's default seems to be
the
> > double-quotes-like style. qx//, qw//, m//, s///, qr//, <<EOF.
>
> I think you may have misunderstood how qw// works.
>
Oups, sorry I put this one by mistake. This one have a constant behavior,
like qq// and q//.
But all those that can have both single or double-like behavior are default
to doubles.
DAE
------------------------------
Date: Sat, 10 Jul 2004 13:23:52 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: how perl set envirment variable
Message-Id: <I5SHc.37928$6e7.8453@nwrddc03.gnilink.net>
Ting Wang wrote:
> I want set envirment variable, e.g PATH
> with perl, how can I co it?
Depends on what you want to achive. Please check
- "perldoc perlvar", section about %ENV
- "perldoc -q env"
jue
------------------------------
Date: Sat, 10 Jul 2004 08:19:54 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: how perl set envirment variable
Message-Id: <slrncevr7q.div.tadmc@magna.augustmail.com>
Ting Wang <wangtg@web.de> wrote:
> I want set envirment variable, e.g PATH
> with perl, how can I co it?
$ENV{PATH} = '/bin';
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 10 Jul 2004 07:19:27 -0700
From: jl_post@hotmail.com (J. Romano)
Subject: Re: how perl set envirment variable
Message-Id: <b893f5d4.0407100619.7a09dd66@posting.google.com>
Ting Wang <wangtg@web.de> wrote in message news:<bcabriopame.fsf@marvin.informatik.uni-stuttgart.de>...
> I want set envirment variable, e.g PATH
> with perl, how can I co it?
Dear Ting Wang,
"perldoc -q environment" says that it's almost impossible, but that
there are a few work-arounds, if you are using Unix.
Here's one work-around (for Unix/Linux) that sets your PATH to
"/usr/bin":
#!/usr/bin/perl -w
use strict;
$ENV{PATH} = "/usr/bin";
exec $ENV{SHELL};
__END__
All I did was set the PATH by setting $ENV{PATH}, and then adding
"exec $ENV{SHELL}" as the last line of the Perl script. That way,
your environment changes will "stick" when the Perl script ends.
What is really happening is that a child process was made (that's
why the environment changes stick) so, for every time you run this
Perl script, you have to type an extra "exit" at the prompt when you
want to leave, unless you run the script with the UNIX "exec" command,
like this:
exec script.pl
Keep in mind that these environment changes aren't permanent. Once
you logout or exit your shell you will have to run your script again
to get your changes back.
I hope this helps,
Jean-Luc
------------------------------
Date: Sat, 10 Jul 2004 14:43:05 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: how perl set envirment variable
Message-Id: <ZfTHc.38014$6e7.29474@nwrddc03.gnilink.net>
J. Romano wrote:
> Ting Wang <wangtg@web.de> wrote in message
> news:<bcabriopame.fsf@marvin.informatik.uni-stuttgart.de>...
>> I want set envirment variable, e.g PATH
>> with perl, how can I co it?
>
> "perldoc -q environment" says that it's almost impossible, but that
> there are a few work-arounds, if you are using Unix.
>
> Here's one work-around (for Unix/Linux) that sets your PATH to
> "/usr/bin":
> #!/usr/bin/perl -w
> use strict;
> $ENV{PATH} = "/usr/bin";
> exec $ENV{SHELL};
> __END__
I guess "It works" by some definition of works.
However your approach provides a workaround for only one user scenario, and
a rare scenario for that matter. How often do you really want to open a new
shell? Typically people would rather continue in the given shell.
Not to mention that your approach is utterly useless in batch programming
which is one of the main application areas of Perl.
jue
------------------------------
Date: Sat, 10 Jul 2004 15:08:14 GMT
From: Derek Ludwig <mdl@hvc.rr.com>
Subject: Re: how perl set envirment variable
Message-Id: <pan.2004.07.10.15.08.13.715955@hvc.rr.com>
>> Ting Wang <wangtg@web.de> wrote in message
>> I want set envirment variable, e.g PATH
>> with perl, how can I co it?
>> J. Romano wrote:
>> Here's one work-around (for Unix/Linux) that sets your PATH to
>> "/usr/bin":
>> #!/usr/bin/perl -w
>> use strict;
>> $ENV{PATH} = "/usr/bin";
>> exec $ENV{SHELL};
>> __END__
> Jürgen Exner wrote:
> I guess "It works" by some definition of works.
<SNIP>
> jue
Actually, this shows that you can you can set $ENV{PATH},
and effect subsequent calls to exec, system, etc. If have
had path problems in a batch environment, so I ended up
with the (somewhat cheesy):
use local::Batch::Env;
to set my local environment, including $ENV{PATH}, so
that system does work they way I want. I have to deal
with too many "helpful" people who correct the value
of ${PATH} :-/.
------------------------------
Date: 10 Jul 2004 15:12:12 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: how perl set envirment variable
Message-Id: <Xns952271F924AAasu1cornelledu@132.236.56.8>
jl_post@hotmail.com (J. Romano) wrote in
news:b893f5d4.0407100619.7a09dd66@posting.google.com:
...
> #!/usr/bin/perl -w
> use strict;
> $ENV{PATH} = "/usr/bin";
> exec $ENV{SHELL};
> __END__
>
>
> All I did was set the PATH by setting $ENV{PATH}, and then adding
> "exec $ENV{SHELL}" as the last line of the Perl script. That way,
> your environment changes will "stick" when the Perl script ends.
...
Changes will not stick. You have just invoked a new copy of your shell
with a new environment.
Each time you run this script, a new copy of your shell will run.
Why would you want to do that for something that can be handled much for
easily using your shell's facilities?
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: 10 Jul 2004 10:18:27 -0700
From: dan_yuan@trendmicro.com (Dan)
Subject: Re: Negation of RegEx
Message-Id: <4c135583.0407100918.3669dcdc@posting.google.com>
I think the only way out is build a negation of RegEx.
It is actually a subpatten of a larger regular expression.
can't be any other formats. :-(
Thanks
Dan
Tad McClellan <tadmc@augustmail.com> wrote in message news:<slrnceuana.a05.tadmc@magna.augustmail.com>...
> [ Please learn (and then use) the proper form for a followup posting ]
>
>
> Dan <dan_yuan@trendmicro.com> wrote:
> > Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote in message news:<v3lkcc.us3.ln@goaway.wombat.san-francisco.ca.us>...
> >> On 2004-07-08, Dan <dan_yuan@trendmicro.com> wrote:
> >> > But, I am not allowed to use "!~", I can only use "=~" for this
> >> > problem,
> >>
> >> Why are you not allowed to use !~? Sounds like homework to me.
> >>
> > I will put regular expressions in a script.
> > No sign "!~" or "=~" allowed in there.
>
>
> Why is no "!~" or "=~" allowed in there?
>
> I use them in my "scripts" all the time.
>
>
> If you don't tell us what your real problem is, then we probably
> won't be able to help you solve it...
>
>
> [ snip TOFU ]
------------------------------
Date: Sat, 10 Jul 2004 08:24:25 -0500
From: "Joe Halbrook" <jhalbrook@bjc.org>
Subject: Re: Regexp substitution problem - suggestions?
Message-Id: <10evrgbrqee6208@corp.supernews.com>
Thank you all very much for all this helpful information!
I tried all the tips you've suggested, but just have not been
successful. Not sure why either, as the examples you sent
appear to be exactly what I needed.
The file I was using to test contained the following:
E-mail me at: mailto:inquiries@domain.com
E-mail me at: mailto:inquiries@domain.com.
E-mail me at: mailto:inquiries@domain again.
Try this: mailto:addr@domain.com?Subject=Testing-blues
re: Spam
I hate it as much as the next person.
I assure you that I am NOT in any way, shape, or form trying
to facilitate spamming. Quite to the contrary.
Thanks so much, again.
JK
"Joe Smith" <Joe.Smith@inwap.com> wrote in message
news:asBHc.23693$WX.11118@attbi_s51...
> JK wrote:
>
> > my $parm1 = substr($_,$str,$len);
> > $_ =~ s/$parm1/<a href="$parm1">$parm1<\/a>/ig; # This is the problem
line
>
> You don't need "=~" when working with $_.
> Anytime you have a variable as the first part of s///, you should
carefully
> consider using \Q or \Q and \E around the variable.
>
> s/\Q$parm1/<a href="$parm1">$parm1<\/a>/ig; # Quote specials in $parm1
>
> -Joe
------------------------------
Date: 10 Jul 2004 15:06:20 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: Regexp substitution problem - suggestions?
Message-Id: <Xns952270FAA2587asu1cornelledu@132.236.56.8>
"Joe Halbrook" <jhalbrook@bjc.org> wrote in
news:10evrgbrqee6208@corp.supernews.com:
[ Please do not top-post ]
> The file I was using to test contained the following:
>
> E-mail me at: mailto:inquiries@domain.com
> E-mail me at: mailto:inquiries@domain.com.
> E-mail me at: mailto:inquiries@domain again.
> Try this: mailto:addr@domain.com?Subject=Testing-blues
>
> re: Spam
>
> I hate it as much as the next person.
> I assure you that I am NOT in any way, shape, or form trying
> to facilitate spamming. Quite to the contrary.
Well, now, it looks like you are trying to add addresses from domain.com to
spammers' databases.
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: Sat, 10 Jul 2004 18:03:06 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Regexp substitution problem - suggestions?
Message-Id: <2lai67Fa1k6vU1@uni-berlin.de>
Joe Halbrook wrote:
> I tried all the tips you've suggested, but just have not been
> successful.
Then post a short but complete program that illustrates the problem,
and someone may help you fix it.
I suggest that you read the posting guidelines for this group:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
> re: Spam
>
> I hate it as much as the next person.
> I assure you that I am NOT in any way, shape, or form trying to
> facilitate spamming. Quite to the contrary.
If you publish email addresses on publicly availabe web pages, you
*are* facilitating spamming, whether that's your intention or not.
(Not to mention the point Sinan made.) ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 10 Jul 2004 19:17:35 +0200
From: Petr Pajas <pajas@ufal.ms.mff.cuni.cz>
Subject: Re: why utf8::upgrade is needed?
Message-Id: <ccp86l$284s$1@news.vol.cz>
Alan J. Flavell wrote:
> On Sat, 10 Jul 2004, Petr Pajas wrote:
>
>> \x{168} is non-latin1 Scaron. The code shows, that \x{e1}
>> remains non-UTF8 as long as it meets a non-latin1 character, or
>> utf8::upgrade is called. Can anyone explain why (and possibly
>> how to avoid that)?
>
> To try to answer the question "why", the documentation explains this
> in terms of transparent compatibility with older 8-bit handling.
>
>
http://www.perldoc.com/perl5.8.4/pod/perlunicode.html#Byte-and-Character-Semantics
I see, the answer seems to be here:
"For operations where this determination cannot be made without additional
information from the user, Perl decides in favor of compatibility and
chooses to use byte semantics.
...
"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."
"\x{e1}" is a literal, right? and Perl can't decide between
bytes/characters, therefore I have to upgrade it.
>
> For how to deal with that in practice,
>
>
http://www.perldoc.com/perl5.8.4/pod/perlunicode.html#Forcing-Unicode-in-Perl-(Or-Unforcing-Unicode-in-Perl)
>
> (and the following heading) seem to be particularly relevant.
>
> Maybe I misunderstood what you were saying, but you can't just mark an
> iso-8859-1 string as utf8; it's necessary to cause Perl to genuinely
> create the utf8 version from the 8-bit-coded version.
I know. The problem was, that I thought that there must be some way to
state, that all non-ascii should be treated using character semantics (with
something little more forceful than use utf8). I wanted literals like
"\x{e1}" to be automatically treated as Unicode (character semantics),
since it is non-ASCII (this works for \x{161}, but that's even >255, so
there's no doubt it's character semantics).
Without going into boring details, my situation is as follows: in my
program, the user provides arbitrary Perl expression which I parse using
Text::Balanced. The expression is expected to result in a ascii or UTF8
string (or maybe some other perl object). Due to a reported (and already
fixed) bugs in substr of Perl<=5.8.3, this module fails to handle utf8 code
correctly, so the users are forced to use ASCII code. To insert literal
utf8 data into ascii code, the user has to use \x{...}. After I evaluate
the expression, I'm passing it to a XS module, which is utf8 aware, but
treats non-utf8-flagged non-ascii strings in a specific way. On the other
hand, having a blood-signed treaty with the user on my desk:-), I know that
when he says "\x{e1}", he means characters, not bytes. But, since "\x{e1}"
evaluates as to a non-ascii non-UTF8-flagged string, the modules behaves
incorrectly. So, in order to resolve it, I have to manually force upgrade
at all entry points to the library (hundreds). Other solution would be to
remove the "special treatment" of non-utf8 non-ascii data from the XS
module (being one of the developers I could try to establish that), but
unfortunately, lots of users rely on that behavior.
> As I understand
> it, once the utf8 version has been created it won't be quietly
> destroyed; so if a character > 255 is appended to a string (causing
> upgrade to utf8) and then taken off again, the string will still be
> held in utf8 form, unless one explicitly down-converts it. I'd
> suggest
>
>
http://www.perldoc.com/perl5.8.4/pod/perlunicode.html#Interaction-with-Extensions
>
> in relation to your specific interest.
>
> hope this helps
Yes it does, although the findings didn't make me any happier:-(
Thanks a lot, anyway.
Cheers,
-- Petr
------------------------------
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 6788
***************************************
