Gerard has asked for the wisdom of the Perl Monks concerning the following question:

Here is a code snippet,
use Data::Dumper; my $q = CGI->new(); my %var = $q->Vars(); my $log_file = 'log.txt'; open(LOG,">>$log_file") || err("Can't open log file: $!"); print LOG "URL: $ENV{REQUEST_URI}\n\n", Dumper(\%var,\%ENV)."\n\n", '=' x 60, "\n\n"; close LOG;
I am having problems with a script I wrote a few months ago. it was running on win 2000 and iis, now it is running on the same box with apache 1.3 which I have just installed for testing. Data Dumper prints out binary rubbish instead of the posted data that I was expecting. When I ran the same script a few months ago I got the results that I expected. The only thing that I have changed that I can think of is the webserver. Do I need to change anything in my script, or what else could be causing this sort of problem?
I can provide examples if required...

Thanks for your help.

Update: Unknown to me, the spec was changed, and they were sending this binary rubbish on purpose. Doesn't conform to normal http standards, but I was able to read the data by reading it from stdin before using CGI. Thanks to all for the advice, I was reminded to use binmode which proved to be correct as well.

Replies are listed 'Best First'.
Re: cgi->vars() unexpected results
by PodMaster (Abbot) on Apr 22, 2004 at 06:13 UTC
    <thinking_cap on>
    What is "binary rubbish" and what did you expect? Consider
    perl - 1=1 2=2 1=3 1=5 use CGI; use Data::Dumper; local $Data::Dumper::Useqq=1; local $Data::Dumper::Indent=1; print Dumper( scalar CGI->new->Vars ),$/; __END__ $VAR1 = { 1 => "1\0003\0005", 2 => 2 };
    That is what I expected because that's what the docs say to expect (the CGI and the Data::Dumper docs).
    </thinking_cap>

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      lol, ok. When the request method is post or get I would expect to see a list of value pairs much like what you have in your reply. This is what would normally happen, and was happening previously.

      Now the output from mode code snippet is
      $var1 { 'sd*%^$T$Y$^U 56y$%65 5645' => 'r455&^ 57%^& 547 7765 GFGFH +J&*4#$$^%^*&^ &^*%^ &* &* ASEqw ^&*&^ ^GHSRF&I*&^H %^%$% .....
      etc. The sort of thing that you get when you read a binary file in a text editor. Note: I just typed the above garbage as I am no longer at work, and don't have the file here.
      Thanks, Gerard.

      And Thanks for making me laugh, I've had a long day.
        Since I already /msg'd you, this here for posterity.
        • Don't forget to binmode LOG
        • You have to identify when the data is turning to rubbish and if in fact it is being turned to rubbish.
          1. You should verify your browser is sending what it's supposed to be sending.
          2. You should verify your program is receiving what it should be receiving (just binmode STDIN, read off STDIN before CGI.pm has a chance to touch it).
          3. After that you should ensure that CGI.pm is doing the right thing and that Data::Dumper (don't forget the Useqq option) is doing the right thing
        If applying binmode and Useqq does not solve your problem, my guess is that either your browser is sending weird stuff (likely depending on browser), or your apache is somehow mangling the input (anything could happen I guess).

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

Re: cgi->vars() unexpected results
by dave_the_m (Monsignor) on Apr 22, 2004 at 10:59 UTC
    If you are running this on Redhat 8/9, you could be running into the infamous utf-8 LANG problem. If the $LANG environment variable has a .utf8 on the end, then Perl 5.8.0 treats any input as being UTF8 encoded, even if it isn't. If this is the case, include a new setting for LANG in the script that starts up apache eg if $LANG is en_US.utf8, then add LANG=en_US to the script.
      Thanks, but I am running this on windows 2000 unfortunately.
      Cheers, Gerard
Re: cgi->vars() unexpected results
by diotalevi (Canon) on Apr 22, 2004 at 12:42 UTC
    This won't solve the problem you're faced with right now but I note that you neglected to lock the file being written to. Simultaneous requests can corrupt your log.