in reply to calling an external program, from within a perl script

I assume you mean if (!$?) and not if (!?). Anyway.

From perldoc perlvar: 

       $?      The status returned by the last pipe close,
               backtick (``) command, or system() operator.  Note
               that this is the status word returned by the
               wait() system call (or else is made up to look
               like it).  Thus, the exit value of the subprocess
               is actually ($? >> 8), and $? & 127 gives which
               signal, if any, the process died from, and $? &
               128 reports whether there was a core dump.
               (Mnemonic: similar to sh and ksh.)

[download]

In other words, your process terminates with an exit status of zero (which should be correct), dying from signal 13, which happens to be SIGPIPE.

Enough hints? :-)

-- TMTOWTDI

Replies are listed 'Best First'.
Re: Re: calling an external program, from within a perl script
by softworkz (Monk) on Aug 09, 2001 at 21:32 UTC
    Nick,
    Try a variation of the following.
    system "U:\\foo\\bar\\FILENAME $input /x+ /y+ /z >$output";
    I've used something like this before where the FILENAME was an executable and the executable had some switches for various types of output. It worked on a win32 system. Have fun!
[reply]
Re: Re: calling an external program, from within a perl script
by nick (Sexton) on Aug 09, 2001 at 21:38 UTC 
    Ok, this explains the error level. However, it doesn't 
explain the fact that the command doesn't work from this 
perl script. However, it does work from the cmnd 
line, and also from a little 3 liner (in the examples 
above).

So I know the system call is working, because it can call 
the 3 line perl script. I know the command 'mkfs' is 
working, because I can run the 3 liner, and the command 
executes.

when I run the 'mkfs' command from the large perl script,
 even though ($? >> 8) may return a 0 exit code, the device 
is not created, because there is not XFS filesystem on the
device when I check after running it.

Also, if I grab the output with backticks, there is none.
 (and this is a verbose command, so there should be several 
lines of output when generating the XFS Filesystem).

Any thoughts?

- Nick
[reply]

      Let's see...

      • SIGPIPE is sent to the process when it tries to write to a pipe with no connected readers
      • mkfs -t fstype is just a wrapper that spawns the appropriate mkfs.fstype
      • It works fine on the command line
      I tried the script myself using mkfs -t ext2 /dev/fd0 and it worked fine. Messages were output to STDERR but no problem whatsoever. I don't have xfs so I can't test it under your conditions, but perhaps you can test the script under mine and see what happens.

      If it works fine, my guess is that mkfs.xfs expects some kind of interaction with the user (you mentioned a condition where --force was necessary) and it dies because it's not connected to a terminal.

      If it still does not work, experiment:

      • Is the error code still the same?
      • What happens using another device?
      • What happens using an illegal device on purpose?
      • What happens using anothe filesystem type?
      • And with an illegal filesystem type?
      • What happens with another command?
      • Does a shell line like echo `your command` work?
      And so on. By observing (hopefully) different behaviours, it should be possible to determine what triggers the problem. Hope this helps!

      -- TMTOWTDI

[reply]
[d/l]
[select]
        Maybe at this point it would be good to know that the main program is a CGI, therefore, the fact that I can write a simple perl script to run this command wil work when I run it from the command line, but wont when I run that same script from the CGI. (however, if I run a system call in the CGI for a command, like for instance, cat, ir works fine.
         
        Does this help at all?
         
        - Nick
[reply]

In Section Seekers of Perl Wisdom