Date: Tue, 7 May 2002 23:30:24 +0000 From: "J. Mallett" <jmallett@FreeBSD.ORG> To: Garrett Rooney <rooneg@electricjellyfish.net> Cc: Garance A Drosihn <drosih@rpi.edu>, "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: <20020507233024.GC20078@FreeBSD.ORG> In-Reply-To: <20020507232301.GB45271@electricjellyfish.net> References: <20020507184519.GB28857@FreeBSD.ORG> <XFMail.20020507150637.jhb@FreeBSD.org> <20020507191959.GA26441@FreeBSD.ORG> <p0511173fb8fe1074d26d@[128.113.24.47]> <20020507232301.GB45271@electricjellyfish.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 07, 2002 at 07:23:01PM -0400, Garrett Rooney wrote:
> 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.
I'd go so far as to say we're implementing a superset of Perl's
capabilities in sed(1), and as such, the "old code" provision
falls in. After all, if you re-implmeneted a whole utility, you
would want compatability. All we want is front-end compatability
with Perl. The options.
Maybe there's a flaw in that logic.
Maybe there's a flaw in conforming to a standard and breaking POLA,
where said standard has not been broken in existing functionalities,
just new ones, that furthermore, are covered in and of themselves,
directly or otherwise, by provisions in said standard.
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020507233024.GC20078>