[23953] in Perl-Users-Digest
Perl-Users Digest, Issue: 6154 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 18 14:10:46 2004
Date: Wed, 18 Feb 2004 11:10:14 -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, 18 Feb 2004 Volume: 10 Number: 6154
Today's topics:
Re: MakeMaker problem (Bill)
Re: more stripping <jurgenex@hotmail.com>
Re: more stripping <hillmw@ram.lmtas.lmco.com>
Re: more stripping <tore@aursand.no>
Re: more stripping <gnari@simnet.is>
Multiple substitution in a complex RE (SqlSlinger)
Re: Multiple substitution in a complex RE <xx087@freenet.carleton.ca>
Re: Multiple substitution in a complex RE <uri@stemsystems.com>
Re: Multiple substitution in a complex RE <xx087@freenet.carleton.ca>
Newbe Unicode question (Scottie)
Re: Newbe Unicode question <usenet@morrow.me.uk>
No performance gain using threads? (Yash)
Re: No performance gain using threads? <usenet@morrow.me.uk>
Re: OPEN( , Get , or slurping problem <noreply@gunnar.cc>
Re: Posting Usenet News Messages <tobyorn@to.by>
Re: Posting Usenet News Messages <ignoromnibus@cochon.fr>
Re: Posting Usenet News Messages <ignoromnibus@cochon.fr>
Re: Posting Usenet News Messages <ignoromnibus@cochon.fr>
Re: Posting Usenet News Messages <usenet@morrow.me.uk>
Re: Posting Usenet News Messages <usenet@morrow.me.uk>
Re: Prob Perl/Tk <twhu@lucent.com>
Re: Regular Expresions & pattern matching (mis)understa <nobull@mail.com>
Re: Regular Expresions & pattern matching (mis)understa <tassilo.parseval@rwth-aachen.de>
Re: Regular Expresions & pattern matching (mis)understa <uri@stemsystems.com>
Re: suggestion for a best book <gabe@tyler.c0s.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 18 Feb 2004 06:55:32 -0800
From: wherrera@lynxview.com (Bill)
Subject: Re: MakeMaker problem
Message-Id: <239ce42f.0402180655.3c173209@posting.google.com>
Guru03 <Guru03@despammed.com> wrote in message news:<Xns949362E09DFDAGuru03despammedcom@193.43.96.1>...
> I tried:
>
> EXE_FILES = ['exec.pl'];
>
> INST_SCRIPT = '/usr/sbin';
>
> but it doesn't work.
instead of 'exec.pl' use something in the source tree the makefile uses, like
'/lib/dir/exec.pl'
------------------------------
Date: Wed, 18 Feb 2004 14:47:29 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: more stripping
Message-Id: <5WKYb.43718$1S1.30955@nwrddc01.gnilink.net>
Michael Hill wrote:
> Well, I definitely have been receiving some rather fierce remarks
> about using the cgi modules. There are many good points that were
> spoken most deal with the ease of coding but the compelling ones deal
> with security.
>
> Can anyone talk to what security holes may be there?
Google may be very educational (hint: this topic has been discussed a few
times before).
jue
------------------------------
Date: Wed, 18 Feb 2004 10:43:13 -0600
From: Michael Hill <hillmw@ram.lmtas.lmco.com>
To: =?iso-8859-1?Q?J=FCrgen?= Exner <jurgenex@hotmail.com>
Subject: Re: more stripping
Message-Id: <40339621.2CB642B7@ram.lmtas.lmco.com>
> >
> > Can anyone talk to what security holes may be there?
>
> Google may be very educational (hint: this topic has been discussed a few
> times before).
>
> jue
I'm not asking for a comprehensive listing of security holes using cgi,
but rather inherent security holes because I am using *hand rolled* cgi
instead of the cgi module.
------------------------------
Date: Wed, 18 Feb 2004 18:01:21 +0100
From: Tore Aursand <tore@aursand.no>
Subject: Re: more stripping
Message-Id: <pan.2004.02.18.17.01.21.196588@aursand.no>
On Wed, 18 Feb 2004 10:43:13 -0600, Michael Hill wrote:
>>> Can anyone talk to what security holes may be there?
>> Google may be very educational (hint: this topic has been discussed a
>> few times before).
> I'm not asking for a comprehensive listing of security holes using cgi,
> but rather inherent security holes because I am using *hand rolled* cgi
> instead of the cgi module.
And that _has_ been discussed before. Try searching for 'cgi security' in
the *perl* groups from <http://groups.google.com/>.
--
Tore Aursand <tore@aursand.no>
"Every man usually has something he can do better than anyone else.
Usually it is reading his own handwriting." -- Unknown
------------------------------
Date: Wed, 18 Feb 2004 17:59:23 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: more stripping
Message-Id: <c10946$437$1@news.simnet.is>
"Michael Hill" <hillmw@charter.net> wrote in message
news:1036nmsa59b714f@corp.supernews.com...
> Well, I definitely have been receiving some rather fierce remarks about
> using the cgi modules. There are many good points that were spoken most
deal
> with the ease of coding but the compelling ones deal with security.
>
> Can anyone talk to what security holes may be there?
for example, I have seen roll-your-owners use unsafe methods to
import querystring/form params into program symboltable.
like cgi?foo=1&bar=x being evaled into $foo and $bar.
gnari
------------------------------
Date: 18 Feb 2004 08:50:29 -0800
From: vince.iacoboni@db.com (SqlSlinger)
Subject: Multiple substitution in a complex RE
Message-Id: <b74d9c54.0402180850.4e9bec05@posting.google.com>
I'm trying to convert all occurances of variables of the form
VARIABLE_ONE, VARIABLE_NUMBER_TWO, a_really_long_VARIABLE_name
to the form
VariableOne, VariableNumberTwo, AReallyLongVariableName
Here's my Program:
$_='a_really_long_VARIABLE_name';
s/([A-Za-z])([^_ \t\n]*?)(_([A-Za-z0-9])([^_ \t\n]*?))+/\u$1\L$2\E\u$4\L$5\E/;
print;
__END__
Prints "AReally_long_VARIABLE_name".
Can anyone help?
------------------------------
Date: 18 Feb 2004 17:34:41 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: Multiple substitution in a complex RE
Message-Id: <slrnc378hi.dm5.xx087@smeagol.ncf.ca>
SqlSlinger <vince.iacoboni@db.com> wrote:
> I'm trying to convert all occurances of variables of the form
> VARIABLE_ONE, VARIABLE_NUMBER_TWO, a_really_long_VARIABLE_name
> to the form
> VariableOne, VariableNumberTwo, AReallyLongVariableName
my @vars = qw(VARIABLE_ONE VARIABLE_NUMBER_TWO a_really_long_VARIABLE_name);
my %StudlyCaps;
foreach (@vars) {
my $var = ucfirst lc;
$var =~ s/_(.)/\U$1/g;
$StudlyCaps{$_} = $var;
}
use Data::Dumper;
print Dumper(\%StudlyCaps);
--
Glenn Jackman
NCF Sysadmin
glennj@ncf.ca
------------------------------
Date: Wed, 18 Feb 2004 18:36:14 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Multiple substitution in a complex RE
Message-Id: <x7vfm4utep.fsf@mail.sysarch.com>
>>>>> "GJ" == Glenn Jackman <xx087@freenet.carleton.ca> writes:
GJ> my @vars = qw(VARIABLE_ONE VARIABLE_NUMBER_TWO
GJ> a_really_long_VARIABLE_name);
GJ> foreach (@vars) {
GJ> my $var = ucfirst lc;
GJ> $var =~ s/_(.)/\U$1/g;
GJ> }
s/_?(.)([^_]*)/\U$1\L$2/g ;
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 18 Feb 2004 18:59:43 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: Multiple substitution in a complex RE
Message-Id: <slrnc37dh0.dm5.xx087@smeagol.ncf.ca>
Uri Guttman <uri@stemsystems.com> wrote:
> >>>>> "GJ" == Glenn Jackman <xx087@freenet.carleton.ca> writes:
> GJ> my $var = ucfirst lc;
> GJ> $var =~ s/_(.)/\U$1/g;
>
> s/_?(.)([^_]*)/\U$1\L$2/g ;
Good one.
--
Glenn Jackman
NCF Sysadmin
glennj@ncf.ca
------------------------------
Date: 18 Feb 2004 08:39:31 -0800
From: Scott_Starker@sil.org (Scottie)
Subject: Newbe Unicode question
Message-Id: <899d28b2.0402180839.2d0e6a90@posting.google.com>
How do I make a Unicode Perl script that uses:
perl zapotec.pl zapotecUnicode.txt > asdf.txt
where "zapotecUnicode.txt" is UTF-8 file?
In the zapotec.pl I have:
binmode(STDOUT, ":utf8");
binmode(STDIN, ":utf8");
use encoding "latin2";
at the very top.
Any help would be appreciated.
Scott
------------------------------
Date: Wed, 18 Feb 2004 18:32:13 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Newbe Unicode question
Message-Id: <c10b3d$a0u$2@wisteria.csv.warwick.ac.uk>
Scott_Starker@sil.org (Scottie) wrote:
> How do I make a Unicode Perl script that uses:
> perl zapotec.pl zapotecUnicode.txt > asdf.txt
> where "zapotecUnicode.txt" is UTF-8 file?
>
> In the zapotec.pl I have:
> binmode(STDOUT, ":utf8");
> binmode(STDIN, ":utf8");
> use encoding "latin2";
Why? Is your source in latin2?
> at the very top.
>
> Any help would be appreciated.
Err... what does yor script do, and in what ways is in not working?
Ben
--
don't get my sympathy hanging out the 15th floor. you've changed the locks 3
times, he still comes reeling though the door, and soon he'll get to you, teach
you how to get to purest hell. you do it to yourself and that's what really
hurts is you do it to yourself just you, you and noone else * ben@morrow.me.uk
------------------------------
Date: 18 Feb 2004 08:16:05 -0800
From: yashgt@yahoo.com (Yash)
Subject: No performance gain using threads?
Message-Id: <5a373b1d.0402180816.7ad5dc35@posting.google.com>
I have a perl program that spawns as many threads as the number of
processors. Each thread reads lines from a set of files exclusively
assigned to it and after performing some in-memory operations, writes
the enriched lines back to disk.
The number of threads is limited by the number of files to process.
When I ran with a single file, it spawned just one thread and took 200
seconds to finish. I could see 1 CPU occupied by looking at the Task
Manager.
When I made 4 copies of the file, it spawned 4 threads and too 800
secs. I was expecting it to take a little more than 200 secs. All 4
CPUs were seen to be occupied.
There is no locking or synchronization between the threads.
This means that the program does not scale up as expected, by
processing more data in different threads.
Is there something else I might need to do in the program logic so
that adding more processors will help me process larger volumes of
data in the same time?
I am using Active Perl 5.8 on Windows 2000.
Thanks
------------------------------
Date: Wed, 18 Feb 2004 18:18:30 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: No performance gain using threads?
Message-Id: <c10a9m$7gh$6@wisteria.csv.warwick.ac.uk>
yashgt@yahoo.com (Yash) wrote:
> I have a perl program that spawns as many threads as the number of
> processors. Each thread reads lines from a set of files exclusively
> assigned to it and after performing some in-memory operations, writes
> the enriched lines back to disk.
> The number of threads is limited by the number of files to process.
> When I ran with a single file, it spawned just one thread and took 200
> seconds to finish. I could see 1 CPU occupied by looking at the Task
> Manager.
> When I made 4 copies of the file, it spawned 4 threads and too 800
> secs. I was expecting it to take a little more than 200 secs. All 4
> CPUs were seen to be occupied.
> There is no locking or synchronization between the threads.
Perl's threads are currently highly inefficient... you may want to look
into writing a little 'driver' program that starts several instances of
your processing program, rather than trying to thread.
Ben
--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces molit animos, tristesque mentes erigit. | ben@morrow.me.uk
Musica vel ipsas arbores et horridas movet feras. |
------------------------------
Date: Wed, 18 Feb 2004 15:28:53 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: OPEN( , Get , or slurping problem
Message-Id: <c0vtj9$1cqoqv$1@ID-184292.news.uni-berlin.de>
Michele Dondi wrote:
> Gunnar Hjalmarsson wrote:
>
>>>>> open my $file, '<', \$site or die $!;
>>>>> do_something while <$file>;
>
> [snip]
>
>> I figured out that the reason for my problems was that I run my
>> test script in taint mode. Untainting $site:
>>
>> $site = $1 if $site =~ /(.*)/s;
>>
>> does not make a difference, and I don't get any meaningful error
>> message. (Only "Premature end of script headers".)
>
> Well, it's evident even from your .sig that you "have to do" with
> CGI et similia.
Guilty as charged.
> But from the posts (of yours) I read it seems you're *not* "yet
> anoter Perl==CGI-kinda-guy",
Yeah, I do know that Perl == CGI returns false (or doesn't
compile...). ;-)
> so is there any good reason for testing the above snippet in *that*
> environment?
Well, I'm on a W98 box, and not very fond of the MS-DOS window. Maybe
the truth is that I have never bothered to learn how to configure
and/or use it properly.
Anyway, since most Perl things I do actually are CGI apps, I have
simply made it a habit to also run 5 lines test programs as CGI.
Not sure if those reasons are good enough. :)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 18 Feb 2004 16:19:51 GMT
From: Toby <tobyorn@to.by>
Subject: Re: Posting Usenet News Messages
Message-Id: <HgMYb.983$wJ5.276@newsfep4-winn.server.ntli.net>
Camelback Jones wrote:
OK, perl learner here ...
> $server->post( [ @lines ] ) or die "Can't post: $!\n";
Isn't that going to pass an anonymous array to post() with @lines
in [0] ?
> And it dies. "Can't post: " (no $! content).
I've heard (on clpm) that you you shouldn't use \n after $! as it
supresses messages (or something like that). YMMV
Cheers
Toby
--
morec0ffeeplease * at * yahoo * com
------------------------------
Date: Wed, 18 Feb 2004 11:01:00 -0600
From: Camelback Jones <ignoromnibus@cochon.fr>
Subject: Re: Posting Usenet News Messages
Message-Id: <c105v31kpq@enews2.newsguy.com>
Toby wrote:
> Camelback Jones wrote:
>
> OK, perl learner here ...
>
>> $server->post( [ @lines ] ) or die "Can't post: $!\n";
>
> Isn't that going to pass an anonymous array to post() with @lines
> in [0] ?
>
Good question - that's directly from the example I quoted. The problem with
this particular "example" is that there's no definition in it of what
@lines is supposed to contain... hmmmm...
However, I've tried it with and without the brackets, and it hasn't changed
the result.
>> And it dies. "Can't post: " (no $! content).
>
> I've heard (on clpm) that you you shouldn't use \n after $! as it
> supresses messages (or something like that). YMMV
>
I tried it without the newline (which I had added, since I had put in
several alternative sets of data for @lines), and it showed the program
name and line number, which I already knew...
> Cheers
> Toby
Hey, thanks for taking a shot at it!
--
The greatest unsolved theorem in mathematics is why some people are
better at it than others.
------------------------------
Date: Wed, 18 Feb 2004 11:00:54 -0600
From: Camelback Jones <ignoromnibus@cochon.fr>
Subject: Re: Posting Usenet News Messages
Message-Id: <c105uu0kpq@enews2.newsguy.com>
Tad McClellan wrote:
> Camelback Jones <ignoromnibus@cochon.fr> wrote:
>> Tad McClellan wrote:
>>> Camelback Jones <ignoromnibus@cochon.fr> wrote:
>
>
>
>>>> "Newsgroups: alt.test",
>>>> "Subject: One More Test",
>>>> "Message-ID: <433498\@noemail.com>",
>>>> "Path: aintg",
>>>> " ",
>>> ^
>>> ^
>>> ^ you don't want that space character there.
>>
>> Why not?
>
>
> Because then you will make the 3-char sequence "\n \n" when
> you are supposed to be making the 2-char sequence "\n\n".
>
>
>> The spec calls for a blank line. What DO you want there?
>
>
> A blank line.
>
> A line with a space character on it is not blank,
> it has a space character on it.
>
This depends on how the NNTP server interprets it. Many pieces of software
do in fact interpret a line as "blank" if there are no "printable"
characters on it, and an ascii 32 is not considered "printable". I don't
know whether NNTP considers it to be a "blank" line if it has one or more
spaces, but I do know that at least this particular part of it - so far -
hasn't seemed to make the slightest difference whether it's accepted for
posting or not.
>
>>> So the claim "This is the body of this message." is a lie, it
>>> is in the headers of the message.
>>
>> No, it's not a lie.
>
>
> Didn't you see the smiley?
>
> Do you know what a smiley means?
>
Sure, but it's a bit (or maybe several bits) on the disingenuous side to
argue that a line with a ascii character 32 on it is not "blank" on the one
hand and then fail to discriminate between "lie" and "incorrect", on the
other, no? ;)
>
>> If I'm interpreting your comments, should this work?
>
>
> Yes.
>
>
>> @lines = ('From: Norbo Quantitator <aintg@noemail.com>',
>> 'Date: Fri, Feb 13 2004 15:14:13 CST',
>> 'Newsgroups: alt.test',
>> 'Subject: One More Test',
>> 'Message-ID: <433499@noemail.com>',
>> 'Path: aintg',
>> '',
>> '',
>> 'This is the body of this message.',
>> 'There may be any number of body lines. Or not.',
>> ''
>> );
>>
>> It doesn't - perhaps you have an example that does?
>
>
> I can't help then. Sorry.
>
I'll take that as a "no".
Thank you for trying, anyway. I'll let you know when I do get this working,
and then you'll know, too.
--
The greatest unsolved theorem in mathematics is why some people are
better at it than others.
------------------------------
Date: Wed, 18 Feb 2004 11:01:07 -0600
From: Camelback Jones <ignoromnibus@cochon.fr>
Subject: Re: Posting Usenet News Messages
Message-Id: <c105v92kpq@enews2.newsguy.com>
Steve May wrote:
> Camelback Jones wrote:
>> Tad McClellan wrote:
>>
>>
>>>Camelback Jones <ignoromnibus@cochon.fr> wrote:
>>>
>>
>> I've gone back and forth, with and without one or more "blank" lines,
>> and, as stated, with and without newlines as part of the line content.
>> Doesn't seem to have made a diff so far.
>>
>
> Tad told you this in the process of kindly giving you a few pointers
> on other potential problems with your code.
>
Definitely, there are some pointers, I agree. "Kindly" is an assumption
that may or may not be valid: neither you nor I know his motive(s) and
"kindness" may or may not play a part. I certainly appreciate his attempts,
whatever his motives may be, at any rate. However, the fact remains that -
as helpful as they may be - they haven't resulted in the code functioning,
and I merely report that fact; I can't see any reason for you to take
exception to my statement.
> > So what will be output? Here's part of it:
> >
> > Path: aintg\n \nThis is the body of this message.\n
> > ^^^^^
> >
> > But you need "\n\n" to end the headers, and that sequence is
> > not there.
> >
> > So the claim "This is the body of this message." is a lie, it
> > is in the headers of the message.
>
>
> Consider: "Text\n\n"
>
> Note the construction: text and a newline, then another newline.
> The second newline *is* a blank line since nothing preceeds the
> newline on that line...and nothing can come after it, obviously.
>
> ---------------
>
> Consider: "Text\n \n"
>
> Note the constructon: text and a newline, a space and a newline.
> The first line holds text, the second line holds a space.
> I don't see any blank lines there, do you?
>
That depends on what you mean by "blank", and on what perl interprets as
"blank".
I understand that what you are trying to say here is that a "blank" line is
one that consists of nothing but a single ascii character 10 - which is not
necessarily the case for every language and every piece of software.
For all I know, NNTP is perfectly happy to consider a line as "blank" if
there's nothing on it but spaces - I've tried it both ways, and it hasn't
made any difference so far, and I therefore have no basis on which to
conclude whether there is or is not an issue there - certainly it is not
"the" issue.
However, that's not the point I was making there, which was: "lie" and
"incorrect" are not the same thing. What I said was not a "lie", it was -
in terms of what NNTP apparently wants - "incorrect".
> Take a look at the documentation (pod) for NET::NNTP and see what
> it says.
No such documentation exists, for the simple reason that there is no such
piece of code as NET::NNTP. No, wait! I see... it's a lie! You really meant
Net::NNTP, didn't you? ;)
Really, though, I did look at both pod and man for Net::NNTP. I didn't see
much, if any, difference between them. Is there something specific in the
pod thant's not in the man pages? What is it you think I'm missing?
I do appreciate your trying to help, although, to be frank, RTFM is not
really terribly helpful, since I am RTFM, and it (whatever "it" is) is not
jumping off the page at me.
Here, for what it's worth, is the current version of the code, which, with
or without the newlines (one to terminate headers and one or more at start
and end the message body) and with or without the square brackets, gives
"Can't post". I can pop over to knode and post manually, and the top part
of the particular program does successfully log onto the server and
download headers, download the last message, and print it before proceeding
on to this last bit:
$server->postok() or die "Server said no posting allowed.\n";
print "Apparently we CAN post to $name\n";
@lines = ("From: Norbo Quantitator <aintg@noemail.com>\n",
"Date: Fri, Feb 13 2004 15:14:13 CST\n",
"Newsgroups: alt.test\n",
"Subject: \"There is no subject\"\n",
"Message-ID: <$randid\@noemail.com>\n",
"Path: aintg\n",
"\n",
"\n",
"This is the body of this message.\n",
"There may be any number of body lines. Or not.\n",
"\n"
);
$server->post( [ @lines ] ) or die "Can't post: $!\n";
Tad didn't seem to have a working example of what I was trying to do - do
you? Or can you see something wrong with either the construction or the
approach?
--
The greatest unsolved theorem in mathematics is why some people are
better at it than others.
------------------------------
Date: Wed, 18 Feb 2004 17:48:40 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Posting Usenet News Messages
Message-Id: <c108ho$7gh$1@wisteria.csv.warwick.ac.uk>
Toby <tobyorn@to.by> wrote:
> Camelback Jones wrote:
>
> OK, perl learner here ...
>
> > $server->post( [ @lines ] ) or die "Can't post: $!\n";
>
> Isn't that going to pass an anonymous array to post() with @lines
> in [0] ?
No... the elements of an array (anon or not) are scalars, and scalars
cannot hold arrays. Say @lines contained (1, 2, 3). The construction
[ @lines ]
first evaluates @lines in list context, when it returns a list of its
elements:
[ (1, 2, 3) ]
. Then it creates an anonymous array from that list, which will thus
contain a copy of the elements of @list.
> > And it dies. "Can't post: " (no $! content).
>
> I've heard (on clpm) that you you shouldn't use \n after $! as it
> supresses messages (or something like that). YMMV
It's nothing to do with $!, rather to do with warn and die. If you put
"\n" on the end, it will suppress the line-number and file information,
which is usually essential to debugging any problem.
Ben
--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces molit animos, tristesque mentes erigit. | ben@morrow.me.uk
Musica vel ipsas arbores et horridas movet feras. |
------------------------------
Date: Wed, 18 Feb 2004 18:46:17 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Posting Usenet News Messages
Message-Id: <c10btp$a0u$4@wisteria.csv.warwick.ac.uk>
Camelback Jones <ignoromnibus@cochon.fr> wrote:
> Steve May wrote:
> >
> > Consider: "Text\n \n"
> >
> > Note the constructon: text and a newline, a space and a newline.
> > The first line holds text, the second line holds a space.
> > I don't see any blank lines there, do you?
> >
>
> That depends on what you mean by "blank", and on what perl interprets as
> "blank".
...and what NNTP interprets as blank.
> I understand that what you are trying to say here is that a "blank" line is
> one that consists of nothing but a single ascii character 10 - which is not
> necessarily the case for every language and every piece of software.
As a general rule, Unix software (and descendants, such as perl)
consider a line blank iff it has nothing on it.
> For all I know, NNTP is perfectly happy to consider a line as "blank" if
> there's nothing on it but spaces
Well, you don't know much then, do you? Try reading the relevant RFC
before writing a newsreader: NNTP considers a blank line to be exactly
"\015\012\015\012"
, ie. ASCII CR LF CR LF.
> However, that's not the point I was making there, which was: "lie" and
> "incorrect" are not the same thing. What I said was not a "lie", it was -
> in terms of what NNTP apparently wants - "incorrect".
Oh, FFS, get a life. The only thing that matters is whether what you
said was correct or not: getting on your high horse about the fact that
you didn't mean it to be false helps noone.
> > Take a look at the documentation (pod) for NET::NNTP and see what
> > it says.
>
> Really, though, I did look at both pod and man for Net::NNTP. I didn't see
> much, if any, difference between them. Is there something specific in the
> pod thant's not in the man pages? What is it you think I'm missing?
There is no difference.
Ben
--
And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
* ben@morrow.me.uk *
------------------------------
Date: Wed, 18 Feb 2004 11:48:37 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: Prob Perl/Tk
Message-Id: <c10515$1u4@netnews.proxy.lucent.com>
"Orion93" <orion93@club-internet.fr> wrote
[snip]
> $main->Button(-text=>'Ok',-command=>\my $recupPages)->pack(-side=>'left',
> expand=>1);
?????
what is '-command=>\my $recupPages' ?
check syntax.
-command => sub {...}
-command => &sub_name
-command => [....]
------------------------------
Date: 18 Feb 2004 18:05:47 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Regular Expresions & pattern matching (mis)understanding
Message-Id: <u91xosgt50.fsf@wcl-l.bham.ac.uk>
Ben Morrow <usenet@morrow.me.uk> writes:
> Nils Petter Vaskinn <no@spam.for.me.invalid> wrote:
> >
> > if ( /^(.*)<page>([0-9]+)<\/page>(.*)/ ) {
>
> Bleech!
>
> if ( m|^(.*)<page>(\d+)</page>(.*)| ) {
I think the ability to use alternate quoting delimiters is often
overrated. I don't like to increase the ammount of contextual
information needed to understand what I'm looking at. In the case of
a long regex I don't want to have to remeber that it's using some
delimiter other than /. Compared to the tiny effort of the extra
keystoke to escape each / I don't think the small loss of readability
is justified.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 18 Feb 2004 18:25:33 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Regular Expresions & pattern matching (mis)understanding
Message-Id: <c10amt$8sk$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Brian McCauley:
> Ben Morrow <usenet@morrow.me.uk> writes:
>
>> Nils Petter Vaskinn <no@spam.for.me.invalid> wrote:
>> >
>> > if ( /^(.*)<page>([0-9]+)<\/page>(.*)/ ) {
>>
>> Bleech!
>>
>> if ( m|^(.*)<page>(\d+)</page>(.*)| ) {
>
> I think the ability to use alternate quoting delimiters is often
> overrated. I don't like to increase the ammount of contextual
> information needed to understand what I'm looking at. In the case of
> a long regex I don't want to have to remeber that it's using some
> delimiter other than /. Compared to the tiny effort of the extra
> keystoke to escape each / I don't think the small loss of readability
> is justified.
And particularly, using a delimiter that has special meaning in regexps
(such as '|') is always a bad idea. Under these circumstances I prefer
to use '!' or '#' or in fact any character that visually stands out and
is not meta in its semantics.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 18 Feb 2004 18:39:51 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Regular Expresions & pattern matching (mis)understanding
Message-Id: <x7smh8ut8o.fsf@mail.sysarch.com>
>>>>> "BM" == Brian McCauley <nobull@mail.com> writes:
BM> Ben Morrow <usenet@morrow.me.uk> writes:
>> Nils Petter Vaskinn <no@spam.for.me.invalid> wrote:
>> >
>> > if ( /^(.*)<page>([0-9]+)<\/page>(.*)/ ) {
>>
>> Bleech!
>>
>> if ( m|^(.*)<page>(\d+)</page>(.*)| ) {
BM> I think the ability to use alternate quoting delimiters is often
BM> overrated. I don't like to increase the ammount of contextual
BM> information needed to understand what I'm looking at. In the case of
BM> a long regex I don't want to have to remeber that it's using some
BM> delimiter other than /. Compared to the tiny effort of the extra
BM> keystoke to escape each / I don't think the small loss of readability
BM> is justified.
i have to disagree. i find \ annoying to see when it is not needed. just
choose a delimiter that works with this regex. i like paired delims like
{} or []. and if the regex gets too long or complex, /x is called
for. and then paired delims work very well:
s{
blah
}
{
replace
}sexi ;
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 18 Feb 2004 10:54:25 -0800
From: gabe <gabe@tyler.c0s.org>
Subject: Re: suggestion for a best book
Message-Id: <863c98kyla.fsf@tyler.c0s.org>
consider this seconded
------------------------------
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 6154
***************************************
