[30354] in Perl-Users-Digest
Perl-Users Digest, Issue: 1597 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 31 00:10:02 2008
Date: Fri, 30 May 2008 21:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 30 May 2008 Volume: 11 Number: 1597
Today's topics:
Re: FAQ 4.17 How do I find yesterday's date? <simon.chao@gmail.com>
Re: Need help with a simple (I think) Perl script <ced@blv-sam-01.ca.boeing.com>
Re: Need help with a simple (I think) Perl script <szrRE@szromanMO.comVE>
Re: Need help with a simple (I think) Perl script xhoster@gmail.com
OT: SI units (was sorting a hash / 2008-06-01) sheinrich@my-deja.com
Re: Speed comparison of regex versus index, lc, and / / <benkasminbullock@gmail.com>
Re: Speed comparison of regex versus index, lc, and / / <1usa@llenroc.ude.invalid>
Re: Speed comparison of regex versus index, lc, and / / <1usa@llenroc.ude.invalid>
Re: Speed comparison of regex versus index, lc, and / / <ben@morrow.me.uk>
Re: The Importance of Terminology's Quality <conrad@lewscanon.com.invalid>
Re: The Importance of Terminology's Quality <fdsa@jklh.dili5na>
Re: The Importance of Terminology's Quality <conrad@lewscanon.com.invalid>
Re: The Importance of Terminology's Quality <sbour@niaid.nih.gov>
Re: The Importance of Terminology's Quality <jj47@mj56.1nv4l1d>
Re: The Importance of Terminology's Quality <arne@vajhoej.dk>
Re: Using perl locally on a Windows XP system <bill@ts1000.us>
Re: Win32::IE::Mechanize can't upload <bjoern@hoehrmann.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 30 May 2008 15:10:38 -0700 (PDT)
From: nolo contendere <simon.chao@gmail.com>
Subject: Re: FAQ 4.17 How do I find yesterday's date?
Message-Id: <af730d1b-c2bd-45d4-9597-44afdc5338d6@c65g2000hsa.googlegroups.com>
On May 30, 2:51=A0pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> nolo contendere wrote:
> > On May 30, 2:39 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> >> Peter J. Holzer wrote:
> >>> On 2008-05-29 00:54, David Combs <dkco...@panix.com> wrote:
> >>>> I'm still not sure, from what you guys have discovered,
> >>>> what the faq *should* say? =A0
> >>> The FAQ should say what it actually says (well, it could also mention
> >>> localtime/mktime - I'm not sure if the two modules it mentions are par=
t
> >>> of the core).
> >> They are not part of the core.
>
> >> The core module Time::Local + localtime() are sufficient to answer the
> >> FAQ question safely.
>
> >> =A0 =A0 =A0use Time::Local;
> >> =A0 =A0 =A0my $today =3D timelocal 0, 0, 12, ( localtime )[3..5];
> >> =A0 =A0 =A0my ($d, $m, $y) =3D ( localtime $today-86400 )[3..5];
> >> =A0 =A0 =A0printf "Yesterday: %d-%02d-%02d\n", $y+1900, $m+1, $d;
>
> > Doesn't Peter's post contradict this, since his example demonstrated
> > that the -86400 can lead to a result that is 2 days older?
>
> No. Can't you spot a difference between the above code and
>
> =A0 =A0 =A0print scalar localtime(time-86400);
>
> ??
>
oh, that was your whole point. sorry :-).
------------------------------
Date: Fri, 30 May 2008 16:11:15 -0700 (PDT)
From: "comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <7e3b4d7b-e7a4-449f-baf1-3fc1a99a63c2@c19g2000prf.googlegroups.com>
On May 30, 12:33 pm, "szr" <sz...@szromanMO.comVE> wrote:
> xhos...@gmail.com wrote:
> > "szr" <sz...@szromanMO.comVE> wrote:
> >> Ben Bullock wrote:
> >>> On Fri, 30 May 2008 01:16:39 +0200, Gunnar Hjalmarsson wrote:
>
> >>>> If you develop a Perl program in a CGI
> >>>> environment, you'd better make it a habit to
>
> >>>> use CGI::Carp 'fatalsToBrowser';
>
> >>>> It will make the browser display more meaningful error messages.
>
> >>> That may not always be a good habit, since the error messages are
> >>> meaningful only to the programmer:
>
> >>>http://schwern.org/~schwern/cgi-bin/unix2vms/
>
> >>> One can look for the messages produced by "die" in the error log
> >>> too, and if the code is in use by people other than the CGI
> >>> programmers (which it probably will be) it's probably a better bet
> >>> to not use the above outside of testing, since it will produce
> >>> something meaningless and confusing.
>
> > I wouldn't find it meaningless and confusing. It is quite clear that
> > an error has occurred, that is neither meaningless nor confusing. It
> > gives extra information, but I think I (being hypothetically not a CGI
> > programmer) would know enough to expect that this is meaningful to
> > someone else, if not to me, and that if I wish to discuss the error
> > with that someone else, it might be helpful to quote parts of it to
> > them, so in that way it is meaningful as well as not confusing.
>
> True (though I did not write what you were responding to.)
>
> >> One trick I used in the past was to have a $SIG{__DIE__} handler that
> >> check $ENV{REMOTE_ADDR} and if it was my own, print (custom) errors
> >> ($! and such), else just dies, leaving the error in the logs.
>
> > Unless by "just die" you mean use either the default CGI::Carp thing
> > or your own analog to it, by just dying you'd get an empty page, or a
> > partially rendered page, or a 500 error. I'd say that *that* is
> > meaningless and confusing!
>
> I was talking about a generic case. I should of said a default error
> page stating something weren't wrong, and a link allowing one to report
> it. My point was this is one way one could have some simple debugging
> when working on a live server (though I still recommend using a separate
> dev environment.)
I've used a default page that exposes only a sanitized message and
then
mails debug back to me.
--
Charles DeRykus
------------------------------
Date: Fri, 30 May 2008 16:48:16 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <g1q3o101ul6@news4.newsguy.com>
comp.llang.perl.moderated wrote:
> On May 30, 12:33 pm, "szr" <sz...@szromanMO.comVE> wrote:
>> xhos...@gmail.com wrote:
>>> "szr" <sz...@szromanMO.comVE> wrote:
>>>> Ben Bullock wrote:
>>>>> On Fri, 30 May 2008 01:16:39 +0200, Gunnar Hjalmarsson wrote:
>>
>>>>>> If you develop a Perl program in a CGI
>>>>>> environment, you'd better make it a habit to
>>
>>>>>> use CGI::Carp 'fatalsToBrowser';
>>
>>>>>> It will make the browser display more meaningful error messages.
>>
>>>>> That may not always be a good habit, since the error messages are
>>>>> meaningful only to the programmer:
>>
>>>>> http://schwern.org/~schwern/cgi-bin/unix2vms/
>>
>>>>> One can look for the messages produced by "die" in the error log
>>>>> too, and if the code is in use by people other than the CGI
>>>>> programmers (which it probably will be) it's probably a better bet
>>>>> to not use the above outside of testing, since it will produce
>>>>> something meaningless and confusing.
>>
>>> I wouldn't find it meaningless and confusing. It is quite clear
>>> that an error has occurred, that is neither meaningless nor
>>> confusing. It gives extra information, but I think I (being
>>> hypothetically not a CGI programmer) would know enough to expect
>>> that this is meaningful to someone else, if not to me, and that if
>>> I wish to discuss the error with that someone else, it might be
>>> helpful to quote parts of it to them, so in that way it is
>>> meaningful as well as not confusing.
>>
>> True (though I did not write what you were responding to.)
>>
>>>> One trick I used in the past was to have a $SIG{__DIE__} handler
>>>> that check $ENV{REMOTE_ADDR} and if it was my own, print (custom)
>>>> errors ($! and such), else just dies, leaving the error in the
>>>> logs.
>>
>>> Unless by "just die" you mean use either the default CGI::Carp
>>> thing or your own analog to it, by just dying you'd get an empty
>>> page, or a partially rendered page, or a 500 error. I'd say that
>>> *that* is meaningless and confusing!
>>
>> I was talking about a generic case. I should of said a default error
>> page stating something weren't wrong, and a link allowing one to
>> report it. My point was this is one way one could have some simple
>> debugging when working on a live server (though I still recommend
>> using a separate dev environment.)
>
> I've used a default page that exposes only a sanitized message and
> then mails debug back to me.
Yes I've used such things and can be convenient. It all depends on what
you're doing, and in what sort of environment.
--
szr
------------------------------
Date: 31 May 2008 02:44:07 GMT
From: xhoster@gmail.com
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <20080530224410.590$UI@newsreader.com>
sln@netherlands.co wrote:
> On 30 May 2008 18:44:40 GMT, xhoster@gmail.com wrote:
> >> Ben Bullock wrote:
> >> >
> >> > One can look for the messages produced by "die" in the error log
> >> > too, and if the code is in use by people other than the CGI
> >> > programmers (which it probably will be) it's probably a better bet
> >> > to not use the above outside of testing, since it will produce
> >> > something meaningless and confusing.
> >
> >I wouldn't find it meaningless and confusing. It is quite clear that an
> >error has occurred, that is neither meaningless nor confusing. It gives
> >extra information, but I think I (being hypothetically not a CGI
> >programmer) would know enough to expect that this is meaningful to
> >someone else, if not to me, and that if I wish to discuss the error with
> >that someone else, it might be helpful to quote parts of it to them, so
> >in that way it is meaningful as well as not confusing.
> >
>
> But, YOU won't be there.
I won't be where?
> The whole idea is programmed error recovery.
Presumably we've already tried that to the extent it can be done. Simple
errors that can be recovered should of course be recovered. But many
errors can't be recovered. If if a file that is critical can't be
accessed, or if a database that is critical cannot be connected to, then
there is no recovery to be done. Pretending otherwise is not error
recovery, it is just launching an infinitude of crap in which you refuse to
acknowledge the existence of a problem which obviously does exist.
> To just die, unless you can't recover is not an option in the corporate
> world. Built in recovery algo's are manditory in the money world.
My paycheck never seems to bounce, so the world I live in seems to be money
world.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Fri, 30 May 2008 14:52:40 -0700 (PDT)
From: sheinrich@my-deja.com
Subject: OT: SI units (was sorting a hash / 2008-06-01)
Message-Id: <909e7d1f-f37a-4e85-96de-c35f800e6a60@a70g2000hsh.googlegroups.com>
On May 30, 9:21 am, "dn.p...@gmail.com" <dn.p...@gmail.com> wrote:
...
>
> my %hash = () ;
> $hash{Calif}{San Jose}{max_temp} = 84 ;
> $hash{Calif}{San Fran}{max_temp} = 94 ;
> $hash{Calif}{Cupertino}{max_temp} = 38 ;
> $hash{Calif}{Fremont}{max_temp} = 66 ;
> $hash{Texas}{Dallas}{max_temp} = 72 ;
> $hash{Texas}{Austin}{max_temp} = 96 ;
> $hash{Texas}{Fort Worth}{max_temp} = 62 ;
> $hash{Mass}{Boston}{max_temp} = 96 ;
> $hash{Mass}{Framingham}{max_temp} = 55 ;
> $hash{Mass}{Worcester}{max_temp} = 55 ;
>
Excuse me, but is it really absolutely unthinkable to share your
information with the meager 99% percent of the world that has adopted
SI units decades(!) ago?
https://www.cia.gov/library/publications/the-world-factbook/appendix/appendix-g.html
Cheers, Steffen
------------------------------
Date: Sat, 31 May 2008 00:16:18 +0000 (UTC)
From: Ben Bullock <benkasminbullock@gmail.com>
Subject: Re: Speed comparison of regex versus index, lc, and / /i
Message-Id: <g1q5ci$mf$1@ml.accsnet.ne.jp>
On Fri, 30 May 2008 14:55:04 +0000, xhoster wrote:
> Ben Bullock <benkasminbullock@gmail.com> wrote:
>> In a recent discussion on this newsgroup, it was mentioned that "index"
>> is better for matching fixed strings than using regular expressions.
>
> Yes, it is.
Proof?
> If using regex to match fixed strings, you need to worry
> about special characters or syntax errors in the regex, like the problem
> with the literal string like "[l-c]" which we recently witnessed here.
That was exactly the discussion I was referring to. I said to use a
regex with \Q and \E, and Jurgen Exner said that "index" was the
correct tool for the job. I'm continuing that discussion on a separate
thread, since some time has passed and this is a separate topic from
that. I think Mr Exner was incorrect.
> "Better" is a much bigger issue than merely faster.
OK, what is your definition of "better"?
> And of course, if you are interested in where the string matches (i.e.
> the return value of index, and not just whether or not it is -1) then it
> is simpler to get it from index than from a regex.
Really? Please edit the following to show me how:
#!/usr/local/bin/perl
use warnings;
use strict;
sub index_find
{
my ($text, $ss) = @_;
my @finds;
my $found = 0;
while (1) {
$found = index ($text, $ss, $found);
last if $found == -1;
push @finds, $found;
$found += length ($ss);
}
return \@finds;
}
sub regex_find
{
my ($text, $ss) = @_;
my @finds;
while ($text =~ /\Q$ss\E/g) {
push @finds, pos ($text) - length($ss);
}
return \@finds;
}
my $text = <<EOF;
xhoster is the coolest perl programmer ever. xhoster is the
greatest. xhoster is the champion. xhoster is a babe magnet.
EOF
my $ss = "xhoster";
for (\&index_find, \®ex_find) {
print "String found at ", (join ", ",@{&{$_}($text, $ss)}),"\n";
}
It's possible to reduce the while (1) in the first line to something like
while (($found = index ($text, $ss, $found)) != -1) {
of course, but that doesn't make it simpler.
------------------------------
Date: Sat, 31 May 2008 01:49:14 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Speed comparison of regex versus index, lc, and / /i
Message-Id: <Xns9AAEDDF8A85B8asu1cornelledu@127.0.0.1>
Ben Bullock <benkasminbullock@gmail.com> wrote in
news:g1q5ci$mf$1@ml.accsnet.ne.jp:
> On Fri, 30 May 2008 14:55:04 +0000, xhoster wrote:
>
...
>> And of course, if you are interested in where the string matches
>> (i.e. the return value of index, and not just whether or not it is
>> -1) then it is simpler to get it from index than from a regex.
>
> Really? Please edit the following to show me how:
There is one change I would make to both routines. Cache length $ss
before the loop. On my machine, that cut down the time by about 40%.
> #!/usr/local/bin/perl
> use warnings;
> use strict;
>
> sub index_find
> {
> my ($text, $ss) = @_;
> my @finds;
> my $found = 0;
> while (1) {
> $found = index ($text, $ss, $found);
> last if $found == -1;
> push @finds, $found;
> $found += length ($ss);
> }
> return \@finds;
> }
>
> sub regex_find
> {
> my ($text, $ss) = @_;
> my @finds;
> while ($text =~ /\Q$ss\E/g) {
> push @finds, pos ($text) - length($ss);
> }
> return \@finds;
> }
Here is my modified version. I do find the index_find below simpler than
then your index_find.
#!/usr/local/bin/perl
use warnings;
use strict;
my $text = <<EOF;
xhoster is the coolest perl programmer ever. xhoster is the
greatest. xhoster is the champion. xhoster is a babe magnet.
EOF
my $ss = "xhoster";
sub index_find {
my @finds;
my $length = length $ss;
for ( my $found = index $text, $ss, 0;
$found >= 0;
$found = index $text, $ss, $found ) {
push @finds, $found;
$found += $length;
}
return \@finds;
}
sub regex_find {
my @finds;
my $length = length $ss;
while ($text =~ /\Q$ss\E/g) {
push @finds, pos ($text) - $length;
}
return \@finds;
}
use Benchmark qw( cmpthese );
cmpthese -30, {
'index' => \&index_find,
'regex' => \®ex_find,
};
__END__
C:\Temp> v
Rate regex index
regex 194450/s -- -4%
index 202488/s 4% --
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Sat, 31 May 2008 02:08:19 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Speed comparison of regex versus index, lc, and / /i
Message-Id: <Xns9AAEE134B5EAEasu1cornelledu@127.0.0.1>
"A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote in
news:Xns9AAEDDF8A85B8asu1cornelledu@127.0.0.1:
...
>> while ($text =~ /\Q$ss\E/g) {
Changing this to
while ( $text =~ /\Q$ss\E/og ) {
makes regex_find faster by about 1%.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Sat, 31 May 2008 04:12:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Speed comparison of regex versus index, lc, and / /i
Message-Id: <mas6h5-nt11.ln1@osiris.mauzo.dyndns.org>
Quoth "A. Sinan Unur" <1usa@llenroc.ude.invalid>:
>
> Changing this to
>
> while ( $text =~ /\Q$ss\E/og ) {
>
> makes regex_find faster by about 1%.
my $rx = qr/\Q$ss/;
...
while ($text =~ /$rx/g) {
is both clearer and safer. If the program is modified so that $ss is
actually variable (say, the whole thing is made into a sub) then /o
would cause it to fail in ways that are rather hard to diagnose.
Note that m// will only use the precompiled form of the qr// if the
$rx is the only thing in the match. Something like /^$rx/ or
/$rx1|$rx2/ or even / $rx/x will cause the regex to be recompiled
every time all over again.
Ben
--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * ben@morrow.me.uk
------------------------------
Date: Fri, 30 May 2008 19:11:01 -0400
From: Lew <conrad@lewscanon.com.invalid>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <v-2dnSYQWMbyFN3VnZ2dnUVZ_rmdnZ2d@comcast.com>
John Thingstad wrote:
> Perl is solidly based in the UNIX world on awk, sed, bash and C.
> I don't like the style, but many do.
Please exclude the Java newsgroups from this discussion.
--
Lew
------------------------------
Date: Fri, 30 May 2008 16:23:05 -0700
From: "Gordon Etly" <fdsa@jklh.dili5na>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <6abgirF358rgoU1@mid.individual.net>
Lew wrote:
> John Thingstad wrote:
> > Perl is solidly based in the UNIX world on awk, sed, bash and C.
> > I don't like the style, but many do.
> Please exclude the Java newsgroups from this discussion.
Why? Do you speak for everyone in that, this, or other groups?
--
G.Etly
------------------------------
Date: Fri, 30 May 2008 19:33:22 -0400
From: Lew <conrad@lewscanon.com.invalid>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <u92dncc7VuoxE93VnZ2dnUVZ_hydnZ2d@comcast.com>
Gordon Etly wrote:
> Lew wrote:
>> John Thingstad wrote:
>
>>> Perl is solidly based in the UNIX world on awk, sed, bash and C.
>>> I don't like the style, but many do.
>
>> Please exclude the Java newsgroups from this discussion.
>
> Why? Do you speak for everyone in that, this, or other groups?
I don't know why you'd even want to impose your Perl conversation on the Java
group in the first place, troll.
Plonk.
--
Lew
------------------------------
Date: Fri, 30 May 2008 16:40:39 -0700
From: "Stephan Bour" <sbour@niaid.nih.gov>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <Zf00k.2464$uE5.1601@flpi144.ffdc.sbc.com>
Lew wrote:
} John Thingstad wrote:
} > Perl is solidly based in the UNIX world on awk, sed, bash and C.
} > I don't like the style, but many do.
}
} Please exclude the Java newsgroups from this discussion.
Did it ever occur to you that you don't speak for entire news groups?
Stephan.
------------------------------
Date: Fri, 30 May 2008 16:55:24 -0700
From: "Gordon Etly" <jj47@mj56.1nv4l1d>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <6abifdF2rpb7bU1@mid.individual.net>
Lew wrote:
> Gordon Etly wrote:
> > Lew wrote:
> > > John Thingstad wrote:
> > > > Perl is solidly based in the UNIX world on awk, sed, bash and C.
> > > > I don't like the style, but many do.
> > > Please exclude the Java newsgroups from this discussion.
> > Why? Do you speak for everyone in that, this, or other groups?
> I don't know why you'd even want to impose your Perl conversation on
> the Java group in the first place, troll.
If you even bothered to check, you would see that, 1, this thread was
not exclusive to Perl, and 2, I was not a participant,
mr-I-speak-for-everyone.
--
G.Etly
------------------------------
Date: Fri, 30 May 2008 21:35:47 -0400
From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <4840ab73$0$90274$14726298@news.sunsite.dk>
Stephan Bour wrote:
> Lew wrote:
> } John Thingstad wrote:
> } > Perl is solidly based in the UNIX world on awk, sed, bash and C.
> } > I don't like the style, but many do.
> }
> } Please exclude the Java newsgroups from this discussion.
>
> Did it ever occur to you that you don't speak for entire news groups?
Did it occur to you that there are nothing about Java in the above ?
Arne
------------------------------
Date: Fri, 30 May 2008 17:33:42 -0700 (PDT)
From: Bill H <bill@ts1000.us>
Subject: Re: Using perl locally on a Windows XP system
Message-Id: <cc563d2c-0114-428c-9298-a05db996d1b9@d77g2000hsb.googlegroups.com>
> >> So you could have said "It is trivial to do so, check out this site,
> >> or google for this software." Probably would have been faster on your
> >> end and would have gotten a "thank you sinan" and a few nice thoughts
> >> on my end.
>
> > Yeah, I thought a pointer to some answer would have been nice too.
>
> Well, OK then.
>
> The OP did not specify which web server he wanted to install. Therefore,
> I did not post any pointers.
>
> John Bokma has step-by-step instructions for installing Apache on
> Windows:
>
> http://johnbokma.com/windows/apache-virtual-hosts-xp.html
>
Thanks Sinan! I will look into this
Bill H
------------------------------
Date: Fri, 30 May 2008 22:10:53 +0200
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: Win32::IE::Mechanize can't upload
Message-Id: <qnn044ht3f7ne80b94cuqdfvs4r1kfq9fl@hive.bjoern.hoehrmann.de>
* Rodney wrote in comp.lang.perl.misc:
>I have a form on a webpage I am trying to automate. there is a 'file'
>field that I can't get to accept data. I've mapped the path down to
>the Win32::IE::Input module, and tried to set the value from that, but
>still nothing.
Internet Explorer does not allow you manipulate the value of the file
input control, you'll have to feed the source code to some other module
or manually construct the upload request.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
------------------------------
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 V11 Issue 1597
***************************************
