I'm going to run my QT program on a Linux-arm embedded device.

I tried to use system(cmd) function to run linux shell cmd in QT program.

cmd would be a audio playing command "aplay -N sound.wav"

If cmd is as above, there will be no sound come out of my linux device, and the process of the QT program will in the T state (traced or stopped).

If cmd is set as "aplay -N sound.wav &", things will work just fine.

My question is what caused that, why does the "&" background parameter matter in this case.

Thanks.

don't use system.

The system library function is designed to wait for the command to complete before it returns.

The way the system library function works is to:

1. fork a child process (the parent process waits for the child to exit)
2. the child process then uses the exec command to execute the shell to interpret the command.
3. the shell command parses and provides parameter expansion to the command, and sets up a parameter list
4. the shell then forks a child process (the parent NORMALLY waits for the process to terminate unless it is directed to not wait - the & on the command).
5. When this second child exits the exit status is used by the shell to set its exit status.
6. The exit status of the shell process (the child of step 1) is then used to create the return status from the system function.

The side effect of step 1, and step 4/5 is that the child process is cleaned up and the resources used released. Putting the & on the command only does half the job - the command process itself is not cleaned up until after the parent (in step 1) exits, where the shell that started that command does the clean up.

This is not a secure function - environment variables come into play that can affect what command is actually executed, and not the one you necessarily want. Even the shell used by the system command changes depending on environment variables, and this can cause additional side effects.

One of the side effects is how stdin/stdout/stderr are handled. The command may/may not have stdin/out redirected (it is a shell command after all) and different shells use slightly different syntax (especially when stderr is being redirected - look up the difference between cshell and bash).

For this reason it is usually better to directly use the fork system call, and create the exact parameter list you want. and decide what you want to do for the clean up (either handle it, or wait for its parent to handle it). It also turns out to be much faster in execution. (see SIGCHLD for how to catch and handle these exits).

1 members found this post helpful.