Question

Currently I am working with a embedded system that has the Linux OS. I need to run multiple application at the same time, and I would like them to be able to run through one script. A fellow colleague already had implemented this by using a wrapper script and return codes.

wrapperScript.sh $command & > output_log.txt
wrapperScript.sh $command2 & >output_log2.txt

But the problem arises in when exiting the application. Normally all the application that are on the embedded system require a user to press q to exit. But the wrapper script rather than doing that when it gets the kill signal or user signal, it just kill the process. This is dangerous because the wrapper script assumes that the application has the proper facilities to deal with the kill signal (that is not always the case and leads to memory leaks and unwanted socket connections). I have looked into automating programs such as expect but since I am using an embedded board, I am unable to get expect for it. Is there a way in the bash shell or embedded C to deal with multiple process have one single program automatically send the q signal to the programs.

I also would like the capability to maintain log and the output of the files.

EDIT:

Solution:

Okay I found the issue to the problem, Expect is the way to go about it in any situation. There is a serious limitation that it might slower, but the trade off is not bad in this situation. I decided to use Expect Scripting Language to implement the solution. There are certain trade off.

Pros:
* Precise control over embedded application
* Can Make Process Interactive to User
* can Deal with Multiple Process

Cons:
* Performance is slow

Answer 1

Use a pipe

Make the command read input from a named pipe. You’ll then be able to send it commands from anywhere.

mkfifo command1.ctrl
{ "$command1" <command1.ctrl >command1.log 2>&1;
  rm command1.ctrl; } &

Use screen

Run your applications inside the Screen program. You can run all your commands in separate windows in a single instance of screen (you’ll save a little memory that way). You can specify the commands to run from a Screen configuration file:

sessionname mycommands
screen -t command1 command1
screen -t command2 command2

To terminate a program, use

screen -S mycommands -p 1 -X stuff 'q
'

where 1 is the number of the window to send the input to (each screen clause in the configuration file starts a window). The text after stuff is input to send to the program; note the presence of a newline after the q (some applications may require a carriage return instead; you can get one with stuff "q$(printf \\015)" if your shell isn’t too featured-starved). If your command expects a q with no newline at all, just stuff q.

For logging, you can use Screen’s logging feature, or redirect the output to a file as before.