[24127] in Perl-Users-Digest
Perl-Users Digest, Issue: 6321 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 28 21:05:35 2004
Date: Sun, 28 Mar 2004 18:05:03 -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 Sun, 28 Mar 2004 Volume: 10 Number: 6321
Today's topics:
Re: Cannot reset LIBPATH in perl program on AIX <shah@typhoon.xnet.com>
Re: File handling concatenating two files <tadmc@augustmail.com>
Help!! Cannot insert TIMESTAMP after upgrade. <shah@typhoon.xnet.com>
Re: losing data on socket (Vorxion)
Re: losing data on socket <uri@stemsystems.com>
Re: LWP cookies <rbell01824@comcast.net>
Re: LWP cookies <uri@stemsystems.com>
Re: LWP cookies <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 28 Mar 2004 23:24:00 +0000 (UTC)
From: Hemant Shah <shah@typhoon.xnet.com>
Subject: Re: Cannot reset LIBPATH in perl program on AIX
Message-Id: <c47mqg$6e1$1@flood.xnet.com>
In comp.databases.ibm-db2 Big and Blue <No_4@dsl.pipex.com> wrote:
> Hemant Shah wrote:
>>
>> I am having a problem with my perl module on AIX system. I cannot reset
>> LIBPATH variable from my perl module.
>
> You can set it. What you mean is that setting it doesn't have any
> effect. This is true. The value used is that at program startup.
This is true.
>
>> I have a perl script that uses my
>> perl module which in turn uses DBD::DB2 to get data from a database.
>>
>> When user logs in, his environment may set LIBPATH and LD_LIBRARY_PATH to
>> another DB2 instance.
>
> Bad practice. The values in here will refer to SPECIFIC APPLICATIONS,
> so should not be set in a global context. (I trust that your Perl scripts
> don't use global variables everywhere, but instead use correctly-scoped ones?)
I am not sure if it is a bad practice. When a user logs into the system,
his/her environment is set to access the database that is used by the
application in that development environment. Each development area has
different DB2 instance so the environment is set based upon the active
development area.
We store information of our source code in a seperate database and have
written several perl scripts that developer can use to search the database.
Until now all the DB2 instances were at same version (UDB V7.2) I upgraded
the source code database to UDB V8. Until I migrate all the instances to
UDB V8 I need to be able to run the scripts that access source code
database.
I am NOT using global variables, all the varaibles are either within the
scope of the function or within the module (e.g. database handle).
That's why I want to change the path within the module.
Here is the sample use of the module in the perl script:
use MyModule;
MyModule::ConnectToDatabase;
$SomeThing = MyModule::GetSomethingForMe($Var1, $Var2);
MyModule::TerminateConnection;
>
>> When functions from my perl module are called I would like to reset LIBPATH
>> to a different DB2 instance.
>
> a) If you know where the dynamic libraries will be at the time you compile
> the extension then set the relevant link-time options so that the Perl
> extensions knows where to look.
I tried that too. I set LIBPATH and LD_LIBRARY_PATH to what I wanted and
built DB2::DBD, but that did not help either.
>
> b) if you can't do a) then run *your* application through a simple sehll
> interlude script that does set LD_LIBRARY_PATH/LIBPATH to the value you
> want and the exec your perl script.
>
>> One option I have is to write a wrapper shell script that resets the
>> variables and then calls the perl script. I am trying to avoid this
>> because there are many scripts (most of which are not under my control)
>> that call functions from my perl module and all of them will have to
>> change. I would rather change one module that is under my control.
>>
>> Is there a way around it?
>
> Yes.
>
> c) similar to b) but you pass in the name of the script you wish to run as
> well, so that you only have one interlude script, but it can exec any DB2
> script.
That will be difficult because I do not write the scripts, I wrote the perl
module that anyone can use to get the data from the database.
>
>
> --
> -*- Just because I've written it here doesn't -*-
> -*- mean that you should, or I do, believe it. -*-
>
--
Hemant Shah /"\ ASCII ribbon campaign
E-mail: NoJunkMailshah@xnet.com \ / ---------------------
X against HTML mail
TO REPLY, REMOVE NoJunkMail / \ and postings
FROM MY E-MAIL ADDRESS.
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.
------------------------------
Date: Sun, 28 Mar 2004 17:06:20 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: File handling concatenating two files
Message-Id: <slrnc6emjc.a96.tadmc@magna.augustmail.com>
uc_sk <kshagun@hotmail.com> wrote:
> I have the task of comparing two text files line by line and
> outputting it after concatenating it. For example:
> In my File1 I have 2 RECORDS:
>
> abcdecf 7 {2,3,4,6} 4
> >{2,3}
> >{6}
>
> lmno-qr 6 {12,16,29} 3
> >{12}
> >{16}
> >{29}
>
> and in File2 I have again 2 RECORDS (if you will see and compare the
> records of File1 and File2, the first line i.e the first pattern is
> the same):
>
> abcdecf 7 {2,3,4,6} 4
> (1,2,3,4,5,6,7) 7 {0,1,2,3,4,5,6} 7
>
> lmno-qr 6 {12,16,29} 3
> (1,2,3,4,6,7) 6 {11,12,16,17,29} 5
>
> So now i want the output after concatenating them as:
>
> abcdecf 7 {2,3,4,6} 4
> (1,2,3,4,5,6,7) 7 {0,1,2,3,4,5,6} 7
> >{2,3}
> >{6}
>
> lmno-qr 6 {12,16,29} 3
> (1,2,3,4,6,7) 6 {11,12,16,17,29} 5
> >{12}
> >{16}
> >{29}
>
> So basically in my final result I want the first two lines of File2
> and want all the lines of File1 except the first line FOR EACH RECORD.
-------------------------------------------------
#!/usr/bin/perl
use strict;
use warnings;
$/ = ''; # enable "paragraph mode"
my %f2;
open FILE2, 'file.2' or die "could not open 'file.2' $!";
while ( <FILE2> ) {
my($key, $value) = /(.*\n)(.*\n)/;
$f2{$key} = $value;
}
close FILE2;
open FILE1, 'file.1' or die "could not open 'file.1' $!";
while ( <FILE1> ) {
my($key, $value) = /(.*?\n)(.*\n)/s;
print $key, $f2{$key}, $value;
}
close FILE1;
-------------------------------------------------
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 28 Mar 2004 23:30:36 +0000 (UTC)
From: Hemant Shah <shah@typhoon.xnet.com>
Subject: Help!! Cannot insert TIMESTAMP after upgrade.
Message-Id: <c47n6s$6kk$1@flood.xnet.com>
Folks,
I recently upgraded/migrated my database from UDB 7.2 on AIX to UDB 8.1 on
Linux. Now I cannot insert data into a TIMESTAMP column. The string I am
using for TIMESTAMP is in ISO format.
The old database was using ISO-8859-1 character set, the new database is
using UTF-8. I have a perl script that inserts data into one of the table
that has time stamp column. The script worked in UDB 7 database but fails
with SQL0180N in UDB 8.
1246: $InsertStmt_CodeChanged_Hdl->execute($SourceNum, $RevBranch, $RevDecimal,
1247: $TimeStamp, $Author, $Command, $SubCommand,
1248: $LinesAdded, $LinesDeleted);
DB<2> p $TimeStamp
2004-03-28-17:06:39.816398
DB<3> n
lidp12|InsertCodeChangedData: DBD::DB2::st execute failed: [IBM][CLI Driver][DB2/LINUX] SQL0180N The syntax of the string representation of a datetime value is incorrect. SQLSTATE=22007
I tried to run following command on the client system but that did not help
either.
db2 bind @db2cli.lst DATETIME ISO blocking all grant public
db2 bind @db2ubind.lst DATETIME ISO blocking all grant public
How can I fix it? I need to fix it A.S.A.P.
Thanks.
--
Hemant Shah /"\ ASCII ribbon campaign
E-mail: NoJunkMailshah@xnet.com \ / ---------------------
X against HTML mail
TO REPLY, REMOVE NoJunkMail / \ and postings
FROM MY E-MAIL ADDRESS.
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.
------------------------------
Date: 28 Mar 2004 19:29:46 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: losing data on socket
Message-Id: <40676dfa$1_1@news.iglou.com>
In article <c47jll$kov$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>Also sprach Vorxion:
>
>So it's neither a lexical nor a package variable (to which local() can
>be applied). What is it then? There are only those two flavour of
>variables. In your case $main_buffer is a package variable as you say
>that it lives in the package 'main'. In this case it could be subject to
>local(), of course.
Global to the package main::, I suppose is what I meant.
>This code is a mess, I am afraid. I doubt people will be able to spot
>the problem in it. Here are some comments that should help you to clean
>up your code a bit. Maybe it will help you to find out what is wrong.
The code looks fine when you don't have to pare down 1100+ lines to 472 or
so. :)
>You are not using strictures. A program of a certain size (and yours
>does qualify) will benefit from using strict along with lexical
>variables. I wouldn't be surprised if your program behaved badly due to
>too many global variables and actions-at-a-distance arising from that.
>Therefore:
No, I'm certainly not using strict. I've tried that and it -insists- on
making you reference every variable by a package name if it's not lexical.
I -need- some package variables, period, and I see no reason to bloat the
code by referencing main:: everywhere.
>> $local_addr = inet_ntoa(scalar(gethostbyname(${local_host} || 'localhost')));
>
>What are those curlies doing there? They are not wrong, but they serve
>no purpose either. All they do is harm readability. Ditch them here and
>everywhere else where you are using them.
I use curlies on every variable that is referenced as an rvalue, period,
the end. It's a matter of stylistic continuity. If I -always- do it, it's
never confusing, as compared to sometimes using them, sometimes not.
>> sub spawn;
>
>What's this for? You always use parens on functions (and no prototypes
>either), so you don't need any forward declarations.
man perlipc
Talk to the developers themselves, since it's actually in the official
POD for perl. I removed the comment, but they said it was a forward
declaration.
>> ##### Set reaper.
>> my $waitedpid = 0;
>
>Interestingly enough, you used a lexical variable here. Why here and not
>elsewhere?
The program has LOTS of lexicals. It's in that 800+ lines I cut loose to
try and post as little as possible.
>> ${cli_logfile} = '__FLTbogus', fl_die(27,"Daemon mode called without absolutely pathed working directory.");
>
>I find using the comma like this confusing. This line looks as though it
>contains two statements. Don't unecessarily join them into on.
It does contain two statements. I learned this syntax from doing something
like:
BLOCKLABEL: {
$found_one++, last BLOCKLABEL if ${line} =~ /\Wone\W/;
...
}
Since it worked there, I use it where possible to combine code. Works
fine. It was in the docs somewhere (probably the Camel) as an example of
how to emulate a 'case' type functionality.
>Also, fl_die() looks like a function that terminates your program. Why
>do you first assign to a variable just to die immediately afterwards.
>Is it maybe because fl_die() accesses the value of $cli_logfile? If so,
>this is a poor way of passing data around. Pass it as a proper argument:
>
> fl_die(27, '...', '__FLTbogus');
>
>The first argument '27', is that a sort of error-code? Maybe you declare
>those as constants. 27 looks rather meaningless to me (and maybe even to
>you when you read your program again in a few months without touching it
>in between).
You entirely misunderstand what it's doing. I'm setting cli_logfile (ouch,
I screwed up and used {}'s on an lvalue...works but goes against my
style...since fixed here), so that it's set when fl_die() calls fl_log(),
and then calling fl_die().
Yes, 27 is an error code that's both logged, and used for exit(). And no,
I don't want to put them all in fl_die or anywhere else so that I can
easily search for the number in the code and find out exactly where I
konked out.
>> use POSIX;
>> chdir('/') or fl_die(10,"Could not chdir prior to daemonisation.");
>
>Wouldn't hurt to include $! in the error message:
Possibly not, but I prefer clean error messages that don't confuse users.
If I have to go in and debug, I can put it in when I test.
>> fl_die(3,"Cannot create socket.") unless ${server};
>> ${server}->setvbuf($super_main_buffer,_IOFBF,102400000);
>
>You didn't read the perldocs too carefully, as it seems. 'perldoc
>IO::Handle' says:
>
> WARNING: The IO::Handle::setvbuf() is not available by default on
> Perls 5.8.0 and later because setvbuf() is rather specific to using
> the stdio library, while Perl prefers the new perlio subsystem
> instead.
True. And that explains why it dies entirely on Solaris under 5.8.0. I
compiled 5.8.3 -without- perlio on linux, and it doesn't crash, but I do
still lose data. You're right, I apparently had missed
To be fair, the Solaris system has 5.6.1 as a default, and the perl 5.8.0
is installed in parallel. The POD that perldoc pulled did -not- have that
statement in it.
>According to your shebang line, you are using 5.8.0.
I am. Apparently perldoc is hardwired to use 5.6.1's POD's, as even
running perldoc under perl5.8.0 doesn't change which POD I got. Okay, so I
didn't see that note.
However, I discovered how to enable it (because it said it was unavailable
on linux under 5.8.3) when I rebuilt 5.8.3 last night, and that problem is
solved.
>Easier:
>
> clean_dead(shift @del_sels) while @del_sels;
>
>You neither need the temporary variable $single_conn nor the explicit
>'scalar'.
True. Thanks for that.
>I think you should try to decrease your character-count a bit. All those
>braces make your code harder on the eye. I particularly hate
>
> ${child_pids{${child}}}
> # should be
> $child_pids{$child}
It's an rvalue. I'm simply being consistant, since if I need them
anywhere, it's inconsistant if they're not everywhere.
>Keep in mind that humans aren't very good at deciphering hordes of
>nested delimiters (especially when they are all the same).
That's what the % key in vi (or the default matching mode in emacs) is for.
:)
>> ##### Make sure to clear the active list for the next cycle.
>> undef @active;
>
>I don't know where that variable is coming from. However, an explicit
>'undef' in a while-loop along with this comment above makes me wonder
>whether you really restricted your variables to its smallest possible
>scope.
@active is package-scoped to main::. I probably could scope it to inside
the while() loop, but it's not harming anything by not being done, either.
Actually, I started using lexicals about 4 months ago, and I'm still
getting into the habit of using them. I used to use local() or nothing.
Now I have lexicals all over the place. If you'd like to verify this, I
could email you the -whole- program. :) I can't put it up here publicly
though.
>I suppose you got the idea by now. My honest suggestion would be to
>dispose of this whole code and re-start from scratch. Before you do so,
>find a consistent coding style that requires less characters (I've
>seldom seen a program where the lines are that long throughout the whole
>code). Maybe you have a preliminary read of 'perldoc perlstyle' for a
>start. Apart from that, pay particular attention to the scoping of your
>variables and try to use less of them as well. In other spots, introduce
>a few variables where it increases readability. The above
>while-condition is such an example. For that you could also write a
>function with a descriptive name that returns a booleans value.
Bollocks. I don't care what the preferred style of the authors is; I have
my own. It's (aside from that one lvalue typo, which probably snuck in
during a copy/paste/alter) consistant. The code is -not- invalidated simply
because you can't be bothered to read it because it's -explicitly- written.
There's nothing -wrong- with the code per se. The only thing wrong is that
the buffering isn't working, which may or may not be something I did, or it
could be perl (I'd find that odd). And the buffering is not working in
perlio if you just depend on that and leave set[v]buf() out entirely,
either. That's how I -originally- had it.
I was asking for help on a buffering issue, not a debate on stylistic
differences of representing code. Someone says I didn't post enough to go
on, post the code--fine. I posted the code. Now you say I gave too much
to go on. Surreal. Pick one.
Thanks for the one good suggestion--which had pretty much nothing to do
with my actual problem. But thanks all the same, that was shorter, and I
got something out of the experience.
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: Mon, 29 Mar 2004 01:39:56 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: losing data on socket
Message-Id: <x78yhktor8.fsf@mail.sysarch.com>
>>>>> "V" == Vorxion <vorxion@knockingshopofthemind.com> writes:
V> The code looks fine when you don't have to pare down 1100+ lines to 472 or
V> so. :)
that isn't what he meant. your coding style needs to be cleaned up.
>> You are not using strictures. A program of a certain size (and yours
>> does qualify) will benefit from using strict along with lexical
>> variables. I wouldn't be surprised if your program behaved badly due to
>> too many global variables and actions-at-a-distance arising from that.
>> Therefore:
V> No, I'm certainly not using strict. I've tried that and it -insists- on
V> making you reference every variable by a package name if it's not lexical.
V> I -need- some package variables, period, and I see no reason to bloat the
V> code by referencing main:: everywhere.
you don't get it. strict is meant to help you. your bypassing it is not
eaier but harder. finding naming errors and symref stuff is much harder
without strict.
and you can declare file lexicals which is the best way to do globals
in a file. if the variables MUST be package then use our and you won't
need to fully qualify them everywhere. use the right tools for the job
and don't shirk your work on declaring things with my.
>> What are those curlies doing there? They are not wrong, but they serve
>> no purpose either. All they do is harm readability. Ditch them here and
>> everywhere else where you are using them.
V> I use curlies on every variable that is referenced as an rvalue,
V> period, the end. It's a matter of stylistic continuity. If I
V> -always- do it, it's never confusing, as compared to sometimes
V> using them, sometimes not.
that makes NO sense. braces for basic variable names are meant to be
used when you need to disambiguate them in "" string. they have almost
no other use. your excuse is weak and it means your coding style needs
to be improved.
>>> sub spawn;
>>
>> What's this for? You always use parens on functions (and no prototypes
>> either), so you don't need any forward declarations.
V> man perlipc
V> Talk to the developers themselves, since it's actually in the official
V> POD for perl. I removed the comment, but they said it was a forward
V> declaration.
not needed anymore. the pod for that must be wrong or you misunderstood.
V> The program has LOTS of lexicals. It's in that 800+ lines I cut loose to
V> try and post as little as possible.
but the lexicals won't help you find misspelled ones without using strict.
>>> ${cli_logfile} = '__FLTbogus', fl_die(27,"Daemon mode called without absolutely pathed working directory.");
>>
>> I find using the comma like this confusing. This line looks as though it
>> contains two statements. Don't unecessarily join them into on.
V> It does contain two statements. I learned this syntax from doing something
V> like:
V> BLOCKLABEL: {
V> $found_one++, last BLOCKLABEL if ${line} =~ /\Wone\W/;
V> ...
V> }
just because it is legal doesn't make it good code. comma is ok for
short statements that need to be executed together:
$foo = $bar, next if /blah/ ;
note that the example you quoted is like mine but it is not like your
real code. your code has two completely independent statements with no
reason to use comma. it misleads the reader of your code and is
obsfucating it. is that what you want others to think?
V> Since it worked there, I use it where possible to combine code. Works
V> fine. It was in the docs somewhere (probably the Camel) as an example of
V> how to emulate a 'case' type functionality.
it is BAD style to use it when not needed. horrible in fact. the code
that uses comma has a SINGLE STATEMENT MODIFIER so it needs the comma so
both statements will execute based on the if. your code has NO MODIFIER
so both statements ALWAYS EXECUTE. you gain nothing from the comma but a
long line of code that is hard to read.
V> Possibly not, but I prefer clean error messages that don't confuse users.
V> If I have to go in and debug, I can put it in when I test.
that makes no sense. how will you know what environment the user is in?
the messages from $! are fairly clear and useful.
>> I think you should try to decrease your character-count a bit. All those
>> braces make your code harder on the eye. I particularly hate
>>
>> ${child_pids{${child}}}
>> # should be
>> $child_pids{$child}
V> It's an rvalue. I'm simply being consistant, since if I need them
V> anywhere, it's inconsistant if they're not everywhere.
again, that makes NO sense. try being consistant and never use them
except when needed in "" strings.
>> Keep in mind that humans aren't very good at deciphering hordes of
>> nested delimiters (especially when they are all the same).
V> That's what the % key in vi (or the default matching mode in emacs) is for.
V> :)
that doesn't help someone reading the code on the web or usenet or with
more or cat or on paper. editing is not reading.
>> I suppose you got the idea by now. My honest suggestion would be to
>> dispose of this whole code and re-start from scratch. Before you do
>> so, find a consistent coding style that requires less characters
>> (I've seldom seen a program where the lines are that long
>> throughout the whole code). Maybe you have a preliminary read of
>> 'perldoc perlstyle' for a start. Apart from that, pay particular
>> attention to the scoping of your variables and try to use less of
>> them as well. In other spots, introduce a few variables where it
>> increases readability. The above while-condition is such an
>> example. For that you could also write a function with a
>> descriptive name that returns a booleans value.
V> Bollocks. I don't care what the preferred style of the authors is;
V> I have my own. It's (aside from that one lvalue typo, which
V> probably snuck in during a copy/paste/alter) consistant. The code
V> is -not- invalidated simply because you can't be bothered to read
V> it because it's -explicitly- written. There's nothing -wrong- with
V> the code per se. The only thing wrong is that the buffering isn't
V> working, which may or may not be something I did, or it could be
V> perl (I'd find that odd). And the buffering is not working in
V> perlio if you just depend on that and leave set[v]buf() out
V> entirely, either. That's how I -originally- had it.
bollocks to you too. style is important. you obviously don't get that
yet. in time you will. try working with your own code 10 years
later. hell, try it 6 months later. try having anyone else maintain your
code without running away screaming. your ego is writing checks you
can't cash. listen to what experience perl hackers have to say and don't
slam them.
V> I was asking for help on a buffering issue, not a debate on
V> stylistic differences of representing code. Someone says I didn't
V> post enough to go on, post the code--fine. I posted the code. Now
V> you say I gave too much to go on. Surreal. Pick one.
you post code (which you had to do) you get comments on it. this is
usenet. get used to it. get a thicker skin. get a better coding style.
V> Thanks for the one good suggestion--which had pretty much nothing
V> to do with my actual problem. But thanks all the same, that was
V> shorter, and I got something out of the experience.
and you should have gotten more. too bad your ego is in the way of
learning something. consistancy to a poor style is not useful to anyone
but yourself. and if you think you are the only one to ever maintain
your code, you are sadly mistaken. i doubt you will heed my words any
more than you did tassilo.
i won't bother to help you again. you are not ready to learn. come back
in a year when you have some proper humility and an open mind.
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: Sun, 28 Mar 2004 23:12:16 GMT
From: Richard Bell <rbell01824@comcast.net>
Subject: Re: LWP cookies
Message-Id: <kZI9c.26417$JO3.26173@attbi_s04>
Alan J. Flavell wrote:
> On Sun, 28 Mar 2004, Richard Bell wrote:
>
>
>>As to the headers cookies et al. They are the result of what I would
>>get if I actually visited 18 pages of forms in turn to build the query I
>>post. Moreover, the server is VERY picky about what it will dance with.
>
>
> If it works with a browser, I'm not sure why it wouldn't work with
> LWP. The theory is that you just have to call it in the right way
> (unless the server is misbehaving - in which case you're on entirely
> the wrong group for discussing WWW server problems).
In the course of this dance, I neglected to mention that the 18 previous
pages use frames and very heavy scripting (some Java, some VB). While
I'm new to LWP and don't really know, I'm under the impression that
frames and LWP don't get on well, to say nothing of the scripts. That
aside, the code to visit all 18 pages would ultimately be IMHO rather
worse than the mess with the headers. But that is, of course, just my
preference.
>
>
>> In deference to reality I just send them all along.
>
>
> If they're in scope for the request, and they're in the cookie jar
> already, the module should know what to do with them. Duplicating
> that function does indeed look like re-inventing the wheel, and the
> code was anything -but- aesthetic - which is often a warning sign.[1]
>
The point is interesting. I could, as you seem to suggest, force the
values into the cookie jar and let LWP do a bit more work. It turns out
that the only real benefit here would be to allow LWP to set the content
length
$req18->header('Content-Length' => '384');
and of course, remove my concern about the session cookie (I'm still not
entirely sure which it is)
Still, I'm not sure IMHO that going to the trouble to dump the cookies
into the jar is worth the return (this is, after all, a perl hack).
Still it's a thought.
>
>>It is worth noting that many of the cookies hold the context
>>associated with what would happen if I in fact visited all 18 pages
>>(so they are in that sense necessary for the POST to work, hardly,
>>as you mentioned, wheel invention).
>
>
> But surely the point is that you want to present the POST request 'as
> if' you had visited those pages - and that's done by pre-loading the
> cookie jar with the appropriate cookies.
>
> good luck
>
> [1] even if, speaking as a physicist, I can "write FORTRAN in any
> language" ;-)
To each his own. My real concern, however, remains concerning a cookie
value forced in the header v. one in the cookie jar as it concerns the
session cookie. It's working, I'm OK with it, but I'd like to be a bit
more sure if anyone knows the underlying behavior of LWP in this case.
Thanks for your interest.
R
------------------------------
Date: Sun, 28 Mar 2004 23:43:10 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: LWP cookies
Message-Id: <x7lllktu5u.fsf@mail.sysarch.com>
>>>>> "AJF" == Alan J Flavell <flavell@ph.gla.ac.uk> writes:
AJF> On Sun, 28 Mar 2004, Richard Bell wrote:
>> As to the headers cookies et al. They are the result of what I would
>> get if I actually visited 18 pages of forms in turn to build the query I
>> post. Moreover, the server is VERY picky about what it will dance with.
AJF> If it works with a browser, I'm not sure why it wouldn't work with
AJF> LWP. The theory is that you just have to call it in the right way
AJF> (unless the server is misbehaving - in which case you're on entirely
AJF> the wrong group for discussing WWW server problems).
to reinforce that, the whole design of LWP is to look like a browser and
that includes cookie management. you can easily see what cookies are
sent back and control what cookies you sent to the server.
here is some working (but edited) code i used to manage cookies with
LWP:
my $cookie_jar = $self->{'cookie_jar'} ||=
( $self->{'cookies_text'} ?
Load( $self->{'cookies_text'} ) :
HTTP::Cookies->new() ) ;
$cookie_jar->add_cookie_header( $request ) ;
my $response = $ua->request( $request ) ;
$cookie_jar->extract_cookies( $response ) ;
so just use that and stop doing all that manual header stuff. it gives
me headaches just thinking about it.
>> It is worth noting that many of the cookies hold the context
>> associated with what would happen if I in fact visited all 18 pages
>> (so they are in that sense necessary for the POST to work, hardly,
>> as you mentioned, wheel invention).
AJF> But surely the point is that you want to present the POST request 'as
AJF> if' you had visited those pages - and that's done by pre-loading the
AJF> cookie jar with the appropriate cookies.
exactly. just collect them all in the jar and use the same jar for your
requests. as with browsers only the requested cookies will be sent out
from the jar.
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: Mon, 29 Mar 2004 00:02:45 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: LWP cookies
Message-Id: <x7d66wtt96.fsf@mail.sysarch.com>
>>>>> "RB" == Richard Bell <rbell01824@comcast.net> writes:
RB> In the course of this dance, I neglected to mention that the 18
RB> previous pages use frames and very heavy scripting (some Java, some
RB> VB). While I'm new to LWP and don't really know, I'm under the
RB> impression that frames and LWP don't get on well, to say nothing of
RB> the scripts. That aside, the code to visit all 18 pages would
RB> ultimately be IMHO rather worse than the mess with the headers. But
RB> that is, of course, just my preference.
the backend scripting of java or vb makes NO difference on the client
side. only javascript can screw up LWP by making the buttons only
javascript and hard/impossible to click.
as for your 18 pages, it doesn't matter. www::mechanize can scrape that
in 18 calls. and all without ugly manual header code.
and www::mechanize handles frames as links so that is not a problem
either.
>>
RB> The point is interesting. I could, as you seem to suggest, force
RB> the values into the cookie jar and let LWP do a bit more work. It
RB> turns out that the only real benefit here would be to allow LWP to
RB> set the content length
RB> $req18->header('Content-Length' => '384');
RB> and of course, remove my concern about the session cookie (I'm still
RB> not entirely sure which it is)
then just let lwp handle it and stop worrying. you seem to want to
control stuff you don't NEED to control. lwp is smarter than you are
here. :)
RB> Still, I'm not sure IMHO that going to the trouble to dump the cookies
RB> into the jar is worth the return (this is, after all, a perl
RB> hack). Still it's a thought.
huh? it saves you all the code you wasted on headers and cookies. did
you see the code i posted? it is like 4 lines to handle all the cookie
stuff. and that included persistant cookies from a DB (the cookie init
stuff which needs to be edited).
RB> To each his own. My real concern, however, remains concerning a
RB> cookie value forced in the header v. one in the cookie jar as it
RB> concerns the session cookie. It's working, I'm OK with it, but I'd
RB> like to be a bit more sure if anyone knows the underlying behavior of
RB> LWP in this case.
if you are so concerned, look at the source. but you are wasting your
time (and ours to some extent) fighting over this. massive numbers of
programs have been written with LWP and most need cookie support. no one
else seems to go nutso over controlling the cookies like you do. you get
cookies, you return cookies. the server controls that just fine. only
when you need to manage cookies (such as with persistance like i had too
for login reasons) do you get into it more. and even then i never looked
at the cookies, i just stored/loaded them from the DB if needed.
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: 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 6321
***************************************
