g_exec functions
- From: Tor Lillqvist <tml iki fi>
- To: Havoc Pennington <hp redhat com>
- Cc: gtk-devel-list gnome org
- Subject: g_exec functions
- Date: Mon, 21 Aug 2000 11:25:26 +0300 (FLE Daylight Time)
Havoc Pennington writes:
> - These are UNIX-specific I think
Not really, at least on Win32 they should be readily implementable.
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?
> - 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.
> gboolean g_parse_argv (const gchar *command_line,
> gint *argc,
> gchar ***argv,
> GError *error);
Hmm. There are some complex Win32 portability issues regarding command
line parsing and argv building. I can't say how much difficulty these
will cause in practice.
One problem is caused by the fact that the actual Win32 "system call"
that spawns a new process (CreateProcess) is passed a command line
which is built from an argv in the MS C runtime spawnv() function,
which is then in the new process parsed by the C runtime start-up code
into argc, argv[] before calling main().
In the MS C runtime, both the code that builds a command line, and the
code that parses it into an argv certainly don't use the same
quoting/backslash rules as does Unix shells, and g_parse_argv() would
do.
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.
--tml
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]