[32314] in Perl-Users-Digest
Perl-Users Digest, Issue: 3581 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 4 18:09:26 2012
Date: Wed, 4 Jan 2012 15:09:08 -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 Wed, 4 Jan 2012 Volume: 11 Number: 3581
Today's topics:
how is the string encoded <dn.perl@gmail.com>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <hhr-m@web.de>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <ben@morrow.me.uk>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <dn.perl@gmail.com>
Re: how is the string encoded <hjp-usenet2@hjp.at>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: POD module synopses? (Seymour J.)
Re: POD module synopses? <ben@morrow.me.uk>
Re: POD module synopses? (Seymour J.)
Re: POD module synopses? <ben@morrow.me.uk>
Re: regexp for matching a string with mandatory undersc (Tim McDaniel)
Re: regexp for matching a string with mandatory undersc <rweikusat@mssgmbh.com>
Re: regexp for matching a string with mandatory undersc sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 3 Jan 2012 02:49:04 -0800 (PST)
From: "dn.perl@gmail.com" <dn.perl@gmail.com>
Subject: how is the string encoded
Message-Id: <6c549c5b-599a-4f2c-8b73-09654c0dc092@g19g2000pri.googlegroups.com>
I know the question must have been asked many times, there are many
web-pages which are supposed to help, but after going through many of
them, I still need help.
I am running a simple program on linux, perl 5.8.8 ;
use strict ;
use warnings ;
## use utf8 ;
my $str ;
$str =3D "=E4" ;
print "str is $str\n" ;
---
Works well. But my question is: how do I know which encoding is being
used to read/write $str?
If I uncomment 'use utf8' like, I get a warning: Malformed UTF-8
character. And the string no longer prints correct. Why, and how to
remove this warning, and print the string correctly? I should have
guesses that 'use utf8' adds more power to the code and would not stop
running code which was otherwise running correct.
------------------------------
Date: Tue, 03 Jan 2012 11:06:32 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87boqlgi4n.fsf@sapphire.mobileactivedefense.com>
"dn.perl@gmail.com" <dn.perl@gmail.com> writes:
> I know the question must have been asked many times, there are many
> web-pages which are supposed to help, but after going through many of
> them, I still need help.
> I am running a simple program on linux, perl 5.8.8 ;
>
> use strict ;
> use warnings ;
> ## use utf8 ;
>
> my $str ;
> $str = "ä" ;
> print "str is $str\n" ;
> ---
> Works well. But my question is: how do I know which encoding is being
> used to read/write $str?
According to the people who dabble in this area, you are not supposed
to know that. You are supposed to convert any data flowing into perl
from the encoding known to you into 'the super-secret, proprietary
internal Perl encoding' (patent pending) and any data flowing out of
perl from said 'super-secret internal Perl encoding' into whatever
encoding you'd like to have. Should the encoding you want to use (for
whatever reason) not be among the ones Perl supports natively, you're
fucked and advised to take your petty problems elsewhere. That's the
theory. Practically, Perl uses utf8 (which presumably cause a lot of
people sour bumpers because Microsoft [reportedly] uses UCS-2).
Another practical piece of advice: Stick to ASCII. That's the only
thing no American comittee is going to uninvent tomorrow and thus, a
safe choice for all communication needs among educated people. Let all
those club-bearing natives draw their weird krikel-krakels to their
hearts content and ignore them.
------------------------------
Date: Tue, 3 Jan 2012 13:03:22 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: how is the string encoded
Message-Id: <alpine.LNX.2.00.1201031252250.5279@lxhri01.ws.lrz.de>
On Tue, 3 Jan 2012, Rainer Weikusat wrote:
> "dn.perl@gmail.com" <dn.perl@gmail.com> writes:
> > I know the question must have been asked many times, there are many
> > web-pages which are supposed to help, but after going through many of
> > them, I still need help.
> > I am running a simple program on linux, perl 5.8.8 ;
> >
> > use strict ;
> > use warnings ;
> > ## use utf8 ;
> >
> > my $str ;
> > $str = "ä" ;
> > print "str is $str\n" ;
> > ---
> > Works well. But my question is: how do I know which encoding is being
> > used to read/write $str?
>
> According to the people who dabble in this area, you are not supposed
> to know that. You are supposed to convert any data flowing into perl
> from the encoding known to you into 'the super-secret, proprietary
> internal Perl encoding' (patent pending) and any data flowing out of
> perl from said 'super-secret internal Perl encoding' into whatever
> encoding you'd like to have.
You have to make a difference between the encoding used by *you* while you
are writing your perl program, and the encoding used by *perl* while it is
running your program.
You have to know what *you* are using. The answer has nothing to do with
perl. If you can look at your program in an environment where UTF-8 is
expected and you read it correctly there, then the program is in UTF-8.
Use the "use utf8" to tell perl about it. It has no effect on what the
program does with the strings in it.
For the encoding used by *perl* while it is running your program, Rainer
Weikusat's comment applies. You should not try to know. As long as all
characters in a string are in the ISO-8859-1 character set, it is probable
that ISO-8859-1 is internally used; there is an additional flag in the
internal representation to indicate how the string is internally stored.
Don't mess around with the internal encoding. Rather, *you* have to know
how you meant the string: either as sequence of bytes whose character
meaning only you know, or as a sequence of characters whose encoding as
bytes only perl knows. Do not try to share such knowledge between perl and
you. This is fairly well explained in perlunitut (e.g.
http://search.cpan.org/~flora/perl-5.14.2/pod/perlunitut.pod).
--
Helmut Richter
------------------------------
Date: Tue, 03 Jan 2012 14:22:35 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87y5tokgr8.fsf@sapphire.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Tue, 3 Jan 2012, Rainer Weikusat wrote:
>> "dn.perl@gmail.com" <dn.perl@gmail.com> writes:
>> > I know the question must have been asked many times, there are many
>> > web-pages which are supposed to help, but after going through many of
>> > them, I still need help.
>> > I am running a simple program on linux, perl 5.8.8 ;
>> >
>> > use strict ;
>> > use warnings ;
>> > ## use utf8 ;
>> >
>> > my $str ;
>> > $str = "ä" ;
>> > print "str is $str\n" ;
>> > ---
>> > Works well. But my question is: how do I know which encoding is being
>> > used to read/write $str?
>>
>> According to the people who dabble in this area, you are not supposed
>> to know that. You are supposed to convert any data flowing into perl
>> from the encoding known to you into 'the super-secret, proprietary
>> internal Perl encoding' (patent pending) and any data flowing out of
>> perl from said 'super-secret internal Perl encoding' into whatever
>> encoding you'd like to have.
>
> You have to make a difference between the encoding used by *you* while you
> are writing your perl program, and the encoding used by *perl* while it is
> running your program.
No. The people who *presently* work on Perl unicode support *want*
that users of the language have to pretend that 'the internal perl
encoding' is some magic secret beyond the realm of Perl code *despite*
this is obviously at odds with the original design of 'unicode support
for Perl' and this doesn't make much sense: At the very least, this
requires one additional copy of all data flowing into Perl and one
additional copy of all data going out of Perl. Given that one of the
main uses of Perl is as a so-called 'glue language' interconnection
other pieces of software into a complex whole, this is a major pain in
the ass and this solely for the hypothetical benefit of the people
working on the code. It is hypothetical because there is no way in
heaven or hell that all of the existing Perl code which wasn't written
based on the assumption that Perl strings are magic beasts with
intransigent properties is ever going to be changed just because this
would appeal someone's completely impractical idea of theoretical
purity and the worst possible cause is that - someday - a Perl 5 fork
is created which does break all this code and this will then simply
become Perl 6 rev 0.5 --- something which exists for the private joy
of its developers nobody uses for anything.
------------------------------
Date: Tue, 3 Jan 2012 18:25:10 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how is the string encoded
Message-Id: <6ptbt8-8do.ln1@anubis.morrow.me.uk>
Quoth "dn.perl@gmail.com" <dn.perl@gmail.com>:
>
> I know the question must have been asked many times, there are many
> web-pages which are supposed to help, but after going through many of
> them, I still need help.
> I am running a simple program on linux, perl 5.8.8 ;
That perl is very nearly six years old. You should upgrade to at least
5.12.
> use strict ;
> use warnings ;
> ## use utf8 ;
>
> my $str ;
> $str = "ä" ;
> print "str is $str\n" ;
> ---
> Works well. But my question is: how do I know which encoding is being
> used to read/write $str?
If you don't 'use utf8', perl assumes your source is is ISO8859-1. If
you do, it assumes your source is in UTF-8. (In theory you can use other
encodings with the 'use encoding' pragma, but AIUI this doesn't work
reliably.)
Output is completely unrelated. If you don't do anything special, perl
will give you output in ISO8859-1. This happens *even if* you 'use
uft8': perl doesn't assume your source and your output are necessarily
in the same encoding. If you attempt to print a character which can't be
represented in ISO8859-1 you get a warning and the raw UTF-8 bytes
representing that character: this is obviously something you need to
avoid, since the output doesn't make any sense at that point.
If you want your output in some other encoding, the simplest way is
binmode STDOUT, ":encoding(UTF-8)";
(You can of course use any other encoding there instead.) There are
various shortcuts that acheive the same thing, like the 'open' pragma
and the -C switch, but it's best to stick with being explicit until
you've got the hang of it.
> If I uncomment 'use utf8' like, I get a warning: Malformed UTF-8
> character. And the string no longer prints correct. Why, and how to
> remove this warning, and print the string correctly? I should have
> guesses that 'use utf8' adds more power to the code and would not stop
> running code which was otherwise running correct.
What did you expect to happen? perldoc utf8 quite clearly says
Do not use this pragma for anything else than telling Perl that your
script is written in UTF-8.
so if you 'use utf8' and your source isn't, in fact, *in* UTF-8, you
must expect warnings and misbehaviour.
Ben
------------------------------
Date: Tue, 03 Jan 2012 19:23:21 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87mxa4wpxy.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "dn.perl@gmail.com" <dn.perl@gmail.com>:
>>
>> I know the question must have been asked many times, there are many
>> web-pages which are supposed to help, but after going through many of
>> them, I still need help.
>> I am running a simple program on linux, perl 5.8.8 ;
>
> That perl is very nearly six years old. You should upgrade to at least
> 5.12.
>
>> use strict ;
>> use warnings ;
>> ## use utf8 ;
>>
>> my $str ;
>> $str = "ä" ;
>> print "str is $str\n" ;
>> ---
>> Works well. But my question is: how do I know which encoding is being
>> used to read/write $str?
>
> If you don't 'use utf8', perl assumes your source is is ISO8859-1. If
> you do, it assumes your source is in UTF-8. (In theory you can use other
> encodings with the 'use encoding' pragma, but AIUI this doesn't work
> reliably.)
>
> Output is completely unrelated. If you don't do anything special, perl
> will give you output in ISO8859-1.
This isn't quite correct: It will use 'the native 8 bit encoding' and
this may well be something other than ASCII/ ISO-8859-1, although
that's a case which rarely occurs in practice because most people
don't write code for IBM mainframes :->.
[...]
> If you attempt to print a character which can't be represented in
> ISO8859-1 you get a warning and the raw UTF-8 bytes representing
> that character: this is obviously something you need to avoid, since
> the output doesn't make any sense at that point.
An example I recently encountered where it did make sense was a web
interface with a Japanese localization: Since there were no characters
corresponding with codepoints from (128, 255), the generated output
was simply UTF-8 encoded Japanese which was exactly what it was
supposed to be.
------------------------------
Date: Tue, 3 Jan 2012 23:38:54 -0800 (PST)
From: "dn.perl@gmail.com" <dn.perl@gmail.com>
Subject: Re: how is the string encoded
Message-Id: <9ba45c41-0851-4d77-b84f-457a85eda79f@l24g2000yqm.googlegroups.com>
On Jan 3, 10:25=A0am, Ben Morrow wrote:
>
> That perl (5.8.8) is very nearly six years old. You should
> upgrade to at least 5.12.
>
I wonder whether you realize how difficult (ranging to impossible) it
may be to achieve it. Say, I am on a 3-month contract. The employer
has been managing for years with 5.8.8 and is unlikely to upgrade in
such a case. Once I was stuck with a MySQL server which was many years
old, but my boss was more concerned with preserving his own job than
asking his BOSS to spend time and money on upgrading. Not that the
suggestion to upgrade is wrong or any thing.
>
> If you don't 'use utf8', perl assumes your source is is ISO8859-1. If
> you do, it assumes your source is in UTF-8. (In theory you can use other
> encodings with the 'use encoding' pragma, but AIUI this doesn't work
> reliably.)
> ...
> What did you expect to happen? perldoc utf8 quite clearly says
> =A0 =A0 Do not use this pragma for anything else than telling Perl that y=
our
> =A0 =A0 script is written in UTF-8.
> so if you 'use utf8' and your source isn't, in fact, *in* UTF-8, you
> must expect warnings and misbehaviour.
>
It is very useful to know that perl assumes the source to be
ISO8859-1. That 'use utf8' arguably works counter-intuitively. Since
my code is ASCII and all ASCII is automatically utf8, I tend to wonder
why I would ever write non-ascii code. It may not be a logical thing
to do but I daresay it is an instinctive thing to do. Now if I want to
dabble in utf8 or databases, what do I do? I think of 'use utf8' or
'use DataBaseInterface DBI'.
What I needed was 'use Encode' which is what I am doing now.
Thanks for all the responses.
------------------------------
Date: Wed, 4 Jan 2012 13:05:28 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how is the string encoded
Message-Id: <slrnjg8g49.le4.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
> On Jan 3, 10:25 am, Ben Morrow wrote:
>> That perl (5.8.8) is very nearly six years old. You should
>> upgrade to at least 5.12.
[...]
>> If you don't 'use utf8', perl assumes your source is is ISO8859-1. If
>> you do, it assumes your source is in UTF-8. (In theory you can use other
>> encodings with the 'use encoding' pragma, but AIUI this doesn't work
>> reliably.)
>> ...
>> What did you expect to happen? perldoc utf8 quite clearly says
>> Do not use this pragma for anything else than telling Perl that your
>> script is written in UTF-8.
>> so if you 'use utf8' and your source isn't, in fact, *in* UTF-8, you
>> must expect warnings and misbehaviour.
>>
>
> It is very useful to know that perl assumes the source to be
> ISO8859-1.
This is not quite correct. Without 'use utf8', perl assumes your source
is an unspecified superset of ASCII, not ISO-8859-1. The character codes
are the same, but the semantics are different. For example, if your
script was encoded in ISO-8859-1, "ä" would result in string consisting
of a single byte with the value 0xE4, but that byte is not equivalent to
the character "ä" - it doesn't match \w, [:lower:] or any of the other
classes "LATIN SMALL LETTER A WITH DIAERESIS" should match. It cannot be
uppercased. It is just a meaningless byte, not a character.
> That 'use utf8' arguably works counter-intuitively. Since
> my code is ASCII
No, your code isn't ASCII. It contained the line
| $str = "ä" ;
"ä" is not an ASCII character.
> and all ASCII is automatically utf8, I tend to wonder
> why I would ever write non-ascii code.
Well, why did you?
> What I needed was 'use Encode' which is what I am doing now.
Please don't unless you really understand what it does. Encode does a
couple of different things and it isn't entirely consistent. It seemed
like a good idea at the time and it may have been useful for converting
pre-5.8-code, but I really wouldn't use it for new code.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Wed, 04 Jan 2012 19:22:48 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87lipn46if.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
>> On Jan 3, 10:25 am, Ben Morrow wrote:
>>> That perl (5.8.8) is very nearly six years old. You should
>>> upgrade to at least 5.12.
> [...]
>>> If you don't 'use utf8', perl assumes your source is is ISO8859-1. If
>>> you do, it assumes your source is in UTF-8. (In theory you can use other
>>> encodings with the 'use encoding' pragma, but AIUI this doesn't work
>>> reliably.)
>>> ...
>>> What did you expect to happen? perldoc utf8 quite clearly says
>>> Do not use this pragma for anything else than telling Perl that your
>>> script is written in UTF-8.
>>> so if you 'use utf8' and your source isn't, in fact, *in* UTF-8, you
>>> must expect warnings and misbehaviour.
>>>
>>
>> It is very useful to know that perl assumes the source to be
>> ISO8859-1.
>
> This is not quite correct. Without 'use utf8', perl assumes your source
> is an unspecified superset of ASCII, not ISO-8859-1.
> The character codes are the same, but the semantics are different.
This is also not quite correct: When 'use locale' is in effect, Perl
assumes that anything beyond ASCII is supposed to have a meaning in
the locale which happens to be in effect when the script is
executed. Otherwise, the default is equivalent to the default POSIX
locale (corresponding with LANG=C) which means bytes with value in the
range (0, 127) will be interpreted as ASCII characters belonging to
some of the different characters classes and bytes with values from
(128, 255) are just 'bytes with certain values' and no further
properties.
Eg, assuming the text included below
----------------
$a = chr(0xe4);
{
use locale;
print 'locale: ', $a =~ /\w/, "\n";
}
print 'no locale: ', $a =~ /\w/, "\n";
----------------
is saved to a file on a system where locale-information for ISO-8859-1
based German is available, the command (a.pl being the name of the
file)
LANG=de_DE perl a.pl
will print
locale: 1
no locale:
and
LANG=C perl a.pl
locale:
no locale:
------------------------------
Date: Tue, 03 Jan 2012 11:26:07 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: POD module synopses?
Message-Id: <4f032c1f$4$fuzhry+tra$mr2ice@news.patriot.net>
In <ck3at8-u0i1.ln1@anubis.morrow.me.uk>, on 01/03/2012
at 01:52 AM, Ben Morrow <ben@morrow.me.uk> said:
>I'm not sure what the --believe-pod-name option does,
It causes pod2ipf to use the name from the NAME section rather than
the file name.
>These don't look like module names to me: are you sure they aren't
>actually Pod::Checker and Pod::Escapes?
You're right; they seem to be
Q:\programs\perl\lib\5.10.0\Pod\checker.pm
Q:\programs\perl\lib\5.10.0\Pod\Escapes.pm
I'm not quite sure what is happening; the error message is produced by
print STDERR "\n!!! Not matching: `$_' vs. `$2' in $shortpath
$longname\n"
The code[2] seems to be setting $_ to a value that I didn't expect,
and the documentation of $ARG[1] is sketchy; there's a large gap
between when pod2ipf sets $_ and when it uses it.
[1] It's only in the index under $ARG, not under $_ :-(
[2] I'd attach it but then the article wouldn't propogate.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 3 Jan 2012 19:22:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: POD module synopses?
Message-Id: <341ct8-25p.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <ck3at8-u0i1.ln1@anubis.morrow.me.uk>, on 01/03/2012
> at 01:52 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >These don't look like module names to me: are you sure they aren't
> >actually Pod::Checker and Pod::Escapes?
>
> You're right; they seem to be
>
> Q:\programs\perl\lib\5.10.0\Pod\checker.pm
> Q:\programs\perl\lib\5.10.0\Pod\Escapes.pm
>
> I'm not quite sure what is happening; the error message is produced by
>
>
> print STDERR "\n!!! Not matching: `$_' vs. `$2' in $shortpath
> $longname\n"
>
> The code[2] seems to be setting $_ to a value that I didn't expect,
> and the documentation of $ARG[1] is sketchy; there's a large gap
> between when pod2ipf sets $_ and when it uses it.
Just to see, I took a brief look at
ftp://mirror.ox.ac.uk/sites/www.cpan.org/ports/os2/pod2ipf-1.27.cmd.gz ,
and I'm afraid it's such an awful mess I can't follow what it's doing at
all. I presume you're not using that version, but the later version you
said you found somewhere, since the error message is different?
Unless you have a particular need for IPF documentation, I'd recommend
using something else. If you don't find command-line perldoc acceptable,
you can build an HTML tree with something like
mkdir Q:\Programs\Perl\html
perl -MPod::Simple::HTMLBatch -ePod::Simple::HTMLBatch::go
@INC Q:/Programs/Perl/html
(that second command should be on one line.)
Ben
------------------------------
Date: Tue, 03 Jan 2012 15:20:53 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: POD module synopses?
Message-Id: <4f036325$1$fuzhry+tra$mr2ice@news.patriot.net>
In <341ct8-25p.ln1@anubis.morrow.me.uk>, on 01/03/2012
at 07:22 PM, Ben Morrow <ben@morrow.me.uk> said:
>Just to see, I took a brief look at
>ftp://mirror.ox.ac.uk/sites/www.cpan.org/ports/os2/pod2ipf-1.27.cmd.gz
>, and I'm afraid it's such an awful mess I can't follow what it's
>doing at all. I presume you're not using that version, but the later
>version you said you found somewhere, since the error message is
>different?
It's basically the same code; I added some data to the error messages
to make it easier for me to follow what was going on.
>Unless you have a particular need for IPF documentation,
It's a lot easier to use. I've done enough hacking on pod2ipf that I
can now build an IPF that compiles, with warnings, into a usable INF.
Some of the warnings are due to issues in the POD and some are due to
a bug[1] in pod2ipf that I haven't tracked down yet.
[1] Truncated output lines
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 4 Jan 2012 22:46:27 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: POD module synopses?
Message-Id: <3f1ft8-6kd.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <341ct8-25p.ln1@anubis.morrow.me.uk>, on 01/03/2012
> at 07:22 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Unless you have a particular need for IPF documentation,
>
> It's a lot easier to use. I've done enough hacking on pod2ipf that I
> can now build an IPF that compiles, with warnings, into a usable INF.
OK. If you have (or can acquire) a decent understanding of the IPF file
format, you may find it easier to start again using the Pod::Simple
modules, in particular Pod::Simple::Search.
Ben
------------------------------
Date: Tue, 3 Jan 2012 18:10:29 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: regexp for matching a string with mandatory underscores
Message-Id: <jdvgak$m99$1@reader1.panix.com>
In article <87pqf3tpvc.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
>> On 2011-12-29, John W. Krahn <jwkrahn@example.com> wrote:
>
>[...]
>
>>> It is actually short for tr/_/_/ which replaces every '_'
>>> character with a '_' character and returns the number of
>>> replacements made. It has the advantages that it doesn't
>>> interpolate and it only does one thing, and does it well.
>>
>> For which value of "well"? If it is applied to 2GB string, would
>> it make a copy of it?
>
>Not when counting or replacing character in a non-UTF8 string.
>
>> If the string is tied to a database entry, would
>> it cause a database update?
>
>Maybe, maybe not. That would depend on the implemention of tieing
>mechanism.
>
> [and a forking question]
I remember Dennis Ritchie's use of the phrase "unwarranted chumminess
with the C implementation" (in a far more dubious situation). I'm
hesitant to depend on implementation details unless they're guaranteed
in the documentation. Particularly with Perl: systems I'm on have
versions variously between 5.8 and 5.14, so I wonder which versions
have which optimizations, or indeed if they are done at all.
On the other hand, when you write the scripts yourself (I do that a
lot with Perl), you can know whether it does ties, large strings, or
other unusual cases.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 03 Jan 2012 19:07:49 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: regexp for matching a string with mandatory underscores
Message-Id: <87r4zgwqnu.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <87pqf3tpvc.fsf@sapphire.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
>>> On 2011-12-29, John W. Krahn <jwkrahn@example.com> wrote:
>>
>>[...]
>>
>>>> It is actually short for tr/_/_/ which replaces every '_'
>>>> character with a '_' character and returns the number of
>>>> replacements made. It has the advantages that it doesn't
>>>> interpolate and it only does one thing, and does it well.
>>>
>>> For which value of "well"? If it is applied to 2GB string, would
>>> it make a copy of it?
>>
>>Not when counting or replacing character in a non-UTF8 string.
>>
>>> If the string is tied to a database entry, would
>>> it cause a database update?
>>
>>Maybe, maybe not. That would depend on the implemention of tieing
>>mechanism.
>>
>> [and a forking question]
>
> I remember Dennis Ritchie's use of the phrase "unwarranted chumminess
> with the C implementation" (in a far more dubious situation). I'm
> hesitant to depend on implementation details unless they're guaranteed
> in the documentation.
What is guaranteed in the documentation today will be 'accidentally
still in the documentation' tomorrow and 'a deprecated feature which
must not be used under any circumstances' (on threat of immediate
excommunication from the universe of all the just and beautiful
people) two days later, so that doesn't really buy you anything :->.
OTOH, it is sensible to assume that - usually - the people who wrote
the implementation will have tried to make it behave sensibly and in
this case, that tr/// will neither copy nor modify the string except
if this is necessary to perform the requested operation.
Re: tied scalars
What will happen when an operation is performed on a scalar tied to
something depends on the class/ module used to provide the tied
semantics and this can be anything, so the question didn't really make
sense: This class or module may well cause 'a database update' despite
perl didn't modify the data.
------------------------------
Date: Wed, 04 Jan 2012 14:44:24 -0800
From: sln@netherlands.com
Subject: Re: regexp for matching a string with mandatory underscores
Message-Id: <ocl9g7ho3gejphgpnd27ifjlvfjd8f50qe@4ax.com>
On Tue, 27 Dec 2011 12:40:04 +0000, Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth David Filmer <davidfilmer@davidfilmer.com>:
>> I want to be able to match the string foo1_bar2_baz3 as having
>> multiple underscore characters (with no intervening whitespace), but
>> not match foo1_bar2 which has only one underscore. I want to ignore
>> one match, but not two or more.
>>
>> This would be easy if \w did not ALSO match underscores. But it
>> does. There does not seem to be a character class for alphanumeric
>> ONLY.
>
If I understand you correctly from your example, this may work.
/^[^\W_]+(?:_[^\W_]+){2,}$/
-sln
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 3581
***************************************
