in reply to CGI.pm quirk

esharris

I don't see this style of calling convention documented anywhere, my files go back to 1998 ( CGI.pm v2.38 ), so failing that I just loaded the thing up and ran it, heres the result:

Content-Type: text/html; charset=ISO-8859-1 <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"><head><title>T +est CGI</title> </head><body><p /><input type="checkbox" name="c1" value="ON" checked= +"checked" />c2</body></html>
So I cannot be sure what is going on!

jdtoronto

Replies are listed 'Best First'.
Re: Re: CGI.pm quirk
by esharris (Monk) on Dec 11, 2003 at 22:33 UTC
    If you just run it, it should work properly. When I run this with c1=1, the checked="checked" disappears on my system. Regarding the calling convention, the following excerpt is from http://stein.cshl.org/WWW/software/CGI/#debugging Debugging If you are running the script from the command line or in the perl debugger, you can pass the script a list of keywords or parameter=value pairs on the command line or from standard input (you don't have to worry about tricking your script into reading from environment variables). You can pass keywords like this: my_script.pl keyword1 keyword2 keyword3 or this: my_script.pl keyword1+keyword2+keyword3 or this: my_script.pl name1=value1 name2=value2 or this: my_script.pl name1=value1&name2=value2 If you pass the -debug pragma to CGI.pm, you can send CGI name-value pairs as newline-delimited parameters on standard input: % my_script.pl first_name=fred last_name=flintstone occupation='granite miner' ^D
      When I run your code snippet from the command line without the c1=1 command line argument, I get the same exact HTML output dumped to my screen as when I run it with the c1=1 command line argument.

      In other words, I cannot repeat the behavior you're describing. Does the snippet you provided repeat the problem? Or is there some piece of code that we're not seeing, which is necessary for the problem to surface?

      Update: I found the problem. "1" is not a valid status for a CGI.pm-created checkbox. In fact, it seems that the status expected by CGI.pm must be "ON" (case sensitive).

      For example, if I run the script on its own with no command line, you get: 'value=ON checked="checked"'

      If you run the script with "c1=1" on the command line, you are not passing CGI.pm what it wants to see, and instead, you get "value=ON" (without the 'checked="checked"' output).

      If you run the script with "c1=ON" on the command line, you are passing CGI.pm what it wants to see, and you do get 'value=ON checked="checked"'

      Perhaps CGI.pm is a little too selective by not interpreting "on" as being the same as "ON", but I don't see it as a problem for it to not consider "1" the same as "ON".

      Update 2: The source for CGI.pm is a maze to me. But I did glean a few theories by looking at it. It seems that the default behavior (no command-line args) is for a checkbox to be checked. If an argument is given, it must be "ON" for that default behavior to remain. What is unclear to me after my quick review of the source is how the 'rearrange' function works (must be from CGI::Utils, inherited into CGI.pm), and if it has any bearing on the issue at all. I also don't see where "ON" must be case sensitive, but apparently it must. There are a lot of "if ($status eq $value)...." constructs that are difficult to wade through. But that does tell me one thing. Where a Regular Expression match can deal to some extent with approximation (case insensitivity, alternation, etc.), 'eq' means identical to. While I haven't dug deep enough to know for sure, it sounds like an exact criteria must be met. That's probably one reason that ON works and 'on' or '1' doesn't.


      Dave