[24652] in Perl-Users-Digest
Perl-Users Digest, Issue: 6816 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 3 13:52:02 2004
Date: Tue, 3 Aug 2004 10:51:13 -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 Tue, 3 Aug 2004 Volume: 10 Number: 6816
Today's topics:
Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <ceo@nospam.on.net>
Re: Parsing form POST without CGI.pm on Win32 <jurgenex@hotmail.com>
Re: Parsing form POST without CGI.pm on Win32 <noreply@gunnar.cc>
Re: Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <noreply@gunnar.cc>
Re: Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <spamtrap@dot-app.org>
Re: Parsing form POST without CGI.pm on Win32 <noreply@gunnar.cc>
Re: Parsing form POST without CGI.pm on Win32 <nobull@mail.com>
Re: Parsing form POST without CGI.pm on Win32 <ceo@nospam.on.net>
Re: Parsing form POST without CGI.pm on Win32 <ceo@nospam.on.net>
Re: Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <flavell@ph.gla.ac.uk>
Re: Parsing form POST without CGI.pm on Win32 <aaron@deloachcorp.com>
Re: Parsing form POST without CGI.pm on Win32 <sholden@flexal.cs.usyd.edu.au>
Re: Parsing form POST without CGI.pm on Win32 <bik.mido@tiscalinet.it>
Re: Parsing form POST without CGI.pm on Win32 <lv@aol.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 31 Jul 2004 23:20:24 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Parsing form POST without CGI.pm on Win32
Message-Id: <KM6dnaNCa5IO8pHcRVn-hA@eatel.net>
My Perl programs are developed in the Win32 environment. Some of my work
gets ported to the Unix OS.
I use the CGI.pm module to 'paramitize' form post data. Everything works
well with this great module.
However, I have a program that will be ran every ten seconds or so (maybe
more?). I use the CGI.pm just to parse the initial form post data into
parameters that I immediately place and work with in hashes (I love hashes).
We control the form post data, so I'm not terribly worried about problems
that the CGI.pm module tends too regarding such. This seems like a bit of
overkill just to parse parameters I know, but in Windows there is no STDIN
to parse form posts from like the Unix OS.
Does anybody have a work-around/solution/tip/anything to get around using
the CGI.pm for this instance?
Regards,
Aaron
------------------------------
Date: Sun, 01 Aug 2004 04:55:59 GMT
From: ChrisO <ceo@nospam.on.net>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <zJ_Oc.3614$iH4.2189@newssvr15.news.prodigy.com>
Aaron DeLoach wrote:
> My Perl programs are developed in the Win32 environment. Some of my work
> gets ported to the Unix OS.
>
> I use the CGI.pm module to 'paramitize' form post data. Everything works
> well with this great module.
>
> However, I have a program that will be ran every ten seconds or so (maybe
> more?). I use the CGI.pm just to parse the initial form post data into
> parameters that I immediately place and work with in hashes (I love hashes).
> We control the form post data, so I'm not terribly worried about problems
> that the CGI.pm module tends too regarding such. This seems like a bit of
> overkill just to parse parameters I know, but in Windows there is no STDIN
> to parse form posts from like the Unix OS.
Uh? Says who? Did you *try* any Perl scripts using STDIN? It works
just fine...? (And not just in Perl; of course there is a "standard
input.")
perl -e "print while (<STDIN>)"
Dude, this works fine!
Dude, this works fine!
^Z
>
> Does anybody have a work-around/solution/tip/anything to get around using
> the CGI.pm for this instance?
>
If you want to read and parse your own parameters, you can do that. I'm
not sure what "unnecessary overhead" you feel you are trying to avoid by
not using CGI.pm however. Maybe you could be more specific here. What
are you trying to avoid?
-ceo
------------------------------
Date: Sun, 01 Aug 2004 04:58:31 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <XL_Oc.3025$QA5.2159@nwrddc01.gnilink.net>
Aaron DeLoach wrote:
[...]
> but in Windows there is no STDIN
What gave you that idea?
Of course there is.
jue
------------------------------
Date: Sun, 01 Aug 2004 09:26:12 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <2n3k87FstlkqU1@uni-berlin.de>
Aaron DeLoach wrote:
> However, I have a program that will be ran every ten seconds or so
> (maybe more?). I use the CGI.pm just to parse the initial form
> post data into parameters that I immediately place and work with in
> hashes (I love hashes).
This is some code I'm using for parsing CGI data in a situation where
a plain CGI script is invoked very frequently:
my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}
It handles submissions via query-strings as well, but if your forms
(unlike mine) have multi-value fields, the above code would require
some mods.
> We control the form post data, so I'm not terribly worried about
> problems that the CGI.pm module tends too regarding such.
It's good that you control the data. That's always important. What
made you believe that CGI.pm makes a difference in that respect?
> ... in Windows there is no STDIN to parse form posts from like the
> Unix OS.
That's a misconception. What made you believe so?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 1 Aug 2004 02:54:29 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <uY2dnbT3OeRYPJHcRVn-rw@eatel.net>
"ChrisO" <ceo@nospam.on.net> wrote in message
news:zJ_Oc.3614$iH4.2189@newssvr15.news.prodigy.com...
> Aaron DeLoach wrote:
>
> > My Perl programs are developed in the Win32 environment. Some of my work
> > gets ported to the Unix OS.
> >
> > I use the CGI.pm module to 'paramitize' form post data. Everything works
> > well with this great module.
> >
> > However, I have a program that will be ran every ten seconds or so
(maybe
> > more?). I use the CGI.pm just to parse the initial form post data into
> > parameters that I immediately place and work with in hashes (I love
hashes).
> > We control the form post data, so I'm not terribly worried about
problems
> > that the CGI.pm module tends too regarding such. This seems like a bit
of
> > overkill just to parse parameters I know, but in Windows there is no
STDIN
> > to parse form posts from like the Unix OS.
>
> Uh? Says who? Did you *try* any Perl scripts using STDIN? It works
> just fine...? (And not just in Perl; of course there is a "standard
> input.")
Did I try!! I have been trying for a few days :-)
>
> perl -e "print while (<STDIN>)"
> Dude, this works fine!
> Dude, this works fine!
> ^Z
>
This does not work for me (Win XP Home/Perl 5.8.4)
> >
> > Does anybody have a work-around/solution/tip/anything to get around
using
> > the CGI.pm for this instance?
> >
>
> If you want to read and parse your own parameters, you can do that. I'm
> not sure what "unnecessary overhead" you feel you are trying to avoid by
> not using CGI.pm however. Maybe you could be more specific here. What
> are you trying to avoid?
The module is just so big. It seems like loading it for my cause is
counter-productive from a performance standpoint.
>
> -ceo
------------------------------
Date: Sun, 1 Aug 2004 02:57:41 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <Sc-dnSaWS8QcP5HcRVn-qQ@eatel.net>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:2n3k87FstlkqU1@uni-berlin.de...
> Aaron DeLoach wrote:
> > However, I have a program that will be ran every ten seconds or so
> > (maybe more?). I use the CGI.pm just to parse the initial form
> > post data into parameters that I immediately place and work with in
> > hashes (I love hashes).
>
> This is some code I'm using for parsing CGI data in a situation where
> a plain CGI script is invoked very frequently:
>
> my (%in, $buffer);
> if ($ENV{REQUEST_METHOD} eq 'POST') {
> my $len = $ENV{CONTENT_LENGTH};
> $len <= 131072 or die "Too much data submitted.\n";
> read(STDIN, $buffer, $len) == $len
> or die "Reading of posted data failed.\n";
> } else {
> $buffer = $ENV{QUERY_STRING};
> }
> $buffer =~ tr/+/ /;
> for (split /[&;]/, $buffer) {
> my ($name, $value) =
> map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
> $value =~ tr/\r//d; # Windows fix
> $in{$name} = $value;
> }
>
> It handles submissions via query-strings as well, but if your forms
> (unlike mine) have multi-value fields, the above code would require
> some mods.
Thank you for the algo.. but it doesn't work for me (Win XP Home/Perl
5.8.4)
What could be wrong?
>
> > We control the form post data, so I'm not terribly worried about
> > problems that the CGI.pm module tends too regarding such.
>
> It's good that you control the data. That's always important. What
> made you believe that CGI.pm makes a difference in that respect?
>
> > ... in Windows there is no STDIN to parse form posts from like the
> > Unix OS.
>
> That's a misconception. What made you believe so?
>
> --
> Gunnar Hjalmarsson
> Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 01 Aug 2004 10:17:43 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <2n3n8rFsa1vvU1@uni-berlin.de>
Aaron DeLoach wrote:
> Gunnar Hjalmarsson wrote:
>> This is some code I'm using for parsing CGI data in a situation
>> where a plain CGI script is invoked very frequently:
>>
>> my (%in, $buffer);
>> if ($ENV{REQUEST_METHOD} eq 'POST') {
>> my $len = $ENV{CONTENT_LENGTH};
>> $len <= 131072 or die "Too much data submitted.\n";
>> read(STDIN, $buffer, $len) == $len
>> or die "Reading of posted data failed.\n";
>> } else {
>> $buffer = $ENV{QUERY_STRING};
>> }
>> $buffer =~ tr/+/ /;
>> for (split /[&;]/, $buffer) {
>> my ($name, $value) =
>> map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
>> $value =~ tr/\r//d; # Windows fix
>> $in{$name} = $value;
>> }
>>
>> It handles submissions via query-strings as well, but if your
>> forms (unlike mine) have multi-value fields, the above code would
>> require some mods.
>
> Thank you for the algo.. but it doesn't work for me (Win XP
> Home/Perl 5.8.4)
> What could be wrong?
Your program, perhaps? ;-)
Please post a small, complete program that does not work for you as
expected, and you'll probably get the help needed to fix it.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 1 Aug 2004 03:43:27 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <6aGdnYdd7t-nMJHcRVn-iA@eatel.net>
I see someone else is up late ;-)
[..]
> Please post a small, complete program that does not work for you as
> expected, and you'll probably get the help needed to fix it.
Easy to do! Using your code (or any other code I got from books, etc) to
deal with the STDIN all produce the same. Not an error! Just nothing.
Your code died "Reading of posted data failed." which tells me that there
must be an issue with my OS for this object.
#!/usr/bin/perl -w
use strict;
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 100;
$CGI::DISABLE_UPLOADS = 1;
my (%in, $buffer);
if ($ENV{REQUEST_METHOD} eq 'POST') {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
read(STDIN, $buffer, $len) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for (split /[&;]/, $buffer) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$value =~ tr/\r//d; # Windows fix
$in{$name} = $value;
}
# print the hash
print header();
while (( my $k, my $v) = each %in)
{
print "$k=>$v<br>";
}
Thanks,
Aaron
>
> --
> Gunnar Hjalmarsson
> Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 01 Aug 2004 05:25:52 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <QOCdnYcKErG8KpHcRVn-pg@adelphia.com>
Aaron DeLoach wrote:
> The module is just so big. It seems like loading it for my cause is
> counter-productive from a performance standpoint.
You might want to have a look at CGI::Lite on CPAN. Plain and simple
form and cookie handling, without all the HTML output cruft that CGI.pm
has accumulated over the years.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Sun, 01 Aug 2004 13:54:15 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <2n43uuFru68bU1@uni-berlin.de>
Aaron DeLoach wrote:
> Gunnar Hjalmarsson wrote:
> I see someone else is up late ;-)
Not at all (this time...). It's the middle of the day here (in Sweden).
>> Please post a small, complete program that does not work for you
>> as expected, and you'll probably get the help needed to fix it.
>
> Easy to do! Using your code (or any other code I got from books,
> etc) to deal with the STDIN all produce the same. Not an error!
> Just nothing.
>
> Your code died "Reading of posted data failed."
My code, unlike CGI.pm, checks the return value from read(). ;-)
> which tells me that there must be an issue with my OS for this
> object.
So it seems, after all. I suppose you should have a look at the
configuration of your system. STDIN simply needs to be there...
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 01 Aug 2004 13:03:56 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <u9pt6bm5eb.fsf@wcl-l.bham.ac.uk>
"Aaron DeLoach" <aaron@deloachcorp.com> writes:
> I see someone else is up late ;-)
No you don't. You see that it is not the same time of day at all
places at the same time.
> Your code died "Reading of posted data failed." which tells me that there
> must be an issue with my OS for this object.
>
> #!/usr/bin/perl -w
>
> use strict;
> use CGI qw/:standard/;
> $CGI::POST_MAX=1024 * 100;
> $CGI::DISABLE_UPLOADS = 1;
What's the point of setting CGI's limits if you then don't use it?
> my (%in, $buffer);
> if ($ENV{REQUEST_METHOD} eq 'POST') {
> my $len = $ENV{CONTENT_LENGTH};
> $len <= 131072 or die "Too much data submitted.\n";
> read(STDIN, $buffer, $len) == $len
> or die "Reading of posted data failed.\n";
I think it is possible that the length doesn't match what you expected
because you didn't binmode(STDIN). Or am I imagining stuff. Does
read() honour binmode?
Still I can't see why if you are going to load CGI anyhow you don't
use it.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Sun, 01 Aug 2004 16:08:05 GMT
From: ChrisO <ceo@nospam.on.net>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <Fz8Pc.3624$Jb7.3587@newssvr15.news.prodigy.com>
Aaron DeLoach wrote:
> "ChrisO" <ceo@nospam.on.net> wrote in message
> news:zJ_Oc.3614$iH4.2189@newssvr15.news.prodigy.com...
>
>>Aaron DeLoach wrote:
>>
>>
>>Uh? Says who? Did you *try* any Perl scripts using STDIN? It works
>>just fine...? (And not just in Perl; of course there is a "standard
>>input.")
>
>
> Did I try!! I have been trying for a few days :-)
>
>
>>perl -e "print while (<STDIN>)"
>>Dude, this works fine!
>>Dude, this works fine!
>>^Z
>>
>
>
> This does not work for me (Win XP Home/Perl 5.8.4)
You might want to consider reinstalling Perl then. The above Perl
one-liner should work on Win32 without any problem. It strikes me that
something isn't right somehow, if you say this does not work.
>
>
>>>Does anybody have a work-around/solution/tip/anything to get around
>
> using
>
>>>the CGI.pm for this instance?
>>>
>>
>>If you want to read and parse your own parameters, you can do that. I'm
>>not sure what "unnecessary overhead" you feel you are trying to avoid by
>>not using CGI.pm however. Maybe you could be more specific here. What
>>are you trying to avoid?
>
>
> The module is just so big. It seems like loading it for my cause is
> counter-productive from a performance standpoint.
>
I thought someone else's suggestion of CGI::Lite was a good one.
-ceo
Live deliberately.
------------------------------
Date: Sun, 01 Aug 2004 16:12:12 GMT
From: ChrisO <ceo@nospam.on.net>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <wD8Pc.3625$gc7.1440@newssvr15.news.prodigy.com>
Gunnar Hjalmarsson wrote:
> Aaron DeLoach wrote:
>
>> Gunnar Hjalmarsson wrote:
>>
>>> This is some code I'm using for parsing CGI data in a situation
>>> where a plain CGI script is invoked very frequently:
>>>
>>> my (%in, $buffer);
>>> if ($ENV{REQUEST_METHOD} eq 'POST') {
>>> my $len = $ENV{CONTENT_LENGTH};
>>> $len <= 131072 or die "Too much data submitted.\n";
>>> read(STDIN, $buffer, $len) == $len
>>> or die "Reading of posted data failed.\n";
>>> } else {
>>> $buffer = $ENV{QUERY_STRING};
>>> }
>>> $buffer =~ tr/+/ /;
>>> for (split /[&;]/, $buffer) {
>>> my ($name, $value) =
>>> map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
>>> $value =~ tr/\r//d; # Windows fix
>>> $in{$name} = $value;
>>> }
>>>
>>> It handles submissions via query-strings as well, but if your
>>> forms (unlike mine) have multi-value fields, the above code would
>>> require some mods.
>>
>>
>> Thank you for the algo.. but it doesn't work for me (Win XP
>> Home/Perl 5.8.4)
>> What could be wrong?
>
>
> Your program, perhaps? ;-)
>
> Please post a small, complete program that does not work for you as
> expected, and you'll probably get the help needed to fix it.
He did, in a sense, provide an example by responding that the following
does NOT work on his machine:
perl -e "print while (<STDIN>)"
When I type and hit ENTER, this will echo...
When I type and hit ENTER, this will echo...
^Z
My thought is that if *this* does not work, something is wrong with the
Perl installation likely as not. (Aside from the fact I personally
can't trust what Windows decides to do with most everything, but that's
probably beside the point.)
-ceo
Live deliberately.
------------------------------
Date: Sun, 1 Aug 2004 14:48:12 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <6ZKdnWcgYICa1JDcRVn-jw@eatel.net>
[..]
> > #!/usr/bin/perl -w
> >
> > use strict;
> > use CGI qw/:standard/;
> > $CGI::POST_MAX=1024 * 100;
> > $CGI::DISABLE_UPLOADS = 1;
>
> What's the point of setting CGI's limits if you then don't use it?
We *are* using CGI.pm - we're trying to find a solution. Thye request was
for me to post some example code that dosen't work. The code I posted is
part of 300 lines.
>
> > my (%in, $buffer);
> > if ($ENV{REQUEST_METHOD} eq 'POST') {
> > my $len = $ENV{CONTENT_LENGTH};
> > $len <= 131072 or die "Too much data submitted.\n";
> > read(STDIN, $buffer, $len) == $len
> > or die "Reading of posted data failed.\n";
>
> I think it is possible that the length doesn't match what you expected
> because you didn't binmode(STDIN). Or am I imagining stuff. Does
> read() honour binmode?
>
> Still I can't see why if you are going to load CGI anyhow you don't
> use it.
Read the op, where I am trying to get away from this.
>
> --
> \\ ( )
> . _\\__[oo
> .__/ \\ /\@
> . l___\\
> # ll l\\
> ###LL LL\\
------------------------------
Date: Sun, 1 Aug 2004 14:52:12 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <adGdnV6oBaRq1JDcRVn-uQ@eatel.net>
I don't think it's the Perl installation. It just so happens that I did a
full mfg re-installation a couple of days ago. It didn't work before on Perl
5.8.2, and since I had to re-install everything I upgraded Perl to 5.8.4
also. Still not working.
Is anyone getting to STDIN using Win XP *Home Version* ? I'm beginning to
believe it might not be available in the home version.
"ChrisO" <ceo@nospam.on.net> wrote in message
news:wD8Pc.3625$gc7.1440@newssvr15.news.prodigy.com...
> Gunnar Hjalmarsson wrote:
>
> > Aaron DeLoach wrote:
> >
> >> Gunnar Hjalmarsson wrote:
> >>
> >>> This is some code I'm using for parsing CGI data in a situation
> >>> where a plain CGI script is invoked very frequently:
> >>>
> >>> my (%in, $buffer);
> >>> if ($ENV{REQUEST_METHOD} eq 'POST') {
> >>> my $len = $ENV{CONTENT_LENGTH};
> >>> $len <= 131072 or die "Too much data submitted.\n";
> >>> read(STDIN, $buffer, $len) == $len
> >>> or die "Reading of posted data failed.\n";
> >>> } else {
> >>> $buffer = $ENV{QUERY_STRING};
> >>> }
> >>> $buffer =~ tr/+/ /;
> >>> for (split /[&;]/, $buffer) {
> >>> my ($name, $value) =
> >>> map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
> >>> $value =~ tr/\r//d; # Windows fix
> >>> $in{$name} = $value;
> >>> }
> >>>
> >>> It handles submissions via query-strings as well, but if your
> >>> forms (unlike mine) have multi-value fields, the above code would
> >>> require some mods.
> >>
> >>
> >> Thank you for the algo.. but it doesn't work for me (Win XP
> >> Home/Perl 5.8.4)
> >> What could be wrong?
> >
> >
> > Your program, perhaps? ;-)
> >
> > Please post a small, complete program that does not work for you as
> > expected, and you'll probably get the help needed to fix it.
>
> He did, in a sense, provide an example by responding that the following
> does NOT work on his machine:
>
> perl -e "print while (<STDIN>)"
> When I type and hit ENTER, this will echo...
> When I type and hit ENTER, this will echo...
> ^Z
>
> My thought is that if *this* does not work, something is wrong with the
> Perl installation likely as not. (Aside from the fact I personally
> can't trust what Windows decides to do with most everything, but that's
> probably beside the point.)
>
> -ceo
>
> Live deliberately.
------------------------------
Date: Sun, 1 Aug 2004 22:14:34 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <Pine.LNX.4.61.0408012143350.31849@ppepc56.ph.gla.ac.uk>
On Sun, 1 Aug 2004, Aaron DeLoach blurted out atop a fullquote:
> I don't think it's the Perl installation.
What's going on here? We don't have the first idea what your Perl
expertise is (ignorance of usenet netiquette is something else); all
that we can see is that you've stumbled in with some muddled code and
you can't get it to work.
> It just so happens that I did a full mfg re-installation a couple of
> days ago. It didn't work before on Perl 5.8.2, and since I had to
> re-install everything I upgraded Perl to 5.8.4 also. Still not
> working.
I'm sorry, but this is no way to get help. If you're going to use
CGI.pm then there are recipes (e.g in the online resource material
that goes with the author's book[1]). I'd recommend trying them, and
then, at least, you would have proven code, quotable symptoms which
someone might recognise, and a decent lever on whatever installation
problem you might be experiencing. Then show what you've done, what
you expected to get, show what happened - copy/paste a manageable
amount of code that you tried and the resulting diagnostics, and
you'll find any number of capable folks here who will be only too
happy to help.
Debugging hand-knitted code in an environment that you're not yet
comfortable with is like working with a hand tied behind your back.
If you're *not* going to use CGI.pm at this stage, then you're only
giving yourself additional uncertainties. I really don't recommend
it. In this kind of situation, I would seriously suggest putting the
confusion aside for the time being, going back to basics, verifying
that you can make the various elements work which contribute to your
final requirement.
> Is anyone getting to STDIN using Win XP *Home Version* ?
I can't offer any practical comment on that.
> I'm beginning to believe it might not be available in the home
> version.
However, if that were so, I think even I would have heard about it.
Beware of Gunnar's advice - he knows what he's doing: his problem is
that he is all to ready to assume that everyone else does too. If you
have efficiency issues with CGI.pm startup, then there are better
approaches to the problem than to toss it all aside and try to knit
your own. "Don't optimise yet": get it to work first.
good luck
[1] http://www.wiley.com/legacy/compbooks/stein/source.html - but note
the date: I would recommend applying warnings and strict, and -T taint
checking too, over and above what you find in the published recipes.
------------------------------
Date: Sun, 1 Aug 2004 23:28:19 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <Sv-dnTDYg5ZzX5DcRVn-ig@eatel.net>
[..]
> What's going on here? We don't have the first idea what your Perl
> expertise is (ignorance of usenet netiquette is something else); all
> that we can see is that you've stumbled in with some muddled code and
> you can't get it to work.
What didfference does it make regarding Perl experience? My problem lies
with not being able to access STDIN data on Windows XP Home edition using
Perl (or any other language for that matter). It doesn't take a genious to
write a few lines of code to print the STDIN data. I'll bet you could even
do it.
The "muddled code" was an offering by a fellow human being who had something
to offer besides words that didn't add up to anything.
>
> > It just so happens that I did a full mfg re-installation a couple of
> > days ago. It didn't work before on Perl 5.8.2, and since I had to
> > re-install everything I upgraded Perl to 5.8.4 also. Still not
> > working.
>
> I'm sorry, but this is no way to get help. If you're going to use
> CGI.pm then there are recipes (e.g in the online resource material
> that goes with the author's book[1]). I'd recommend trying them, and
> then, at least, you would have proven code, quotable symptoms which
> someone might recognise, and a decent lever on whatever installation
> problem you might be experiencing. Then show what you've done, what
> you expected to get, show what happened - copy/paste a manageable
> amount of code that you tried and the resulting diagnostics, and
> you'll find any number of capable folks here who will be only too
> happy to help.
Your lack of knowledge (or effort to read) of the op and subsequent
discussions *really* shows here. You should have just stopped here, but you
continue to show yourself...
> Debugging hand-knitted code in an environment that you're not yet
> comfortable with is like working with a hand tied behind your back.
>
> If you're *not* going to use CGI.pm at this stage, then you're only
> giving yourself additional uncertainties. I really don't recommend
> it. In this kind of situation, I would seriously suggest putting the
> confusion aside for the time being, going back to basics, verifying
> that you can make the various elements work which contribute to your
> final requirement.
There's no confusion at all except on your part. This thread is actually
leading me to a viable solution. The last time I checked, that was what the
ng was for.
>
> > Is anyone getting to STDIN using Win XP *Home Version* ?
>
> I can't offer any practical comment on that.
>
> > I'm beginning to believe it might not be available in the home
> > version.
>
> However, if that were so, I think even I would have heard about it.
You should have said "...even *I* whould have heard about it"
> Beware of Gunnar's advice - he knows what he's doing: his problem is
> that he is all to ready to assume that everyone else does too. If you
> have efficiency issues with CGI.pm startup, then there are better
> approaches to the problem than to toss it all aside and try to knit
> your own. "Don't optimise yet": get it to work first.
It's been working for a long time now. I'm in the process of fine tuning
some code, that's all. If you would have read the op you would have been
aware that nothing was broken in the code to begin with.
Against my better judgement, let me get ignorant now...
You start off by insulting someone you know nothing about. You insuate
"ignorance" based on your perception of yourself. That, my friend, is
ignorant.
You should be more careful. I just might be the owner of several dozen
fortune 500 companies who likes to get dirty himself. In fact, *I* might be
the one writing *your* paycheck. But that doesn't make me better than you.
Nor does it put me on a level looking down on you. Be careful who you call
ignorant next time.
I know I shouldn't have said these things, but you pissed me off. I'll
regret having posted this later.
>
> good luck
>
Fuck off!
------------------------------
Date: 2 Aug 2004 06:53:44 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <slrncgrp7o.6j7.sholden@flexal.cs.usyd.edu.au>
On Sun, 1 Aug 2004 23:28:19 -0500, Aaron DeLoach <aaron@deloachcorp.com> wrote:
>
> I know I shouldn't have said these things, but you pissed me off. I'll
> regret having posted this later.
Yes you will, assuming you ever have another question for this newsgroup
that you actually want the maximum number of experienced perl coders,
trainers, and generally helpful types to see.
--
Sam Holden
------------------------------
Date: Mon, 02 Aug 2004 12:02:59 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <tptqg0tho2m4kvplsls3fb3uhk720egs5g@4ax.com>
On Sun, 1 Aug 2004 22:14:34 +0100, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
>> Is anyone getting to STDIN using Win XP *Home Version* ?
>
>I can't offer any practical comment on that.
Me neither...
>> I'm beginning to believe it might not be available in the home
>> version.
...but! I really can't believe it can be so. For one thing tons of
programs would not work, and this is a good reason, period. Also, why
shouldn't here been something that's been in *all* M$ OSen I know of?
Now that I think of it, I fear that the OP may have misunderstood what
Gunnar correctly suggested to him as a test and now, to be sure, I'm
referring directly to him: (i) open a terminal window (cmd.exe), (ii)
type
perl -e "print while <STDIN>"
at the prompt. Then type what you like, e.g. some words and press
return. You should get something like
C:\WINDOWS>perl -e "print while <STDIN>"
foo
foo
bar
bar
here the first "foo" and "bar" respectively are what you typed
literally, echoed to the terminal. The second ones are those output by
the script. To terminate press ^Z (eof in DOS/Win*).
HTH,
Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"
------------------------------
Date: Mon, 02 Aug 2004 12:36:07 -0500
From: l v <lv@aol.com>
Subject: Re: Parsing form POST without CGI.pm on Win32
Message-Id: <410e7b86$1_5@corp.newsgroups.com>
Aaron DeLoach wrote:
> I don't think it's the Perl installation. It just so happens that I did a
> full mfg re-installation a couple of days ago. It didn't work before on Perl
> 5.8.2, and since I had to re-install everything I upgraded Perl to 5.8.4
> also. Still not working.
>
> Is anyone getting to STDIN using Win XP *Home Version* ? I'm beginning to
> believe it might not be available in the home version.
>
I have no problem with STDIN on Win XP *Home Version*, I am however
using Perl v5.6.1, build 631, not 5.8 as you are.
Len
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
------------------------------
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 6816
***************************************
