Re: [wxperl-users] Wx::Perl::ProcessStream

[Mark D. <mar...@zn...>]

Hi Eric,

Thanks for the pointer to ExecuteArgs;

Wx::Perl::ProcessStream->OpenProcess() now accepts an array ref or a command string as the first argument.

The array form is implemented simply as a call to Wx::ExecuteArgs;

Added a test and uploaded a new version.

Regards

Mark

Eric Wilhelm wrote:
> # from Mark Dootson
> # on Monday 26 March 2007 09:03 pm:
> 
>> I'd appreciate any comments and views on code, process and namespace.
> 
> I would really like to see some sort of list-context (\@command or 
> otherwise) functionality.  I've only briefly looked at the source, so 
> there might be some underlying implementation nit forcing your hand 
> here.
> 
>   my $process = Wx::Perl::ProcessStream->OpenProcess(
>     $command, $name, $eventhandler);
> 
> With a quick glance around, it seems that Wx.pm supports the 
> "wxExecute(char **argv,..." form via ExecuteArgs().  It also looks like 
> this would be no different than using ExecuteCommand() in terms of 
> firing the callback.  Perhaps detecting whether $command is an array 
> ref would do it?
> 
> Of course, I'm assuming here that the list form in ExecuteArgs() carries 
> all of the not-running-a-shell benefits of `exec(@list)` (such as "no 
> need to escape spaces in filenames" to name one very common example.)  
> If I'm wrong, ugh.  See also:  execvp(3).  The wx docs aren't exactly 
> clear on what happens so ... at least the unix implementation 
> ("src/unix/utilsunx.cpp") reads as if they've reinvented shell 
> escaping.  Neat.  So, maybe the semicolon ends up as an argument (I 
> think perl goes out of its way to fire-up a shell.)  Ooh.  The windows 
> implementation puts everything together and calls the string form due 
> to the nature of CreateProcess.  Yay.  Well, I see from win32/win32.c 
> create_command_line() that perl works a little harder.
> 
> In any case, I typically build command and arguments as lists.  Would 
> rather not have to do join(" ", map({escape($_)} @list)) and then have 
> wx go through that and split on spaces when the operating system is 
> otherwise quite capable of executing a list of "command and arguments".  
> I guess just leave "what should we do when the operating system is not 
> so capable?" as an exercise for the reader.
> 
> --Eric