[pacman-dev] Fixing command line argument parsing in makepkg
Dan McGee
dpmcgee at gmail.com
Tue May 20 15:58:18 EDT 2008
On Mon, May 19, 2008 at 10:54 AM, Sebastian Nowicki <sebnow at gmail.com> wrote:
>
> I have not tested this on many systems, but when running into another
> "bug", I noticed that makepkg doesn't parse command line options
> correctly on Mac OS X:
>
>> $ sudo makepkg --asroot
>> ==> ERROR: Running makepkg as root is a BAD idea and can cause
>> permanent, catastrophic damage to your system. If you
>> wish to run as root, please use the --asroot option.
>
> I'm not sure if this has something to do with my settings, or zsh (I did
> test in bash), but there is a problem. After running getopt, it appears
> $@ gets altered. The following is the output of makepkg with an
> additional "echo $@" just after running getopt:
>
>> $ makepkg -h
>> -- AbcCdefFghiLmop:rRsSV -l
>> ignorearch,asroot,builddeps,clean,cleancache,nodeps,noextract,force,fo
>> rcever:,geninteg,help,holdver,install,log,nocolor,nobuild,rmdeps,repac
>> kage,source,syncdeps,usesudo,version,noconfirm,noprogressbar
>> -n makepkg -- -h
>
> makepkg proceeds as if -h was not supplied.
>
> The patch in the following mail attempts to fix this by using $ARGLIST,
> which does have the correct command line arguments. I did not test this
> patch on linux or other systems, or really tested it much at all, but
> the command line arguments do seem to get noticed and parsed properly. I
> didn't really write the patch as a solution, I just wanted to bring
> something to the table. I am not familiar with makepkg so it'd be best
> for other people to look into this.
>
> After applying the patch, $@ no longer gets shifted, and I saw use of
> OPT_IND, which never gets used, but it did scare me off a bit. Not
> shifting the command line arguments may result in regressions, but the
> solution provided is a simple one.
I just replied to your patch email, but did not mention when OPT_IND
actually gets used. I believe the idea was that any remaining args to
makepkg would get passed to pacman when/if it is called? But I may
just be crazy there.
-Dan
More information about the pacman-dev
mailing list