Re: system() vs `backtick`

[etcshadow]

It depends on what the program is that you are running... but another possible issue is this: When running a command with system(), it is hooked up directly to your terminal, both for output and input... just as though a user had run that command at a shell prompt. When running a command with backticks, the input (as well as stderr) is still hooked up to the terminal, but the output stream is no longer the terminal... it is a pipe back to the parent (perl) process.

Why does this matter? Well some programs will produce different output (or just generally work differently) if they detect that they are attached to a terminal than if they are not. For example, at least on many linux variants (can't speak for all *nixes), the ps command will format it's output for a terminal (it sets the the output width to the width of your terminal) if it sees that it is outputting to a terminal, and otherwise it will truncate its output width at 80 characters. Likewise, ls may use terminal escape code to set the color of file-names to indicate permissions or types. Also, ls may organize its output into a pretty looking table when writing to a terminal, but make a nice neat list when NOT writing to a terminal.

Anyway, an easy way to check this out with your program is via a useless use of cat such as this:

[me@host]$ command
...
[me@host]$ command | cat
...

And comparing the differences in the output. You can see the same thing (sorta) happening between system and backticks with this (which simply checks to see if the output stream is attached to a terminal or not):

[me@host]$ perl -e 'print `perl -le "print -t STDOUT"`'

[me@host]$ perl -e 'system q(perl -le "print -t STDOUT")'
1
[me@host]$

As a shameless personal plug, I've actually written a node about how you can fool a process into thinking that it is connected to a terminal when it is not. This may not be of the utmost use to you in fixing your problem... but it is apropos.

[ambrus]

As a shameless personal plug, I've actually written a node about how you can fool a process into thinking that it is connected to a terminal when it is not. This may not be of the utmost use to you in fixing your problem... but it is apropos.

That is not needed here.

The OP says that the command runs fine in backticks, but hungs when runs with system. The program probably waits for input (confirmation) when run on a terminal, that's why it hangs. What the OP actually needs is to fool the program it's not running interactively, by calling it through a backtick or redirecting its stdout. This is much simpler to acheive. It might even be unneccessary if the program has some command line switch to force it not to ask questions. Many programs like rm or fsck have such an option: if you give rm a file for which you do not have write access, it promts you whether you want to delete it, you can override this with the -f switch or by redirecting its stdin. Running rm in backticks redirects the stdout which is not enough for rm: it prompts for a confirmation, even if stderr is redirected too, and if you don't see the error it appears to hang.