Otherwise: The back ticks return undef in scalar context when the called program fails, i.e. returns a non-null value. This is normally the case when wrong arguments are provided to the program. So your program probably prints the warning but it is not returned by the back ticks because the program call failed.

You could try to use open in order to read the output:

open (my $call, '-|', "$command 2>&1");
$output = join //, <$call>;
# or use { local $/; $output = <$call>; }
close ($call);
[download]

Update: It looks like the the back ticks return only undef when the given program couldn't be started, i.e. wrong name or permissions, but not when it fails. But checking if the output is really defined is still a good idea. Are you running the perl program under an other user, e.g. over CGI?

It seems that bsub somehow finds out that its standard error is not connected to a terminal, and then refuses to print the message.

Another option is to check $? to see if bsub exited with a 0 status. Commands usually exit with a non-zero status when there is an error condition. This won't get you the output, but at least you can tell if there was a problem:

my $output = qx("$command 2>&1");
if ($?) {
  # something wrong
}
[download]

Good point. I tried

  bsub -k >a 2>&1
[download]

and, indeed, a turns out to be empty. This means that bsub really behaves differently, when it sees that it is not connected to a terminal.
Ronald Fischer <ynnor@mm.st>

As an alternative to Expect, you could also use IO::Pty directly, as you're not really interacting with your bsub program. IO::Pty is the pseudo terminal that Expect is using under the hood.  In its most simple case this could look something like this

use IO::Pty;

sub run_in_pty {
    my @cmd = @_;

    my $pty = IO::Pty->new();
    
    my $pid = fork;  die "Couldn' fork: $!" unless defined $pid;
    if ($pid) {  # parent
        $pty->close_slave();
    
    } else {     # child
        my $slv = $pty->slave() or die "Couldn't get slave: $!";
        close $pty;
    
        open STDOUT, ">&".$slv->fileno() or die "Couldn't reopen STDOU
+T: $!";
        open STDERR, ">&".$slv->fileno() or die "Couldn't reopen STDER
+R: $!";
    
        exec @cmd;
        die "Couldn't exec(@cmd): $!";
    }

    return join '', (<$pty>);
}

my $cmd = "./bsub";

my $out = run_in_pty($cmd);

print "$cmd: '$out'\n";
[download]

Now, with this bsub-replacement (for demo purposes):

#!/usr/bin/perl

if (-t STDERR) {  # connected to terminal?
    print STDERR "msg-to-stderr\n";
}
print "msg-to-stdout\n";
[download]

you should get both messages with the above run_in_pty routine, while if you'd do on the commandline:

$ ./bsub >output 2>&1
[download]

you'd only have "msg-to-stdout" in the output file.

I'm afraid this doesn't work on native Windows, though... (Cygwin should be ok),  so hopefully, someone else knows a solution for this platform.

Actually, IO::Pty is not only missing on Windows (in the ActiveState implementation), but is also not available under Cygwin....
But thank you anyway for pointing this out.
-- 
Ronald Fischer <ynnor@mm.st>

http://perldoc.perl.org/IPC/Open3.html or http://search.cpan.org/~rsod/IPC-Run-0.80/lib/IPC/Run.pm

Cheers
Chris