Date: Tue, 7 May 2002 19:23:01 -0400 From: Garrett Rooney <rooneg@electricjellyfish.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: "J. Mallett" <jmallett@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020507232301.GB45271@electricjellyfish.net> In-Reply-To: <p0511173fb8fe1074d26d@[128.113.24.47]> References: <20020507184519.GB28857@FreeBSD.ORG> <XFMail.20020507150637.jhb@FreeBSD.org> <20020507191959.GA26441@FreeBSD.ORG> <p0511173fb8fe1074d26d@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 07, 2002 at 07:20:21PM -0400, Garance A Drosihn wrote:
> >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.
it's all well and good to have interface guidelines like this, but in
this particular case i think being compatable with a common idiom (the
way perl treats -i) is more important than following the letter of the
law.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020507232301.GB45271>