arrange form data in same order as on form

Discussion in 'Perl Misc' started by bbxrider, Nov 13, 2003.

  1. bbxrider

    bbxrider Guest

    is there a way to sort (or other method) the 'method=post' data fields from
    a form into
    the same order they appear in the form
    when i use the following code there doesn't appear to be any particular
    order to how they are arranged

    read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    @pairs = split(/&/, $buffer);
    foreach $pair (@pairs) {
    ($name, $value) = split(/=/, $pair);
    $value =~ tr/+/ /;
    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    $FORM{$name} = $value;
    bbxrider, Nov 13, 2003
    1. Advertisements

  2. bbxrider

    Ben Morrow Guest

    Firstly, you *really* should be using CGI or CGI::Lite rather than
    parsing stdin yourself.

    If the browser doesn't return them in order, then the only way to put
    them back in order is to know what order they were in on the original
    form. One way of doing this might be to give them names beginning with
    '01', '02' etc.: if you generate the form yourself you can automate

    Note that hashes are inherently unordered: if you create a hash with
    more than one key there is *no* guarantee about the order you will get
    the keys back in when you list them. If you need there to be, then
    either keep a separate array of keys to hold the order, or use
    Tie::IxHash from CPAN which does that for you.

    Ben Morrow, Nov 13, 2003
    1. Advertisements

  3. why do you care?
    this code is buggy. either write your own, taking into account all the fine
    points of the specs, or just use but don't use someone else's buggy

    A. Sinan Unur, Nov 13, 2003
    Hash: SHA1

    The CGI spec does not guarantee that the form variables will be submitted
    in any particular order, so you're out of luck.
    This is exceedingly bad code. Unless you really know what you're doing,
    and have strong reasons not to, you should use the CGI module.

    We keep seeing this exact same bad code posted to this newsgroup. Out of
    curiosity, where did you copy it from?

    - --
    $_ = reverse sort $ /. r , qw p ekca lre uJ reh
    ts p , map $ _. $ " , qw e p h tona e and print

    Version: PGPfreeware 7.0.3 for non-commercial use <>

    -----END PGP SIGNATURE-----
    Eric J. Roode, Nov 14, 2003
  5. Do you know the context in which that code is used? If not, you can't
    reasonably tell whether it's "buggy".
    That's important only if you are writing a general purpose function or
    module. What makes you think that that is what OP is about to do?
    That is one option.
    Gunnar Hjalmarsson, Nov 14, 2003
  6. bbxrider

    Ben Morrow Guest

    The OP is attempting to interpret a CGI POST request, as stated in the
    Original Post.
    It is important in all circumstances where the data being received is
    not entirely under your control; eminently the case in a CGI
    ....and by far the best[1], unless you are (a) very clever and (b) need to
    do something particular that doesn't do for you.

    The whole *point* of CPAN is so that people don't have to keep failing
    to solve the same difficult problems over and over again.


    [1] modulo equivalent alternatives, such as CGI::Lite.
    Ben Morrow, Nov 14, 2003
  7. I meant context in a more narrow sense, of course.

    Still don't understand what it is that makes the above code "buggy".
    What's important in those circumstances is that you validate the data
    properly, run the program in taint mode, etc. Using does not
    take care of everything, right?
    I'm not questioning the advantages with code reuse in general. I'm
    just (once again) reacting to the aggressive way, sometimes not to the
    point, in which some people here argue for using
    Gunnar Hjalmarsson, Nov 14, 2003
  8. The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer, and
    there's no attempt made to detect or handle this event. Without going
    to the effort of reading the original post I don't know for sure, but
    I'd bet there's at least three or four other instances where
    handles things correctly that the OP's code does not.
    No, but it removes one axis of variability from the list of things
    that could be buggy. Given the option of using known-good code and
    hacking something up yourself, why (other than learning excercises,
    which are surely valuable) would you not use the tested and verified

    Eric Schwartz, Nov 14, 2003
  9. Some kind of exception handling is most often useful, but the lack of
    it isn't exactly a _bug_, is it?
    None of us knows which of those "things" that are _applicable_ in OP's
    I very much dislike the aggressive way in which some people here
    advocate the use of CGI, and the lack of faith that is shown in
    people's own judge. The described attitude makes me suspicious and
    less inclined to listen. How about that for a reason? :)
    Gunnar Hjalmarsson, Nov 14, 2003
  10. Is this buggy?

    open(FH, '>', "/root/file");
    print FH @data;

    I'd say heck yeah, because there's no checking that FH was properly
    opened, and that's the exact same class of bug we're talking about in
    the OP.
    Does it matter? As long as there are any, it means that using
    (or some equivalent, such as CGI::Lite, or what-have-you) is a better
    solution than rolling it on your own. Again, I make exceptions for
    doing it for personal learning purposes, because it's good to learn
    how to do things, but it's just nuts to not use a module in a
    production environment.
    I know you're being snarky, but I'll answer it honestly: it sucks as a
    reason. It's juvenile and immature, and overlooks the real benefits
    in favour of rebellion for its own sake. It's not that I have a lack
    of faith in people's judgement, it's that I have never-- not *once*--
    seen hand-rolled CGI parsing code on this newsgroup that wasn't buggy.

    Most of the arguments against using, including "it's too slow",
    aren't based on facts, they're based on suppositions, and "well, it
    stands to reason". Sometimes they're based on facts, and then people
    usually agree that that's a bad case to use it in, but I'd
    conservatively estimate that 98% of the time it's the way to go.

    I'll grant you, there are times when it's a good idea to roll your own
    CGI parsing routines. Personal study is one. I can't think of any
    situation for which I'd want to that it doesn't already work
    for, but if there is one, that's a good reason-- though a better idea,
    IMO, is to fix and thus make everyone's life that much better.
    Sometimes you don't need the HTML generation routines, and in that
    case there are modules like CGI::Lite and others that do the parsing
    job for you.

    In the end, there are a gazillion ways to get it wrong, and only a
    very few ways to do it right. And people being people, the sort of
    person who thinks they're saving time and effort by not using
    (or equivalent) is not as a rule the sort of person that's going to
    take the very painstaking approach of reading the RFCs and following
    them correctly, leading to the

    10 Hey, it works for me.
    20 <tweak>
    30 Oh, crap, now it's broke. <code>
    40 GOTO 10

    loop we're all so painfully familiar with.

    Eric Schwartz, Nov 14, 2003
  11. OK, you can call it something else then. Let's assume you don't care about
    that. There is still the fact that

    will miss pairs separated by a semicolon. In addition, parameter names are
    not unescaped. What happens when the query string given is

    As Eric Roode pointed out, the same exact code has been posted here
    numerous times (e.g.
    so I assumed the OP was not relying on his own judgement, but using someone
    else's code. In that case, he is better off using

    A. Sinan Unur, Nov 14, 2003
  12. It seems to date back to 1996 or even earlier:
    A. Sinan Unur, Nov 14, 2003
  13. bbxrider

    bbxrider Guest

    thanks for all the help and opinions
    i'm just self learning perl and found some code at
    and some other searching google groups
    actually i dont even know what and cgi lite are but will surely find
    i dont' mean to try and just steal code, but have found that seeing, using
    and understanding examples
    really accelerates my learing curve
    what i've since found is that the variable containing the form input is in
    fact in the same order as the form
    this code keeps the original order
    foreach (split(/[&;]/, $buffer)) {
    s/\+/ /g ;
    ($name, $value)= split('=', $_, 2) ;
    $name=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
    $value=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
    print "$name = $value";
    $buffer{$name}.= "\0" if defined($in{$name}) ; # concatenate
    multiple vars
    $buffer{$name}.= $value ;
    i have already set up sql query based inserts that expect the data fields in
    order and since there are 67
    on the form i want to be able to reuse that code
    again thanks for the help, this is a great forum and would hope to return
    the help someday

    bbxrider, Nov 14, 2003
  14. Not applicable. Look at OP's original post again. Parameters submitted
    via forms using the POST method are not separated by semicolons.
    Nothing, since the code does not parse query strings.

    I know that you know better than that, Sinan. But now we are talking
    about the 'sacred cow', so the usually educated, logical posts
    from you are suddenly replaced with incorrect or questionable
    statements. It's anything but convincing.
    Gunnar Hjalmarsson, Nov 14, 2003
  15. Maybe true, when you look at it from a rational angle. But it's human.

    See my latest reply to Sinan. (This is my last post in this thread, I
    promise. :) )
    Gunnar Hjalmarsson, Nov 14, 2003
  16. bbxrider

    Ben Morrow Guest

    [please don't top-post]

    For CGI, type 'perldoc CGI' at a command prompt. CGI::Lite you would
    need to install. Note that the names of Perl modules are case-sensitive.
    Absolutely. Reading decent code is one of the best ways to learn. You
    do have to be sure your source is reliable, though: there is one hell
    of a lot of very bad Perl floating around the web.
    I don't think this is guaranteed, by which I mean that it may happen
    to work for you with your browser during this phase of the moon, but
    under other circumstances it may well not. If you need to keep
    separate track of the different paramaters, give them different
    names. Change whatever generates them to put a number on the end, or

    Ben Morrow, Nov 14, 2003
  17. Hmmmm ... Let's say I have been doing too much 'task-switching' today,
    leading to muddled thinking.
    It is not that ... Simply jumbled neural paths or something. I do

    A. Sinan Unur, Nov 14, 2003
  18. bbxrider

    Keith Keller Guest

    Hash: SHA1

    What if he wants to support GET in the future?
    What if he wants to parse query strings in the future?

    - --keith

    - --
    (try just my userid to email me)

    Version: GnuPG v1.2.3 (GNU/Linux)

    -----END PGP SIGNATURE-----
    Keith Keller, Nov 14, 2003
  19. bbxrider

    bbxrider Guest

    what is 'top-post' ???
    actually don't understand how the eric roode and first sinan unur posts were
    not subordinated to the post immediately above them,
    i simply use reply-to-group and it always subordinates to the post i'm
    responding to

    bbxrider, Nov 14, 2003
  20. [re:]
    Looking at the question and the answer, in isolation at least, I'm going
    to assume the use of "reason" there is irony. :)

    David H. Adler, Nov 14, 2003
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.