Question

I was using Perl to read through each line of a file. I used a command line tool to call a service, and I noticed some interesting functionality that I can’t figure out how to search for. To the variable $cmd I assigned the command that invokes the service. If I refer to $cmd later in the code it prints out the command line argument, but if I refer to it as `$cmd`, however, it gives the output from running the service.

What is the explanation for this?

Answer 1

It works just like backquotes in the shell, which is why it is called that. See sh(1) for details. It captures the standard output alone, and nothing else. It sets the $? variable to the 16-bit wait status word.

This is all explained in the perlop(1) manpage:

qx/STRING/
`STRING`
A string which is (possibly) interpolated and then
executed as a system command with /bin/sh or its
equivalent. Shell wildcards, pipes, and redirections
will be honored. The collected standard output of the
command is returned; standard error is unaffected. In
scalar context, it comes back as a single (potentially
multi-line) string, or undef if the command failed.
In list context, returns a list of lines (however
you’ve defined lines with $/ or
$INPUT_RECORD_SEPARATOR), or the empty list if the
command failed.

Because backticks do not affect standard error: use
shell file descriptor syntax (assuming the shell
supports this) if you care to address this. To
capture a command’s STDERR and STDOUT merged together:

$output = `cmd 2>&1`;

To capture a command’s STDOUT but discard its STDERR:

$output = `cmd 2>/dev/null`;

To capture a command’s STDERR but discard its STDOUT
(ordering is important here):

$output = `cmd 2>&1 1>/dev/null`;

To exchange a command’s STDOUT and STDERR in order to
capture the STDERR but leave its STDOUT to come out
the old STDERR:

$output = `cmd 3>&1 1>&2 2>&3 3>&-`;

To read both a command’s STDOUT and its STDERR
separately, it’s easiest to redirect them separately
to files, and then read from those files when the
program is done:

 system("program args 1>program.stdout 2>program.stderr");

The STDIN filehandle used by the command is inherited
from Perl’s STDIN. For example:

open(BLAM, "blam")     || die "$0: can't open blam: $!";
open (STDIN, "<&BLAM") || die "$0: can't dup BLAM: $!";
print `sort`;

will print the sorted contents of the file blam.

Using single-quote as the delimiter protects the command
from Perl’s double-quote interpolation, passing the contents on
to the shell instead:

$perl_info  = qx(ps $$);    # that's Perl's $$
$shell_info = qx'ps $$';    # that's the new shell's $$

How that string gets evaluated is entirely subject to
the command interpreter on your system. On most
platforms, you will have to protect shell
metacharacters if you want them treated literally.
This is in practice difficult to do, as it’s unclear
which characters need escaping, or how. See perlsec for a
clean and safe example of a manual fork and exec
to emulate backticks safely.
On some platforms (notably DOS-like ones), the shell
may not be capable of dealing with multiline commands,
so putting newlines in the string may not get you what
you want. You may be able to evaluate multiple
commands in a single line by separating them with the
command separator character, if your shell supports
that (e.g. ; on many Unix shells; & on the Windows
NT CMD.COM shell).

Beginning with v5.6.0, Perl attempts to flush all
files opened for output before starting the child
process, but this may not be supported on some
platforms (see perlport(1)). To be safe, you may need to
set $| ($AUTOFLUSH in English) or call the
autoflush method of IO::Handle on any open
handles.

Beware that some command shells may place restrictions
on the length of the command line. You must ensure
your strings don’t exceed this limit after any
necessary interpolations. See the platform-specific
release notes for more details about your particular
environment.

Using this operator can lead to programs that are
difficult to port, because the shell commands called
vary between systems, and may in fact not be present
at all. As one example, the type command under the
POSIX shell is very different from the type command
under DOS. That doesn’t mean you should go out of
your way to avoid backticks when they’re the right way
to get something done. Perl was made to be a glue
language, and one of the things it glues together is
commands. Just understand what you’re getting
yourself into.

See I/O Operators for more discussion.

Here’s a simple example of using backticks to get the exit status of the first element in a pipeline:

$device = q(/dev/rmt8);
$dd_noise = q(^[0-9]+\+[0-9]+ records (in|out)$);
$status = `exec 3>&1; ((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) |  egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`;

---

EDIT

Well ok then, so maybe that wasn’t that simple an example. 🙂 But this one is.

I’d like to recommend the Capture::Tiny CPAN module as a simpler way to manage the output from external commands that you would normally run using backquotes. It has advantages and disadvantages, but I feel that for many people, the advantages outweigh any arguable disadvantageL

• The advantage is that you get to do all this without requiring deep knowledge of arcane mysteries of file-descriptor redirection the way the previous example did.

• The disadvantage is it’s yet another non-core dependency — something else you have to install from CPAN.

That’s really not bad for what you get.

Here’s an example of how easy it is:

NAME

Capture::Tiny – Capture STDOUT and STDERR from Perl, XS, or external programs

SYNOPSIS

    use Capture::Tiny qw/capture tee capture_merged tee_merged/;

     ($stdout, $stderr) = capture {
        # your code here
      };

     ($stdout, $stderr) = tee {
        # your code here
      };

     $merged = capture_merged {
        # your code here
      };

     $merged = tee_merged {
        # your code here
      };

DESCRIPTION

Capture::Tiny provides a simple, portable way to capture anything sent to STDOUT or STDERR, regardless of whether it comes from Perl, from XS code
or from an external program. Optionally, output can be teed so that it is captured while being passed through to the original handles. Yes, it
even works on Windows. Stop guessing which of a dozen capturing modules to use in any particular situation and just use this one.

There, isn’t that a whole lot easier?