ActiveState Community

exec(), system() and visible console issue

Posted by milan on 2009-10-08 01:00
OS: Windows

Good morning,

I am trying to to a assemble a collection of various tools to run remotely on machines not located at our site, sub-sites, roaming users and so on. I have a central server share users can access when VPN'ing to us, once connected I have a little Perl script that basically does an xcopy on the content of the folder to only get newer stuff. Afterwards the updater launches the main utility which in turn does its stuff. My problem is with the updater.

I have Activestate Perl Dev Kit and I'm using PerlApp to compile the various scripts into binaries. One thing I want is for the updater to be invisible, I can achieve that by activating PerlApps Hide Console (GUI executable) option.

Within the updater, essentially a little 20 liner, I am doing this:
system("xcopy $source $destination /VARIOUS_OPTIONS_FOR_XCOPY");
followed by an:
exec("$workingdir\\BINARY_TO_RUN");

This works, it copies what I want to copy and runs the binary I need afterwards. However, when I active the PerlApp Option to not show the console the first system("xcopy...") fails. When I change system("xcopy...") to exec("xcopy...") it works. When I disable the Console Hiding in PerlApp it also works. Could anyone tell me what causes this? I think I understand the difference between system() and exec(), the first waiting for system() to finish, the second simply executing and continuing with whatever comes next. I don't understand the significance of the console though.

I see some similar differences in behaviour when runnign the executable by double clicking on it with Windows Explorer or running it via Start|Run as oppossed to first opening a command shell and running the binary from the shell.

Any insight would be greatly appreciated,thanks!

lado | Tue, 2009-11-10 03:12

If I understand correctly you don' twant the system statement to open console window when executing. If I am not wrong the system statement is not proper choice for that. Better choice would be Win32::Process (Win32::Process::Create()). That shall give you finer control how your spawned process will run (CREATE_NO_WINDOW flag is te one you're looking for