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

Dear Masters,

I have a Perl script that takes a binary and output the result to an array.

To simplify the matter, the binary only takes one parameter.

Now the problem I had is this. When I ran the binary straight from the shell with both parameter (A and B), like this:
  > some_binary.out A

   or 

  > some_binary.out B

[download]
Both of them gave some output as expected. But when I ran it on Perl script: 
#!/usr/bin/perl -w       

# aboved changed thanks to Mandrake

use Data::Dumper;

my $param  = 'A';  
# When I replace 'A' with 'B', it gives no output


my @output = `some_binary.out $param`;
chomp @output;

print Dumper \@output;

# gives $VAR1 = []; with 'B'

[download]
Only param 'A' gives some output, not 'B'. What could possibly cause this erratic behaviour? How can I effectively debug it?

---
neversaint and everlastingly indebted.......

Replies are listed 'Best First'.
Re: Strange Behaviour with Backticks
by Skeeve (Parson) on Jul 21, 2006 at 07:52 UTC
    What could possibly cause this erratic behaviour
    <Wild-Guessing>
    1. Different PATH variables in shell and perl - can be verified
    2. Output of B contains some strange bytes - check a hex dump
    3. .... don't know ...
    </Wild-Guessing>
    Try
    my @output = `some_binary.out $param | tee /tmp/controll.txt`;

    [download]
    and view the content of /tmp/controll.txt
    s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
    +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
[reply]
[d/l]
[select]

      neversaint asked me in the CB to post my xd (Hexdump) script I've put on my scratchpad for him to use.

      But as others may find it use ful too, I don't put it here but into the snippets section

      Hope you like it.

      s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
      +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
[reply]
[d/l]
[select]
      Dear Skeeve,
      I tried this: 
      my @output = `some_binary.out $param | tee /tmp/controll.txt`;

      [download]
      Although created, but "controll.txt" has no content in it.
      Still trying other options...

      ---
      neversaint and everlastingly indebted.......
[reply]
[d/l]
Re: Strange Behaviour with Backticks
by shmem (Chancellor) on Jul 21, 2006 at 08:14 UTC
    Did you over-simplify the matter? Are the parameters really 'A' and 'B' ? or are they something else? What binary are you running? Does it switch filehandles based on input? It's hard to tell.

    For debugging, that varies (by platform). First, check what's in $?, maybe your binary just dies. On linux, I'd run the perl script with strace -f -ff -o outputfile script.pl. For solaris, there's truss, ktrace on *BSD. Oh, and then - "use the source, luke" - if you have them, that is ;-)

    --shmem 

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
[d/l]
[select]
      Dear shmem,
      Did you over-simplify the matter?
      Well, actually it runs under a CGI script (See the code in my reply to Fletch below).
      I hope this doesn't make the difference...
      Are the parameters really 'A' and 'B' ? or are they something else?
      They consist of two characters ('AB','CD').
      What binary are you running?
      They are C binary.
      Does it switch filehandles based on input? It's hard to tell.
      Not so sure. How can I check that?

      ---
      neversaint and everlastingly indebted.......
[reply]
[d/l]
        Hello neversaint,

        I hope this doesn't make the difference...

        Well, it must not, but it could, as fletch notes below. Running under apache there's no tty. Environment is different. If under chroot, even more. Search paths could be different. UID/GID, etc.

        They consist of two characters ('AB','CD').

        Literally AB and CD What are these for? Floppy disk and hard disk labels?

        They are C binary.
        And what is it supposed to do? You scarce informations leave me to just guessing :-/
        Not so sure. How can I check that?
        As i told you. What OS are you running? If Linux, strace(1) the binary. You should see access(), open() and ioctl() calls. If they involve a tty when run with AB, but not when run with CD, there you have it. If running on some *BSD, ktrace(1) it and kdump(1) the output. If Solaris, use truss. If Windows, grab some stuff from Sysinternals^WMicrosoft.

        Do you have the source for the binary? a man page? any documentation? What's it's real name, anyways?

        --shmem 

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
---222----------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
[d/l]
[select]
Re: Strange Behaviour with Backticks
by Mandrake (Chaplain) on Jul 21, 2006 at 08:49 UTC
    Just wondering if your code indeed compile. 
    !#/usr/bin/perl -w

    [download]
    should be 
    #!/usr/bin/perl -w

    [download]
    Am I missing anything?
[reply]
[d/l]
[select]
Re: Strange Behaviour with Backticks
by syphilis (Archbishop) on Jul 21, 2006 at 08:44 UTC
    What could possibly cause this erratic behaviour?

    I doubt that it's erratic. The chomp() could be doing something that you didn't expect and don't want. What happens when you assign the output to a scalar instead of an array ?

    Cheers,
    Rob
[reply]
Re: Strange Behaviour with Backticks
by Fletch (Bishop) on Jul 21, 2006 at 13:34 UTC

    Another possibility is that the program is checking if it's stdout is a TTY or not and behaving differently based upon that. You could check by using your shell to redirect the output into a file and see if it behaves similarly. Might have to use Expect or IPC::Run to run it on a PTY if that's the case.

[reply]
      Dear Fletch,

      Thanks for the reply.
      ... the program is checking if it's stdout is a TTY or not and behaving differently based upon that.
      But, the strange thing in my setting is that one parameter ('A') works well, but not the other ('B')?

      From what I understand of your statement above, under both parameters the system call should fail. Please correct me if I'm wrong.
      You could check by using your shell to redirect the output into a file and see if it behaves similarly.
      Actually it runs under CGI script. And following your suggestion, I did pass the output into a file using standard open file handle. 
      #!/usr/bin/perl -w
use strict;
use CGI qw/:standard/;
use Data::Dumper;
use Carp;


print header();


my $param = 'A'; # or otherwise not working 'B'

my  $OUTFILE_file_name = 'out.txt';       

@output = `some_binary.out $param`;
chomp output;

open ( OUTFILE, '>', $OUTFILE_file_name )
    or croak "$0 : failed to open $OUTFILE_file_name : $!\n";

print OUTFILE Dumper \@output;

close ( OUTFILE );

      [download]
      But the out.txt shows nothing, i.e it gives: $VAR1=[];

      ---
      neversaint and everlastingly indebted.......
[reply]
[d/l]
[select]
        But, the strange thing in my setting is that one parameter ('A') works well, but not the other ('B')?

        From what I understand of your statement above, under both parameters the system call should fail. Please correct me if I'm wrong.

        There's nothing preventing the program from behaving differently in different branches of the code depending on command line options. 

        if( $ARGV[0] eq 'A' ) { 
  print "I work for a TTY only\n" if -t STDOUT;
}
if( $ARGV[0] eq 'B' ) {
  print "I work regardless of TTY-ness of STDOUT\n";
}

        [download]

        Having said that, one possibly might not call that "expected" behaviour (and if it were the case one would certainly be reasonable in expecting it to be documented). I was just tossing it out as something to be aware of.

[reply]
[d/l]

        You appear to be saying that you get different output from the executable when you run it as a cgi, ie. with web server account privileges, than you get when you run it from the command line, ie. when it has your userid privileges.

        It's quite common for web server account privileges to be severly restricted. Indeed, if they are not, your web server is likely vulnerable.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

Back to Seekers of Perl Wisdom