I can't clearly understand what you are trying to do here. However, some pointers to possible solutions:
Study and understand interprocess communication and signals on POSIX systems.
Study and understand process forking and exec'ing on POSIX systems.
I have done really hairy bash scripts that were able to handle signals and were really bullet-proof - but only because I didn't have a choice in the matter (these were on black-box systems that had limited toolsets and options for building any type of application). This seems to be the other side of that coin.
The key aspect here is that once your application forks and exec's a separate application - by default it will wait for the child process to return before continuing execution of it's main thread of execution. You can avoid this, if you don't want it to wait by expressly forking and exec'ing the application in such a way that tells the parent process not to wait - which is one component of what you are trying to do I think. You can see this at work on the bash command line - try the following commands:
Code:
# bash
# exit
#
# exec bash
# exit
*bye bye*....connection dropped
# bash &
# exit
*bye bye*....connection dropped
In the first instance, by running the command 'bash' on the bash command line - we've forked and the exec'd a new instance of bash on the new 'fork' (this happens for every application/script you run normally by the way). At that point you have the new bash child running in the foreground, and the original bash parent in the background. When you Ctrl-C or type 'exit' in the shell, this child process dies, and the parent shell stops waiting and continues execution in the foreground.
In the second instance, we've used the 'exec' command. What this does is tells the parent bash shell to NOT fork -- and to simply exec a copy of the application over itself - in this case a new instance of bash. When you type 'exit' or Ctrl-c this time, it exits the terminal client because there was no parent process to return to after the application dies.
In the third example, we are expressly telling the foreground application NOT to wait for it's child process by placing the '&' symbol after the child process name. When it does this, it launches the child application in the background, and continues execution of the parent process in the foreground. If you type exit at this point, you will lose connectivity - but the background application may continue running after you drop offline (and will certainly be running in the background in parallel if you don't). You can also give processes signals to tell them what to do - for example, the 'nohup' command sends a signal to the new child process that tells it not to 'hangup' when the parent process dies. A variation of this technique is used when executing daemon processes - so they can run independently of any terminal and have their parent process as the init application (pid 1 generally) when they start.
Based upon what you've stated, the problem is also one of interprocess communication; the intermediate application must run, but stop in mid-stride to wait for some further actions to complete before continuing, and you want this to be automated. I don't know anything about 'airodump-ng' - so I'm assuming that you don't have the source code for that application; unless the application has a command interface that you can communicate with using interprocess communication, it sounds like you only have two choices - run the app and wait for it to return, or just run it in the background in parallel with the follow-on instructions. Both options do not support your specification. If, on the other hand, this application either has an active interprocess communications mechanism, or you have the source code, you could hack the source or configure a pipe to communicate with the process while it is running - to get the effect you are asking for. Either way will be a major undertaking - but these kinds of projects are what turns larvae into moths...hacker moths...
Another possibility would be to use signals to communicate with the application - this assumes that the application itself does not block (or handle) the signals you would want to use. The 'kill' command is not only used to kill applications, but you can also send signals to applications if you know their PID. If you are coding in c, perl or python - you could set up the plumbing to capture the PID of the child process when you fork and exec it. Failing that, you'll need to resort to some not-so-elegant means of grep'ing the process table for the application and parsing out the PID desired. Assuming we have the child PID (I'll leave the details of that up to you) - you can send the application the SIGSTOP signal via the command:
...where '1234' is the correct PID for the child process. If the application has default behavior - it should suspend operation when it receives the signal. Similarly, you can cause the application to continue running by sending it a SIGCONT signal via the command:
You can see all the various signal codes by running 'man signals' on the command line. Your code might look something like:
Code:
sudo echo what interface are you using?
read interface
airmon-ng stop $interface
macchanger --mac 00:11:22:33:44:55 $interface
airmon-ng start $interface
# kick airodump-ng off in the background:
airodump-ng $interface & <---- this is the ongoing action that I need to stop to continue with the rest of these.
# stop airodump-ng here:
A=`ps -ef | grep airodump-ng | grep -v grep | cut *something*`
kill -17 $A
echo Channel?
read Channel
echo ESSID?
read essid
echo BSSID?
read bssid
airodump-ng -c $channel -w $essid --bssid $bssid $interface
# resume running airodump-ng:
kill -19 $A
This still looks kludgey at best - don't know if that will actually do what you want, as your algorithm and requirements are fuzzy.
