Re: why was the VAR 'optind' never changed in initdb? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: why was the VAR 'optind' never changed in initdb?
Date
Msg-id 4F831A23.8080709@dunslane.net
Whole thread Raw
In response to Re: why was the VAR 'optind' never changed in initdb?  (Clover White <mywhiteclover@gmail.com>)
Responses Re: why was the VAR 'optind' never changed in initdb?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 04/09/2012 12:36 PM, Clover White wrote:
> 2012/4/9 Andrew Dunstan <andrew@dunslane.net <mailto:andrew@dunslane.net>>
>
>
>
>     On 04/09/2012 07:38 AM, Clover White wrote:
>
>         Hi,
>          I'm debugging initdb using gdb.
>          I found that I could not step in the function getopt_long in
>         line 2572 in initdb.c.
>          I also found that the value of VAR optind never be changed.
>         VAR optind is always equal to 1 but how could optind be larger
>         than the value of argc(the value of argc is 6) in line 2648
>         and 2654.
>
>         I was so confused. Could someone give me some help? Thank you~
>
>
>
>     Why do you expect it to be? Perhaps if you tell us what problem
>     you're actually trying to solve we can help you better.
>
>     cheers
>
>     andrew
>
>
> Hi, this is my story, it may be a little long :)
>   I mistook the parameter -W of initdb at the first time and used it 
> like this:
>     initdb -U pgsql -W 12345 -D /home/pgsql/pg_data
>   And I found the database was not created in the right directory, but 
> I could not find a log file to find out why.
>   So, I debug initdb and found out I have mistook the parameter -W, I 
> should use it like this:
>     initdb -U pgsql -W -D /home/pgsql/pg_data


This is arguably a bug. Maybe we should change this:
     if (optind < argc)     {         pg_data = xstrdup(argv[optind]);         optind++;     }

to
     if (optind < argc && strlen(pg_data) == 0)     {         pg_data = xstrdup(argv[optind]);         optind++;     }

i.e. we'd forbid:
    initdb -D foo bar


which the OP's error more or less devolves to.


cheers

andrew


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: [JDBC] Regarding GSoc Application
Next
From: Tom Lane
Date:
Subject: Revisiting extract(epoch from timestamp)