Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an application that runs fine, with and without '&' when run directly from the terminal. However, if I try to execute it from a shell script, it works only if the trailing '&' is skipped. Thus, I am unable to start this process in background from inside the shell script.

<Path to My application> <options> &

The application window opens but makes no progress after that.

(The application is a modified(by me) version of qemu 0.13.0. When I run a disk image from that in background in a shell script, I get stuck with a black screen)

share|improve this question
the application name would help – RobotHumans Apr 15 '12 at 18:51
@aking Its a version of qemu modified by me. – AnkurVj Apr 15 '12 at 18:53
okay, does stock qemu work? – RobotHumans Apr 15 '12 at 18:54
@aking Yes, it does... – AnkurVj Apr 15 '12 at 18:55
up vote 8 down vote accepted

There's no need to background the application with the ampersand when it has a built-in option for doing so. Such is the case with qemu (unless you've removed it):

% qemu-kvm --help | grep daemon
-daemonize      daemonize QEMU after initializing
share|improve this answer

Do you see a message like

[1] suspended (tty output) myapplication

in the terminal? This message means that your program is trying to read from the terminal (probably because it's reading from its standard input). Since only a foreground program can read from the terminal, the program is suspended.

If you see this message, figure out why your program is reading. In desperation, try redirecting its standard input (myapplication </dev/null).

If you see no such message, it's some other bug in your program. Look at what your program is doing in a debugger or with strace.

share|improve this answer

There is a difference between running a backgrounded command from the terminal and from a shell script.

In a non-interactive shell (with job control disabled) the stdin of a backgrounded command gets implicitly redirected from /dev/null, which may cause your command not to execute at all.

See the POSIX standard on the Shell Command Language: Asynchronous Lists.

# compare where fd 0 is pointing to
sh -c 'sleep 10 & lsof -p ${!}'
sh -c 'sleep 10 0<&0 & lsof -p ${!}'
sh -c 'set -m; sleep 10 & lsof -p ${!}'
sh -ic 'sleep 10 & lsof -p ${!}'
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.