From owner-cvs-all Tue May 7 16:26:47 2002 Delivered-To: cvs-all@freebsd.org Received: from finntroll.newgold.net (durham-ar1-4-64-252-019.durham.dsl-verizon.net [4.64.252.19]) by hub.freebsd.org (Postfix) with SMTP id 1521237B408 for ; Tue, 7 May 2002 16:26:36 -0700 (PDT) Received: (qmail 7873 invoked by uid 1001); 7 May 2002 23:30:24 -0000 Date: Tue, 7 May 2002 23:30:24 +0000 From: "J. Mallett" To: Garrett Rooney Cc: Garance A Drosihn , "J. Mallett" , John Baldwin , 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> References: <20020507184519.GB28857@FreeBSD.ORG> <20020507191959.GA26441@FreeBSD.ORG> <20020507232301.GB45271@electricjellyfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020507232301.GB45271@electricjellyfish.net> User-Agent: Mutt/1.3.27i Organisation: The FreeBSD Project Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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