Parsing form POST without CGI.pm on Win32

Discussion in 'Perl Misc' started by Aaron DeLoach, Aug 1, 2004.

  1. 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
     
    Aaron DeLoach, Aug 1, 2004
    #1
    1. Advertising

  2. Aaron DeLoach

    ChrisO Guest

    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
     
    ChrisO, Aug 1, 2004
    #2
    1. Advertising

  3. Aaron DeLoach wrote:
    [...]
    > but in Windows there is no STDIN


    What gave you that idea?
    Of course there is.

    jue
     
    Jürgen Exner, Aug 1, 2004
    #3
  4. 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
     
    Gunnar Hjalmarsson, Aug 1, 2004
    #4
  5. "ChrisO" <> wrote in message
    news:zJ_Oc.3614$...
    > 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
     
    Aaron DeLoach, Aug 1, 2004
    #5
  6. "Gunnar Hjalmarsson" <> wrote in message
    news:...
    > 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
     
    Aaron DeLoach, Aug 1, 2004
    #6
  7. 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
     
    Gunnar Hjalmarsson, Aug 1, 2004
    #7
  8. 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
     
    Aaron DeLoach, Aug 1, 2004
    #8
  9. 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
     
    Sherm Pendley, Aug 1, 2004
    #9
  10. 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
     
    Gunnar Hjalmarsson, Aug 1, 2004
    #10
  11. "Aaron DeLoach" <> 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\\
     
    Brian McCauley, Aug 1, 2004
    #11
  12. Aaron DeLoach

    ChrisO Guest

    Aaron DeLoach wrote:
    > "ChrisO" <> wrote in message
    > news:zJ_Oc.3614$...
    >
    >>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.
     
    ChrisO, Aug 1, 2004
    #12
  13. Aaron DeLoach

    ChrisO Guest

    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.
     
    ChrisO, Aug 1, 2004
    #13
  14. [..]

    > > #!/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\\
     
    Aaron DeLoach, Aug 1, 2004
    #14
  15. 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" <> wrote in message
    news:wD8Pc.3625$...
    > 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.
     
    Aaron DeLoach, Aug 1, 2004
    #15
  16. 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.
     
    Alan J. Flavell, Aug 1, 2004
    #16
  17. [..]

    > 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
    >


    **** off!
     
    Aaron DeLoach, Aug 2, 2004
    #17
  18. PROBLEM IDENTIFIED Re: Parsing form POST without CGI.pm on Win32

    "Aaron DeLoach" <> wrote in message
    news:...
    > 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
    >
    >
    >


    I am posting this message to update the thread. Maybe it will help someone
    else.

    Throughout my trials with this subject I was lead to believe that WinXP Home
    did not expose the STDIN object. The problem is an Internet Explorer 6 issue
    (I don't know about earlier versions) . I could not read the STDIN via Perl
    when a form was submitted with IE 6. On NN and Opera the STDIN was
    available. Now I'll try to find the solution... (I'll update the ng)

    Regards,
    Aaron
     
    Aaron DeLoach, Aug 2, 2004
    #18
  19. Aaron DeLoach

    Sam Holden Guest

    On Sun, 1 Aug 2004 23:28:19 -0500, Aaron DeLoach <> 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
     
    Sam Holden, Aug 2, 2004
    #19
  20. On Sun, 1 Aug 2004 22:14:34 +0100, "Alan J. Flavell"
    <> 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"
     
    Michele Dondi, Aug 2, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charlie Taylor
    Replies:
    0
    Views:
    553
    Charlie Taylor
    Nov 18, 2003
  2. Don Glover the younger

    ASP, FORMS, POST METHOD And Post with out form(???)

    Don Glover the younger, Jul 13, 2003, in forum: ASP General
    Replies:
    0
    Views:
    513
    Don Glover the younger
    Jul 13, 2003
  3. Replies:
    7
    Views:
    181
    Michael Granger
    Feb 15, 2008
  4. Stefan Fischer
    Replies:
    2
    Views:
    357
    Stefan Fischer
    Feb 23, 2010
  5. Wenjie

    perl CGI related: form post failure

    Wenjie, Sep 3, 2003, in forum: Perl Misc
    Replies:
    0
    Views:
    114
    Wenjie
    Sep 3, 2003
Loading...

Share This Page