I've done this a few times and have my preferred practice, which comes with no "best practice" recommendation, but its something for you to consider.

The basic thing is that I construct the main script as a standard, command line, switch driven script. I then construct another script using the appropriate gui framework -- I've used Tk and Win32::GUI -- and use it to present the options to the user for selection and have a button that simply runs the script in the background with the arguments the user has selected.

Then I generally use a piped-open to run the command; as that gives me the pid for use with kill should the user decide to abort, and gives me access to the output from the CLI script, which I can the present back to the user either when the script has ended, or dynamically as the run progresses.

This separation of concerns is a win-win in my book as it allows both scripts to be developed, tested and used independently, and also provides uncomplicated multi-tasking that ensures the GUI remains responsive without affecting the performance, or complicating the construction, of the CLI script that does the work.