> >Various points taken. Tell me the preferred way to handle
> >options which may or may not take arguments, and I'll give
> >it my best shot. I'd assume it's to do something like
> >
> >case 'i':
> > if (*argv[optind+1] != '-') {
> > take the option from argv[optind++];
> > } else
> > set a binary flag for -i, and don't set the extension.
> > break;
> >
> >Does that seem right?
>
> We do not want options which "may or may not take arguments".
> The standards only allow those as concessions to older code
> which was written that way. I am pretty sure all "new code"
> has options such that they either always take an argument,
> or they never take an argument.
That's the concern, weening stubborn people off their Perl
dependencies. If we can at least agree to always use a backup
extension, even if it's nil, and move from perl-i to sed-i in
*OUR* source tree, then the code I've committed (and the nil
handling code I'm about to commit) is worthwhile, as it takes
away another reason for people to say "we *NEED* Perl". We
don't, we just need more people willing to try to make more
minimalist tools do their job completely.
--
jmallett@FreeBSD.org | C, MIPS, POSIX, UNIX, BSD, IRC Geek.
http://www.FreeBSD.org | The Power to Serve
"I've never tried to give my life meaning by demeaning you."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message