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

Monks,

I'm currently writing a GUI to allow some of our non-technical guys to run some scripts and apps without having to delve into the depths of a console.

I need to trap the output from the scripts/apps so that we can report it to the user afterwards for error detection. I was using `` to do this: 

# $cmd is defined earlier
my $result = `$cmd 2>&1`;

[download]
but this doesn't work for some of the scripts (those that call external applications): they simply die saying they can't find the external command.

If I substitute the backticks for system, all works as expected.

I've tried playing with chdir to ensure the working directory is that of the script/app, but this doesn't make any difference at all: the command still dies.

Can anyone see what I'm doing wrong, and why the backticks cause a different system call than using system? I'm running Perl 5.004.04 on Sun Solaris.

Thanks in advance for your help.

-- Foxcub
#include www.liquidfusion.org.uk

Replies are listed 'Best First'.
Re: Inconsistent system call from backticks vs system()
by tilly (Archbishop) on Jul 01, 2003 at 14:39 UTC
    Both backquotes and system should pass their argument to the shell, which will do the same thing with that. Therefore they should not behave differently up to the point where the command has started up.

    This suggests to me that the difference in behaviour is in the external command itself. One wild guess is that the external command is testing whether or not it is talking to a tty, and then dying if not? (And then a poorly written error-report somewhere along the chain is lying to you about what is wrong...) You can check this by seeing if it will refuse to let its output be piped into another program. If this is the problem, you should be able to fix the problem with Expect or the older Comm.pl library. (You might have to dig around for a version/variation that will work on 5.004_04.)

    Good luck...

[reply]
Re: Inconsistent system call from backticks vs system()
by hardburn (Abbot) on Jul 01, 2003 at 13:49 UTC

    Does $cmd use an absolute path, or relative? If relative, it probably means that the program isn't in $ENV{PATH}. You're probably better off using an absolute path anyway.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]
      Absolute. That was something I thought about, which is why I tried playing with chdir, just in case.

      It literally seems like an inconsistency in the way system and the backticks handle the system call - as I said, if I substitute one for the other, it all works happily.

      -- Foxcub
      #include www.liquidfusion.org.uk

[reply]
[d/l]
[select]
Re: Inconsistent system call from backticks vs system()
by cbro (Pilgrim) on Jul 01, 2003 at 14:09 UTC
    You may want to read this. That way I don't have to get too detailed. But in general:
    When you run a command with backticks you should not need to redirect using the 2>&1. All output from the program will be redirected to your variable(AFAIK); when you want to capture output, use the backticks...not system(). Try removing the 2>&1 and see if you get the behavior you expected when using backticks.
    HTH,
    Chris
[reply]
[d/l]
[select]
      The reason for the 2>&1 is to trap STDERR as well as STDOUT, as perlop explains in its examples.

      I'm aware that system() doesn't trap output, and I don't intend using it, but unless I can get the backticks to work as I expect them to (system with STDOUT and STDERR trapping) I'll have to think of some other way to do this :/

      Thanks for the feedback.

      -- Foxcub
      #include www.liquidfusion.org.uk

[reply]
[d/l]
[select]
        I know why you used 2>&1. But I'm saying that w/backticks you shouldn't need to trap. UPDATE: Deleted example Ahh, but w/further testing...I found that it was the C program printing. I did need the trap, and I was incorrect on my previous post. I apologize. (It did work fine w/the trap however. The post below mine makes a good point about the './' and a possible path issue)
        Chris
[reply]
[d/l]
Re: Inconsistent system call from backticks vs system()
by fglock (Vicar) on Jul 01, 2003 at 14:24 UTC

    With backticks, you might have to add './' to the script name, in order for the shell to look in the current directory (do you have '.' in your path?)

    With system(), using a list of parameters, perl doesn't go through the shell.

[reply]
      If the 2>&1 trick works, then he is going through the shell.
[reply]
        If the 2>&1 trick works, then he is going through the shell.

        Actually, if the only "shell meta characters" in your command are a trailing "2>&1", then Perl will still avoid using the shell and simply redirect STDERR to STDOUT after it forks but before it execs.

        I think this feature was added to Perl fairly recently and I have yet to notice it having been documented.

                        - tye
[reply]
[d/l]
Re: Inconsistent system call from backticks vs system()
by bluto (Curate) on Jul 01, 2003 at 17:41 UTC
    Perhaps PATH is set up differently in backticks than in system. I can't say I've ever encountered that. If you haven't already done so, you could try and set up $ENV{PATH} in your script or explicitly do it in the backticks command ... 
    my $result = `PATH=/foo/bar/bin:/baz/bin:. $cmd 2>&1`;

    [download]

    bluto

[reply]
[d/l]
Re: Inconsistent system call from backticks vs system()
by hacker (Priest) on Jul 01, 2003 at 15:10 UTC
    At what point did IPC::Open3 not work for you?

    Try piping the output to a file, and see what errors (if any) appear in the file, something like:

      my $result = `$cmd &>/tmp/$$.debug`;

    [download]
[reply]
[d/l]

Back to Seekers of Perl Wisdom