Re: g_exec functions

[Havoc Pennington <hp redhat com>]

Tor Lillqvist <tml@iki.fi> writes:
> Havoc Pennington writes:
>  >  - These are UNIX-specific I think
> 
> Not really, at least on Win32 they should be readily implementable.
> 

With some modifications, right? We can't return pipe file descriptors
on Windows, for example. 

> About the naming: Would it be preferrable to use the term "spawn"
> instead of "exec", not to cause confusion with the semantics of the
> exec*() system calls?
> 

As long as we avoid a function g_exec() I think it's OK - "exec" is
often used separately from the system call. "run_process" is a
possible alternative I like more than "spawn", spawn isn't very
intuitive to UNIX people...

>  >  - the exit status will require interpretation with WIFEXITED() etc.
>  >    which is somewhat odd for glib, so maybe we need glib wrappers for 
>  >    the exit status stuff.
> 
> Yes.
> 

Making these cross-platform is going to be sort of complicated:

 - GIOChannel instead of file descriptors
 - maybe a process ID abstraction, GProcess or something
 - we can wrap WIFEXITED(), but that's almost pointless unless
   we also wrap waitpid() etc. so you can get the exit status
   from the asynchronous process

it sort of snowballs... I wonder if it isn't better to just have
g_exec_* for UNIX and g_spawn_* for Windows (if appropriate), looking
at these as convenience functions rather than portability wrappers. I
don't know. There's a very small subset of UNIX functionality we can
actually support on all platforms...
 
> Another thing is that it probably is much more common on non-Unix
> platforms that pathnames contain spaces; for instance the normal place
> where GIMP is installed on Windows is \Program Files\GIMP.
> 
> Argh, it's hard to say what is the cleanest way to handle issues like
> this. Most probably, only experience will tell.
> 

If nothing else we almost certainly need a g_shell_quote() function to 
quote a filename or whatever to pass to the shell. I'm sure this is
already implemented 57 times with an LGPL license, we just have to
find some of them. Then it could do the right thing on win32.

Havoc