If you have a threaded perl, then you could start a thread at the start of your program and have it sit in a $q_cmds->dequeue() (Thread::Queue)loop. The button then uses $q_cmds->enqueue() to pass commands and parameters (or simply a "DO IT NOW" flag if the call is always the same) to the background thread and have it perform the backticks, system or IPC::Open2/3 as appropriate.

The main thread would then call $q_results->pending(); every now and again to check if the results are ready and $q_results->dequeue() to fetch and display them. That would allow the gui to remain responsive while the system commands are processed, which I assume is your aim.

Note: You need to create two queues before the thread is created, one foreground->background for the commands and one background->foreground for the results.

If the program your are calling has an intereactive mode, then you might be able to avoid the overhead of re-loading the program each time by using something like Expect or Expect::Simple in the background thread.

If the programs you are callling vary, you might be able to drive your shell this way, but the advantage diminishes as you would still be reloading the program itself each time.

Whether any of the effort is worth it will depend on how many and how long running the command you are running are, and whether there is anything that the foreground thread can logically be doing whilst the background thread is running.