> Date: Thu, 19 Feb 2009 21:26:34 -0800 > From: Scott Rotondo <Scott.Rotondo at sun.com> > Bart Blanquart wrote: > > On 02/19/09 18:25, Glenn Faden wrote: > >> This looks good to me. It probably could have been coded differently > >> using getopt, but since that wasn't used in the original code, I think > >> your changes are acceptable. > > > > I originally coded it using getopt, but that fails to handle "auths -ab > > username" correctly, as it can't tell if the "b" is the argument to "-a" > > or a (non-existant) option. > > This is a significant issue. Whether or not you use getopt() in the > implementation, the command syntax should be getopt-compliant. In other > words, the example above should check if the user has the authorization > called "b". The easiest way to achieve getopt-compliance, of course, is > to use getopt(). > > > This also meant it becomes tricky to handle "auths -asolaris.something > > username" correctly: the switch(argc) would fall to the wrong case (as > > argc==3 but it should fall to case 4).
Did you test the above command? As I read it, this will cause the variable haveauth to be set at line 87, hence line 95 sets c=4 and the test at line 97 will pass a NULL ptr to strncmp(). Did you test auth -asolaris.something? According to the man page, that should indicate whether the current user has the solaris.something authorization, but your implementation yields a usage error. The switch at line 103 should be testing optind versus argc. > That's why you want to use optind to decrement argc and increment argv > *after* you call getopt(). That way you get correct results with or > without the space between the option and argument. > > > > > If there's an easy way to handle this I can swap out lines 82-92 for a > > getopt based command line parser (and update 93-99 to match). > > > > Bart > > I didn't review your code; my comments are based on the email thread. > But I'm 99% sure you should be using getopt(). > > Scott I'm 99 44/100 percent sure. 8-) -JZ
