Re: [Libguestfs] [PATCH libguestfs 2/5] guestfish: write --help to stdout, use gnulib's progname module
On Mon, Aug 24, 2009 at 04:26:16PM +0200, Jim Meyering wrote:
Richard W.M. Jones wrote:
> On Mon, Aug 24, 2009 at 02:21:51PM +0200, Jim Meyering wrote:
>> Sure. That works, too.
>> Here's the incremental:
>
> No, this doesn't fix the path munging to use real_argv0.
"fix"?
Is something incorrect, or is it just that you'd prefer
to move the definition of real_argv0 "up"?
I see only two uses of argv[0] in main:
- path-related stuff *before* I change argv[0] and define real_argv0
if (getenv ("LIBGUESTFS_PATH") == NULL &&
argv[0] &&
(argv[0][0] != '/' || strstr (argv[0], "/.libs/lt-") != NULL))
guestfs_set_path (g, "appliance:" GUESTFS_DEFAULT_PATH);
- then, this code, afterwards, that I did change to use real_argv0:
strcpy (cmd, "a=`virt-inspector");
while (optind < argc) {
if (strlen (cmd) + strlen (argv[optind]) + strlen (real_argv0) + 60
...
sprintf (&cmd[strlen(cmd)], "` && %s $a", real_argv0);
If you'd prefer to move the definition of real_argv0 to precede
the former, let me know, and I'll move it and adjust.
However, note that that has no impact on correctness.
You're right - for some reason I thought the path-munging code
occurred after overwriting argv[0].
In general though I think the code is now much more prone to errors if
we rearrange the code in future. (It's already complex and prone to
introducing errors).
If the only benefit to rewriting argv[0] is that we get a slightly
better error message from getopt, then I'm inclined not to do it at
all. Leave all the argv[0] code as it is, and change anything else to
use program_name.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html