[19372] in Perl-Users-Digest
Perl-Users Digest, Issue: 1567 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 20 00:05:52 2001
Date: Sun, 19 Aug 2001 21:05:15 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <998280315-v10-i1567@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 19 Aug 2001 Volume: 10 Number: 1567
Today's topics:
Re: array question <angenent@kabelfoon.nl>
Re: array question (Tad McClellan)
Re: array question <davidhilseenews@yahoo.com>
Re: array question <rsherman@ce.gatech.edu>
Re: avoiding caching in gethostbyname / gethostbyaddr (Garry Williams)
Re: avoiding caching in gethostbyname / gethostbyaddr <rlogsdon@io.com>
Re: Embedded perl question <goldbb2@earthlink.net>
Re: Embedding perl under Windows <iltzu@sci.invalid>
Re: EXEs from within Perl (Garry Williams)
Re: perldoc is like Greek to a beginner?? <goldbb2@earthlink.net>
Re: perldoc is like Greek to a beginner?? (Alan Barclay)
Re: perldoc is like Greek to a beginner?? <uri@sysarch.com>
Re: select doesn't detect pipe close <goldbb2@earthlink.net>
Re: select doesn't detect pipe close <uri@sysarch.com>
Re: Split root@kane.kane
Re: Split (Mario Rizzuti)
Re: String Parsing > Remove everything after the first (Alan Barclay)
Re: Uh Oh: URL Encode <flavell@mail.cern.ch>
Re: Uh Oh: URL Encode <comdog@panix.com>
Re: Uh Oh: URL Encode <iltzu@sci.invalid>
What's wrong with this code?? <chaos0920@orgio.net>
Re: What's wrong with this code?? <tony_curtis32@yahoo.com>
Re: What's wrong with this code?? (Steven Smolinski)
Re: What's wrong with this code?? (John J. Trammell)
Re: What's wrong with this code?? <bart.lateur@skynet.be>
Re: What's wrong with this code?? <chaos0920@orgio.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 20 Aug 2001 01:51:05 +0200
From: "GOGAR" <angenent@kabelfoon.nl>
Subject: Re: array question
Message-Id: <9lpjbs$2ppc$1@news.kabelfoon.nl>
i thought it was
my $count = $#array;
???
"Ilya Martynov" <ilya@martynov.org> wrote in message
news:874rr49en3.fsf@abra.ru...
>
> bl> how can I tell how many elements my array has after I read a text
> bl> file into it
>
> bl> the text file my have 10 to 25 lines after I load it into a array
> bl> I want to count the elements of the array
>
> my $count = @array;
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> | Ilya Martynov (http://martynov.org/)
|
> | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6
|
> | AGAVA Software Company (http://www.agava.com/)
|
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
------------------------------
Date: Sun, 19 Aug 2001 19:32:00 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: array question
Message-Id: <slrn9o0j3g.nsb.tadmc@tadmc26.august.net>
[ Jeopardectomy performed ]
GOGAR <angenent@kabelfoon.nl> wrote:
>"Ilya Martynov" <ilya@martynov.org> wrote in message
>news:874rr49en3.fsf@abra.ru...
>>
>> bl> how can I tell how many elements my array has
>> my $count = @array;
>i thought
^^^^^^^
Why do that? You don't have a perl to try it with?
Please do not post guesses. It increases confusion, we're trying
to _decrease_ confusion hereabouts. You are hurting rather than
helping.
If you cannot test your code, then please do not post your code.
>it was
>
>my $count = $#array;
---------------------------
#!/usr/bin/perl -w
use strict;
my @array = qw(one two three four);
my $count = $#array;
print "there are $count elements in the array\n";
$count = @array;
print "there are $count elements in the array\n";
---------------------------
Empiricism is dead :-(
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 20 Aug 2001 00:37:36 GMT
From: "David Hilsee" <davidhilseenews@yahoo.com>
Subject: Re: array question
Message-Id: <kZYf7.8420$c81.3124387@news1.rdc1.md.home.com>
"GOGAR" <angenent@kabelfoon.nl> wrote in message
news:9lpjbs$2ppc$1@news.kabelfoon.nl...
> i thought it was
>
> my $count = $#array;
>
> ???
>
That yields the index of the last element. For example:
@array = ('onething');
$last = $#array;
$count = @array;
In the above code, there is one element in @array, so $count will be one.
$last, however, will be zero, since that element is at index zero.
David Hilsee
------------------------------
Date: Sun, 19 Aug 2001 21:01:39 +0500
From: Robert Sherman <rsherman@ce.gatech.edu>
Subject: Re: array question
Message-Id: <3B7FE2E3.C0BAA36A@ce.gatech.edu>
Mr bad luck wrote:
>
> how can I tell how many elements my array has after I read a text file into
> it
>
> the text file my have 10 to 25 lines after I load it into a array
> I want to count the elements of the array
$count = @array
should do it for you.
--
robert sherman
css, cee
georgia institute of technology
atlanta, ga, usa
------------------------------
Date: Mon, 20 Aug 2001 01:59:55 GMT
From: garry@ifr.zvolve.net (Garry Williams)
Subject: Re: avoiding caching in gethostbyname / gethostbyaddr
Message-Id: <slrn9o0roq.ff8.garry@zfw.zvolve.net>
On Fri, 10 Aug 2001 20:48:54 -0500, Reuben Logsdon <rlogsdon@io.com> wrote:
> Hello all,
>
> I have a Perl CGI script which I want to react in a special way to visits
> by a certian client, who will be identified by DNS. Basically, if the
> script is visited by a client from "enforcer.myhost.com", then the CGI
> script will share it's registered/not-registered status, and will accept a
> self-destruct command if my enforcer bot chooses to send one. It will not
> share that kind of privileged data with any other visitor.
>
> What worries me is that some person could configure reverse DNS on an IP
> they control such that its claims its name is "enforcer.myhost.com" (in a
> non-authorative way).
^^^^^^^^^^^^^^^^^^^
Huh?
If the person is authoritative for the IP address in question, the
data stored in the PTR resource record *is* authoritative data. It
could be a lie, but it is authoritative.
> So I will have my CGI script do gethostbyaddr on the visitor IP, and
> then do a double-check gethostbyname on the privileged name to make
^^^^^^^^^^^^^^^
What's that? Do you mean your own host name?
> sure its IP matches the visitor. Will gethostbyname always do a
> round trip back to the authorative nameserver of "myhost.com", or
> will it possibly use a cached (fraudulent) IP from some internal
> table?
The answer to the query for the PTR record for d.c.b.a.in-addr.arpa.
is not used to answer the query for an A record on the name that
happens to match. There is no cache kept this way. The two are
separate name spaces in the DNS.
The answer to the query for the A record for a name *is* cached (by
design). The authoritative server specifies the time the data should
be considered valid.
This does not (by itself) expose you to any spoofing.
> Is there some flag that I can pass to gethostbyname or
> another function to require a full DNS lookup without caching?
No. But see the Net::DNS module, if you really want that. (I don't
think that's what you want. Knowing that a lie about the
in-addr.arpa. domain cannot pollute other domains answers your
question I believe.)
> Does anyone have any experiences to share with these types of
> authentication issues?
IP spoofing can be used to lie about all DNS domains. That requires
physical access to your (name server's) network.
--
Garry Williams
------------------------------
Date: Sun, 19 Aug 2001 22:22:21 -0500
From: Reuben Logsdon <rlogsdon@io.com>
Subject: Re: avoiding caching in gethostbyname / gethostbyaddr
Message-Id: <Pine.LNX.4.33.0108192200420.31641-100000@hagbard.io.com>
On Fri, 10 Aug 2001, Godzilla! wrote:
>
> Highly illogical. How will you self-destruct a backup copy of
> an unregistered script? More illogical, what would prevent a
> person from denying your host access to this script? Most
> illogical, what prevents hacking in a registration? Absolutely
> illogical, what prevents removal of your registration coding?
Of course anyone who is reasonably competent can remove all of the
registration-key-validation code. However, most of my copyright problems
come from people who don't know how to code at all. They only know how to
find-n-replace my copyright string with theirs. (Maybe people who learn
to code have also learned to respect other's work...)
Besides, I only have to make it sufficiently difficult and troublesome to
hack so that the $50 registration seems like a value. It doesn't have to
be totally impossible to hack.
> Have you considered destruction of files within an account
> other than your own is a criminal offense? Your appropriate
> and expected response is civil ligitigation.
The proper license agreement would make it okay. Microsoft's Windows and
Office XP will be disabled remotely if the license terms are violated;
that is essentially what my bot will do.
Civil litigation works great as a threat, but it isn't cost effective if
you have to carry through. The last time I wanted to sue somebody over
copyright, my lawyer quoted me $45-60k to carry it through. You can claim
the court costs as part of your damages, but if the defendant doesn't pay,
you have to pay it all. I have never heard of anyone actually going to
court against small-time offenders. They threaten it all the time of
course.
> There is only one effective method of script self-destruction.
> Tell me what is this method?
um, unlink($0)? print "you are being sued";? Not publishing in the first
place? Selling hosted services rather than re-distributed software? Who
knows? There are so many ways.
Regards,
Reuben
------------------------------
Date: Sun, 19 Aug 2001 21:00:58 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Embedded perl question
Message-Id: <3B80614A.DD83C009@earthlink.net>
Robert J. Lee wrote:
>
> Benjamin Goldberg wrote:
> > Robert J. Lee wrote:
> > >
> > > Is there any easy way of saving the state of the perl interpretor
> > > to a file (i.e. the values of all variables AND any subroutines
> > > which have been processed)?
> > >
> > > Basically, I've decided to use embedded perl to add scripting
> > > capabilities to a MUD I'm writing in C++, which has to be stopped
> > > and restarted periodically as code changes (needing recompiling).
> > > So, obviously, I need to save any changes to the perl bits as
> > > well.
> >
> > Do you? Wouldn't it be easier to have it so that "perl bit" are
> > always put into files, and then loaded via require?
>
> Well, that would be one way of saving and restoring everything
> important, but it has it's problems. In order to save functions, you
> would have to save every function as it was declared (on the C++
> side), but then when you restore it, you have the problem of variables
> resetting themselves to the value they had when they were initialised
> in the first incarnation. (i.e. A function initialises a variable,
> another function changes it, the MUD re-starts and its value would be
> re-initialised).
I'm not sure what you mean. If a variable is successfully restored by
whatever mechanism reads it from the file, then there's no need for it
to be re-initialized. Why do you assume that it would be 'initialized'
when it doesn't need to be?
> > > I've got as far as getting a hashtable of all data out of the
> > > stash, which should contain globs of all the data AFAICT. But the
> > > docs don't seem to give much explanation on what I should be doing
> > > with globs ("GV*"s) to turn them into data to save. (Also, I seem
> > > to be getting "SV*"s from the hash and I don't know how to turn
> > > them into "GV*"s).
> >
> > This is the wrong way to do it, since it contains so much data, and
> > you don't really want to save *everything*. If you need data saved,
> > you can use Data::Dumper or Storable.pm or whatever, but remember
> > that you should only save that which *needs* to be saved.
>
> This brings the problem of knowing what needs to be saved; as perl
> functions can effectively overwrite or create any variable. You'd need
> to write an entire parser just to figure out which variables you were
> using as you typed in each function. The whole point of using perl was
> to avoid having to write a scripting language of my own...
There's an easier way. Just *ask* your authors which variables need to
be made persistant. Use packages to keep namespaces seperate, and when
each function is completed, print to the author a list of
already-persistant variables, and ask if there are any variables used by
the function which should be persistant but aren't.
> > What are you adding scripting for?[snip]
>
> The idea is that administrators of the MUD can write subroutines to
> control how the mud operates (every time someone does something, a
> perl subroutine is called that checks if any others need to be called
> to change anything in the MUD). That way, administrators can control
> exactly what the MUD does in any situation without learning C++,
> writing lots of messy code and shutting the MUD down to recompile, and
> without needing direct access to the server to recompile everything.
> Thus leaving me free to focus on implementing more C++ things.
If you require that the admins put their code in packages [or better
yet, have the editor prefix their code with appropriate package
declarations], you should be able to do this without needing any special
"save everything" module.
> > Anyway, do you really expect that the perl code you had before a
> > compile will work well with everything after a recompile? I don't
> > think so.
>
> I don't know. I would have thought that as long as the perl side stays
> the same, and it doesn't use any callbacks into C++ code, that
> recompiling the C++ side shouldn't make any difference. Wether it
> would work after being reloaded into memory, I have no idea (pointers
> to memory areas that have moved etc.). If it *can* be done, then I'm
> sure someone here will know how...
The thing is, there obviously have to be some callbacks to the C++ for
the perl code to do anything useful.
> > Any bits of perl code you need should probably be put each in their
> > own file, and loaded from those files when the MUD starts [or better
> > yet, only when they're needed]. Saving the state that the loaded
> > pieces of code were in when the mud was last up is probably wrong.
>
> Except if their state has changed since they were put each in their
> own file. Which is very likely in this case.
I think you're confusing data with code. You put the code [the
subroutines] into files when it's written. You put the data into files
once when it's created [by the subroutines], plus every X minutes as
backup, and once when the mud shuts down.
The code [the subroutines] is initially in files, it gets loaded when
users first enter the part of the mud it's relevant to [or loaded when
the mud boots up], the BEGIN blocks in the code are called, which
register various callbacks and load the data from the files, and
registers the data with some sort of backup mechanism. The callbacks do
whatever special behaviour the admins need.
> It looks like I'll have to save the subroutines as they are created,
> and re-load them first on start-up, saving the variables on shut-down,
> and re-loading them after subroutines to change their values back to
> what they should be. I was hoping that it could be done more easily
> than this.
This is exactly the way to do it, except that you can write it so don't
necessarily need to think about it this way.
For instance:
package Administorators::AdminName::foo;
use MudUtilities::Persistant;
MudUtilities::Persistant::MakePersist \( our ($foo, $bar, $blah) )
or do {
$foo = .... initializer for $foo goes here ...;
$bar = ....;
$blah = ....;
}
... code which uses $foo, $bar, $blah ...
sub asdf {
}
__END__
The thing is, some code in the file gets run when the file is loaded,
[including the *definitions* of the subs], but the subs don't actually
get called until they're called. So you can initialize them however you
want. Some of this stuff can be auto-generated, too, to make things
easier. MakePersist can look at caller() to figure out what file called
it, and use that to figure out where to put the data [each admin's data
should be seperate from each other admin's data, and for that matter,
each admin might want each file, each group of subroutines to have
seperate data files].
--
I'm not a programmer but I play one on TV...
------------------------------
Date: 19 Aug 2001 23:14:09 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Embedding perl under Windows
Message-Id: <998261525.23603@itz.pp.sci.fi>
In article <TPZd7.709332$eK2.146491182@news4.rdc1.on.home.com>, Cory C. Albrecht wrote:
>
>When I first started on the embbeding of perl into my program, before I got
>this far, my idea was to basically embed perl, then make available to it
>various functions from inside my program. I had thought that xsubs would allow
>me to do that, but now I see that xsubs are for importing functions in
>external native-code shared libraries into perl. The stuff in perlembed is
>basically all about calling perl code from your program, but I need the
>embedded perl to be able to call code from the programme it's embedded inside.
I've never done this -- for that matter I've never even written an XSUB
-- but the documentation certainly suggests it can be done just fine.
What you should do is write XS glue code for the functions you want to
be callable from Perl, use xsubpp to translate that into C code that you
can link with your program, and then hook it into perl with newXS().
The perlembed manual page does show an example of the last step -- it
just then goes on to say that once you've got DynaLoader working, you
rarely need to do this manually. Obviously this is one of those times.
(It may not work quite that way -- as I said, I haven't tested this.
But it certainly must be possible, and probably not even too hard.)
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Mon, 20 Aug 2001 02:08:48 GMT
From: garry@ifr.zvolve.net (Garry Williams)
Subject: Re: EXEs from within Perl
Message-Id: <slrn9o0s9g.ff8.garry@zfw.zvolve.net>
On Sun, 19 Aug 2001 19:24:22 GMT, Graham W. Boyes - TOAO.net
<me@REMOVETHIStoao.net> wrote:
> I was wondering if it's possible to to run a DOS executable, for example,
> Mem.exe (displays used and unused memory) and have the output put into a
> variable inside my Perl program.
See the perlop manual page section on the qx/STRING/ operator. The
short answer:
my $mem_out = qx/mem.exe/;
--
Garry Williams
------------------------------
Date: Sun, 19 Aug 2001 21:12:36 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: perldoc is like Greek to a beginner??
Message-Id: <3B806404.D0615752@earthlink.net>
Bernie Cosell wrote:
>
> abigail@foad.org (Abigail) wrote:
>
> } Could you give examples from some well known languages, like C, Java
> } and ADA that proves they are not truely context free?
>
> How about something like:
> ---------------------
> typedef int x ;
>
> x *y();
> ---------------------
>
> Does it parse into an expression with a function call, or a
> declaration?
For it to be a funcion call, you would need an extra pair of parens:
(x)*y();
Simply saying "int" doesn't do a cast, you have to do "(int)"
--
I'm not a programmer but I play one on TV...
------------------------------
Date: 20 Aug 2001 03:18:07 GMT
From: gorilla@elaine.furryape.com (Alan Barclay)
Subject: Re: perldoc is like Greek to a beginner??
Message-Id: <998277393.759997@elaine.furryape.com>
In article <x7bslpantv.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
>and as others have said, there is little chance of simplifying regular
>expression grammar. it has been around for so many years and nobody has
>come up with a better/simpler grammar.
There have been simpler garmmars, but only at the cost of much
of the power. The implementation of regexes you get when using SQL's
LIKE operator is very simple, but not very powerful.
------------------------------
Date: Mon, 20 Aug 2001 03:42:46 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: perldoc is like Greek to a beginner??
Message-Id: <x7wv3zgzwm.fsf@home.sysarch.com>
>>>>> "AB" == Alan Barclay <gorilla@elaine.furryape.com> writes:
AB> In article <x7bslpantv.fsf@home.sysarch.com>,
AB> Uri Guttman <uri@sysarch.com> wrote:
>> and as others have said, there is little chance of simplifying regular
>> expression grammar. it has been around for so many years and nobody has
>> come up with a better/simpler grammar.
AB> There have been simpler garmmars, but only at the cost of much of
AB> the power. The implementation of regexes you get when using SQL's
AB> LIKE operator is very simple, but not very powerful.
well, obviously i mean a simpler grammar for the same power level. i
have to steal tad's tag line and say you have to pay for the power. to
have perl's regex power, you need to master its grammar (which isn't
THAT hard). it just requires some proper thinking.
one important idea which is rarely taught (i stole it from MJD) is to
visualize two pointers, one in the string and one in the regex. they
move independently but are obviously tied to each other via the
regex. most newbies never get this concept early enough and have trouble
parsing and designing regexes.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 19 Aug 2001 20:08:02 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: select doesn't detect pipe close
Message-Id: <3B8054E2.970559E9@earthlink.net>
Uri Guttman wrote:
>
> >>>>> "BG" == Benjamin Goldberg <goldbb2@earthlink.net> writes:
>
> BG> Ok: here's my rewritten code:
> BG> sub new {
> BG> my $proto = shift;
> BG> my $class = ref($proto) || $proto;
> BG> pipe my( $p2cr, $p2cw ) or die "pipe failed: $!";
> BG> pipe my( $c2pr, $c2pw ) or die "pipe failed: $!";
> BG> defined( my $pid = fork ) or die "fork failed: $!";
> BG> select((
> BG> select($p2cw), $|=1,
> BG> select($c2pw), $|=1,
> BG> )[0]);
>
> better to use sysread and syswrite with pipes. there is usually no
> need or want for buffering, so even setting $| slows it down as it
> will still buffer i/o for you even if it autoflushes.
I don't use print directly... all my io is Storable's store_fd and
fd_retrieve. I don't know whether store_fd uses print or syswrite, and
I'd rather not take chances.
> BG> print STDERR "Forked: $$\n";
> BG> if( $pid ) {
> BG> # these two lines weren't here, so those two filehandles would
> BG> # have been closed implicitly with the return().
>
> BG> local $!;
>
> why that?
Because I want to ignore any errors I get from closing the pipes, and
not see them in the calling scope. I suppose it doesn't matter, since
they were just created by pipe, and it's not likely that anything could
go wrong closing them.
> BG> close $_ for ($p2cr, $c2pw);
>
> not sure if i like this or not. i understand it clearly enough but i
> think it is too much of a trick to be clear to all potential readers.
> i would stick with 2 simple closes.
>
> close $p2cr ;
> close $c2pw ;
I think that anyone who understands Perl's syntax should be able to
understand that statement. There's no reason to have them as two
seperate lines, except to make it 'pretty'.
> BG> return bless { pid => $pid,
> BG> reader => $c2pr, writer => $p2cw,
> BG> state => "unconnected", }, $class;
> BG> } else {
>
> if the last statement in a block is return, next, last, etc. there is
> no need for the else. just remove the else{} and it will work the same
> and be much easier to read. also you preserve the supply of precious
> 'else's and braces.
True, it will work the same, but I think it's easier to read this way.
> but this style has other positive effects beyond pixel/byte
> conservation. it actually reduces the number of lines of code by 2 or
> so lines (depending on the cuddling else style) and removes a level of
> indent. and the old metric of about 1 bug per 100 lines of code is
> fairly accurate. the lower line count you get from perl's flexible
> logic flow syntax is a major reason for using it (besides better
> readibility).
The metric of 1 bug per 100 lines depends on how 'compact' the code is.
If you write your code very compactly, the bugs/lines ratio will be
higher.
> BG> Here's the daemon code (it hasn't changed any):
> BG> sub daemon {
> BG> my ($reader, $writer) = @_;
> BG> my ($dbi, $sth);
> BG> MAIN: while( 1 ) {
> BG> vec(my($rflags)="", fileno $reader, 1) = 1;
> BG> my $eflags = $rflags;
> BG> print STDERR "$$: entering select...\n";
> BG> select($rflags, undef, $eflags, undef)
> BG> or die "select: $!";
> BG> print STDERR "$$: select returned.\n";
> BG> if( !vec($rflags, fileno $reader, 1) ) {
> BG> print STDERR "$$: EOF seen, exiting\n";
> BG> exit;
> BG> }
> BG> The rest is ommited. Anyway, select() here never returns, ever.
>
> use IO::Select, Event.pm, POE or Stem for this stuff. why reinvent
> this wheel one more time?
I don't want the overhead of IO::Select -- and all I'm trying to do is
test whether there's either data available or an eof, so I can exit
cleanly in case of eof [not to mention, code using IO::Select would be
just as long, anyway]. I don't need to manage a list of filehandles,
which is IO::Select's main purpose.
Event.pm can't work for this, because the main body of the loop must be
done synchronously... there's no way to tell if/when a DBI statement
handle is ready to fetch, so we *must* create a seperate process, do the
fetch [synchronously], and then write the data to a pipe, so that the
parent can [asynchronously] watch for data there, and read the fetched
results at it's leisure. POE has the same problem... and I quote:
POE has a very simple cooperative multitasking model; every
session executes in the same OS process without threads or
forking. For this reason, you should beware of using blocking
system calls in POE programs.
The entire purpose of my 'DBI::Daemon' module is so a parent thread can
create a daemon process which will make a DBI connection. This way, it
doesn't matter how long any particular DBI call blocks, the parent
process can add the filehandle of the daemon to a list [perhaps an
IO::Select object], and be doing other stuff while waiting for the
database query to run. If you could get a filehandle from DBI statement
handles, we wouldn't need this.
I don't know what Stem is, but it probably has the same problems.
Anyway... you still haven't answered my question. Not planning to?
--
I'm not a programmer but I play one on TV...
------------------------------
Date: Mon, 20 Aug 2001 03:14:17 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: select doesn't detect pipe close
Message-Id: <x7zo8vh185.fsf@home.sysarch.com>
>>>>> "BG" == Benjamin Goldberg <goldbb2@earthlink.net> writes:
>> better to use sysread and syswrite with pipes. there is usually no
>> need or want for buffering, so even setting $| slows it down as it
>> will still buffer i/o for you even if it autoflushes.
BG> I don't use print directly... all my io is Storable's store_fd and
BG> fd_retrieve. I don't know whether store_fd uses print or syswrite, and
BG> I'd rather not take chances.
if you want async i/o you must control it yourself. almost anytime a lib takes
over a handle, there is no reason to use 4 arg select since the lib will
mostl likely be doing blocking i/o.
BG> close $_ for ($p2cr, $c2pw);
>>
>> not sure if i like this or not. i understand it clearly enough but i
>> think it is too much of a trick to be clear to all potential readers.
>> i would stick with 2 simple closes.
>>
>> close $p2cr ;
>> close $c2pw ;
BG> I think that anyone who understands Perl's syntax should be able to
BG> understand that statement. There's no reason to have them as two
BG> seperate lines, except to make it 'pretty'.
but my point is that it is prettier. and easier to read. it doesn't
matter that your style is syntactically correct and not too hard to
parse. it is still harder than two simple closes. it gains you nothing
but internal satisfaction for using a neat trick. but the one person who
reads it and doesn't grok it immediately loses. that person is whom you
should be coding for and not yourself.
BG> return bless { pid => $pid,
BG> reader => $c2pr, writer => $p2cw,
BG> state => "unconnected", }, $class;
BG> } else {
>>
>> if the last statement in a block is return, next, last, etc. there is
>> no need for the else. just remove the else{} and it will work the same
>> and be much easier to read. also you preserve the supply of precious
>> 'else's and braces.
BG> True, it will work the same, but I think it's easier to read this way.
well, we disagree again. fewer lines is usually easier to read (hmm,
oppsite view of the close issue above. but i can be contradictory if i
want. :). lower levels of indent are also easier to read. and as i said,
it will be less buggy in the long run.
>> but this style has other positive effects beyond pixel/byte
>> conservation. it actually reduces the number of lines of code by 2 or
>> so lines (depending on the cuddling else style) and removes a level of
>> indent. and the old metric of about 1 bug per 100 lines of code is
>> fairly accurate. the lower line count you get from perl's flexible
>> logic flow syntax is a major reason for using it (besides better
>> readibility).
BG> The metric of 1 bug per 100 lines depends on how 'compact' the
BG> code is. If you write your code very compactly, the bugs/lines
BG> ratio will be higher.
nope. it has been shown to be the same in assembler, high level
languages and very high level languages. the actual number of lines is
the metric and it doesn't vary with the compactness of the language.
>> use IO::Select, Event.pm, POE or Stem for this stuff. why reinvent
>> this wheel one more time?
BG> I don't want the overhead of IO::Select -- and all I'm trying to
BG> do is test whether there's either data available or an eof, so I
BG> can exit cleanly in case of eof [not to mention, code using
BG> IO::Select would be just as long, anyway]. I don't need to manage
BG> a list of filehandles, which is IO::Select's main purpose.
nope, IO::Select is a simpler api for 4 arg select. you can use it
anyway you want. and your worrying about overhead and then letting
storable do your i/o for you makes little sense. you either control all
i/o or don't care and let modules do it. you aren't saving any serious
time by not using io::select but your code is much more complex for not
using it. again the bugs per line count metric shows up here. using a
(correctly working) module lowers your line count and so will lower your
bug count as well.
BG> Event.pm can't work for this, because the main body of the loop
BG> must be done synchronously... there's no way to tell if/when a DBI
BG> statement handle is ready to fetch, so we *must* create a seperate
BG> process, do the fetch [synchronously], and then write the data to
BG> a pipe, so that the parent can [asynchronously] watch for data
BG> there, and read the fetched results at it's leisure. POE has the
BG> same problem... and I quote:
BG> POE has a very simple cooperative multitasking model; every
BG> session executes in the same OS process without threads or
BG> forking. For this reason, you should beware of using blocking
BG> system calls in POE programs.
they can be worked around without too much difficulty. see below.
BG> The entire purpose of my 'DBI::Daemon' module is so a parent thread can
BG> create a daemon process which will make a DBI connection. This way, it
BG> doesn't matter how long any particular DBI call blocks, the parent
BG> process can add the filehandle of the daemon to a list [perhaps an
BG> IO::Select object], and be doing other stuff while waiting for the
BG> database query to run. If you could get a filehandle from DBI statement
BG> handles, we wouldn't need this.
you can do that with a separate process sure and even a separate thread
(which is still buggy in perl). dbi is well known to have major issue
with handle io and the problem is not perl or DBI but the c libraries
provided by the DB vendors. almost all of them assume synchronous
blocking io and their lib controls it. dbi just sits on top of that lib.
BG> I don't know what Stem is, but it probably has the same problems.
nope. stem is a message based system which makes it trivial to have
multiprocess systems communicate with almost no coding. in fact i have
plans for a DBI module which will do a similar thing to what you want
and be much more flexible and easier to use at the same time.
BG> Anyway... you still haven't answered my question. Not planning to?
you haven't asked one. i am trying to help you. you don't seem to care
about my opinions on coding style. why should you care about my opinions
on daemon design? not that i would know anything about daemon design :)
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
------------------------------
Date: Mon, 20 Aug 2001 02:56:31 GMT
From: root@kane.kane
Subject: Re: Split
Message-Id: <lmkfw928.fsf@kane.kane>
Are the fields spread over multiple lines? A handle referenced explicitly reads
only a single line.
Kevin
------------------------------
Date: 19 Aug 2001 20:58:10 -0700
From: mariorizzuti@yahoo.com (Mario Rizzuti)
Subject: Re: Split
Message-Id: <42f3ee2.0108191958.4bab00aa@posting.google.com>
"Asgar" <asgar@tkusa.com> wrote in message news:<3b801b9a$0$9821@wodc7nh0.news.uu.net>...
> I am reading a file of fields separated by space:
>
> while (<FILEH>)
> ($a, $b, $c, ....) = split (/ /); # Total of 23 fields
>
> # Doing some stuff & writing it back to another file:
>
> print OUTPUTFILE "$a $b $c ...."
>
> Everything works fine, except that I am getting the first
> 9 fields written back into the output file.
> what am doing wrong?
Maybe using the space as delimiter is not a good idea unless your
fields are 1-word. Let's say your first field is "comp lang perl
misc", this will go in your $a,$b,$c and $d variables altough it's
just one field.
If that's the problem, you can quote the fields or use a character
which you are sure that can't be found in the fields values (the pipe
'|' is a popular choice).
Why not using an array instead of a number of scalars.
my @field = split ' ', $_, -1;
#update
my $newrec = join ' ', @field;
You can surely get better suggestions if you post a sample record,both
in its original file and the output file.
---
Mario Rizzuti
------------------------------
Date: 20 Aug 2001 02:39:12 GMT
From: gorilla@elaine.furryape.com (Alan Barclay)
Subject: Re: String Parsing > Remove everything after the first non-number
Message-Id: <998275150.939528@elaine.furryape.com>
In article <5e79838e.0108180924.67a8f411@posting.google.com>,
DB <rubbish_tip@hotmail.com> wrote:
>I need a snippet of a regex to remove everything after the first
>non-number in a string. For example, I know that the first few chars
>of the string will be numbers - but I don't know how many, or how long
You asked for a regex, and you got lots of examples of that, but
you might want to use Perl's built in string to number conversion.
$string="1234567221%sk23$823498as22"
$string += 0;
This is slightly faster than the regex solutions, but not
so fast that you shouldn't be coding for clarity.
------------------------------
Date: Mon, 20 Aug 2001 00:35:04 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Uh Oh: URL Encode
Message-Id: <Pine.LNX.4.30.0108200033530.13325-100000@lxplus023.cern.ch>
On Aug 20, Ilya Martynov inscribed on the eternal scroll:
> I think arguing here on c.l.p.misc hardly can improve URI::Escape.
But it does rate to help our understanding of the issues, and it seems
to me that IK was right on the ball with those.
------------------------------
Date: Sun, 19 Aug 2001 20:48:47 -0400
From: brian d foy <comdog@panix.com>
Subject: Re: Uh Oh: URL Encode
Message-Id: <comdog-F724B1.20484719082001@news.panix.com>
In article <998255404.21655@itz.pp.sci.fi>, Ilmari Karonen
<usenet11553@itz.pp.sci.fi> wrote:
> In article <comdog-D759F7.18140413082001@news.panix.com>, brian d foy wrote:
> >In article <bafgntkd4fv5pntj7k9j9dqducdtl453h7@4ax.com>, Bart Lateur
> ><bart.lateur@skynet.be> wrote:
> >
> >> It DOES NOT escape the most dangerous characters "=" and "&". It's a
> >> know bug, or feature, depending on what side you're on.
> >i think you want to say "it does not, by default, escape all
> >of the special characters that matter to the CGI". after all,
> >HTTP is only one scheme out of many. :)
> I still can't believe Gisle Aas got this wrong. I wonder if changing
> the default character class would break more existing code than it would
> fix.
i understand what you are saying, and can agree with you to a certain
extent. however, the module documentation is very clear about what
it does. it works as documented and the way Gisle wanted it to work.
we may think it should be some other way, which doesn't mean that it
is broken. :)
but i suppose the rest of this argument is best solved by just
asking him. ;)
--
brian d foy <comdog@panix.com>
CGI Meta FAQ - http://www.perl.org/CGI_MetaFAQ.html
Troubleshooting CGI scripts - http://www.perl.org/troubleshooting_CGI.html
------------------------------
Date: 20 Aug 2001 01:33:09 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Uh Oh: URL Encode
Message-Id: <998271127.26161@itz.pp.sci.fi>
In article <Pine.LNX.4.30.0108200033530.13325-100000@lxplus023.cern.ch>, Alan J. Flavell wrote:
>On Aug 20, Ilya Martynov inscribed on the eternal scroll:
>
>> I think arguing here on c.l.p.misc hardly can improve URI::Escape.
>
>But it does rate to help our understanding of the issues, and it seems
>to me that IK was right on the ball with those.
I just e-mailed Gisle Aas about this. We'll see how it turns out.
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Mon, 20 Aug 2001 01:22:27 GMT
From: Seung Choi <chaos0920@orgio.net>
Subject: What's wrong with this code??
Message-Id: <Xns9102D8F7B6812chaos0920orgionet@199.45.45.11>
Hello.
I need help on the code below.
$var1 = qw{<tr bgcolor="RGB(200,230,200)">};
when I put this variable into the html code,
it only puts 'bgcolor="RGB(200,230,200)">' and omits <tr part.
I don't know how to get around this problem.
Thanks in advance
------------------------------
Date: 19 Aug 2001 20:38:50 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: What's wrong with this code??
Message-Id: <87itfjcxxx.fsf@limey.hpcc.uh.edu>
>> On Mon, 20 Aug 2001 01:22:27 GMT,
>> Seung Choi <chaos0920@orgio.net> said:
> Hello. I need help on the code below.
> $var1 = qw{<tr bgcolor="RGB(200,230,200)">};
"perldoc perlop". What return type does qw() have?
What kind of variable is $var1 ?
> when I put this variable into the html code, it only
With code not shown...
> puts 'bgcolor="RGB(200,230,200)">' and omits <tr part.
Style sheets, and note the HTML shortcut methods in CGI.pm
or (if this isn't CGI) HTML::AsSubs.
hth
t
--
Hmmmmm...sacrilicious!
------------------------------
Date: Mon, 20 Aug 2001 01:40:11 GMT
From: steven.smolinski@sympatico.ca (Steven Smolinski)
Subject: Re: What's wrong with this code??
Message-Id: <%TZf7.5448$wX5.524507@news20.bellglobal.com>
Seung Choi <chaos0920@orgio.net> wrote:
>
> $var1 = qw{<tr bgcolor="RGB(200,230,200)">};
>
> when I put this variable into the html code,
> it only puts 'bgcolor="RGB(200,230,200)">' and omits <tr part.
It works exactly as one should expect.
Quoting from perlop:
qw/STRING/
Evaluates to a list of the words extracted out of STRING, using
embedded whitespace as the word delimiters. [...]
Read further from the manpage for all the semantics. To summarize,
$var1 = qw{<tr bgcolor="RGB(200,230,200)">};
is equivalent to:
$var1 = ( q[<tr], q[bgcolor="RGB(200,230,200)">] );
And the comma operator there evaluates the left operand, throws it away,
and evaluates the right operand, which is then assigned to $var1.
Steve
--
Steven Smolinski => http://arbiter.ca/
------------------------------
Date: 20 Aug 2001 02:28:08 GMT
From: trammell@haqq.hypersloth.invalid (John J. Trammell)
Subject: Re: What's wrong with this code??
Message-Id: <slrn9o1cjo.nnr.trammell@haqq.hypersloth.net>
On Mon, 20 Aug 2001 01:22:27 GMT, Seung Choi <chaos0920@orgio.net> wrote:
> Hello.
>
> I need help on the code below.
>
> $var1 = qw{<tr bgcolor="RGB(200,230,200)">};
^
I think you mean:
$var1 = qq{<tr bgcolor="RGB(200,230,200)">};
--
ERR_NOSIG: sigfile out of commission while removing 'all your base'
references.
------------------------------
Date: Mon, 20 Aug 2001 02:33:13 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: What's wrong with this code??
Message-Id: <cot0ot4koth9sg884ug226g5fjf0bs6eri@4ax.com>
Seung Choi wrote:
>I need help on the code below.
>
>$var1 = qw{<tr bgcolor="RGB(200,230,200)">};
>
>when I put this variable into the html code,
>it only puts 'bgcolor="RGB(200,230,200)">' and omits <tr part.
Why are you using "qw"? I think you want "q", or maybe "qq" (no
difference in this example). "qw" splits on whitespace into a list, of
which you only use the last item.
--
Bart.
------------------------------
Date: Mon, 20 Aug 2001 03:07:09 GMT
From: Seung Choi <chaos0920@orgio.net>
Subject: Re: What's wrong with this code??
Message-Id: <Xns9102EAB7514D2chaos0920orgionet@199.45.45.11>
Bart Lateur <bart.lateur@skynet.be> wrote in
news:cot0ot4koth9sg884ug226g5fjf0bs6eri@4ax.com:
> Seung Choi wrote:
>
>>I need help on the code below.
>>
>>$var1 = qw{<tr bgcolor="RGB(200,230,200)">};
>>
>>when I put this variable into the html code, it only puts
>>'bgcolor="RGB(200,230,200)">' and omits <tr part.
>
> Why are you using "qw"? I think you want "q", or maybe "qq" (no
> difference in this example). "qw" splits on whitespace into a list, of
> which you only use the last item.
>
Thanks all you guys for helping me out.
I resolved the problem I had based on what you guys had told me.
Thanks a lot.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 1567
***************************************
