From owner-freebsd-arch Wed May 8 13:21:21 2002 Delivered-To: freebsd-arch@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 CCED537BA27 for ; Wed, 8 May 2002 13:17:33 -0700 (PDT) Received: (qmail 6670 invoked by uid 1001); 8 May 2002 20:21:32 -0000 Date: Wed, 8 May 2002 20:21:32 +0000 From: "J. Mallett" To: Garance A Drosihn Cc: "Brian F. Feldman" , "J. Mallett" , arch@FreeBSD.ORG, Garrett Wollman Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020508202131.GC19530@FreeBSD.ORG> References: <200205080304.g4834BL42647@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organisation: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 08, 2002 at 02:32:28PM -0400, Garance A Drosihn wrote: > At 11:04 PM -0400 5/7/02, Brian F. Feldman wrote: > >Trying to move this to arch: > > ...certainly a good idea. > > >Another option would be to extend getopt(3) in what could > >simply be a very reasonable way. Here's my proposition > >for making a "clean" version that acts like Perl: > > I must admit that I kind of like the idea of modifying > getopt(3) so that it has the ability to process optional > attached-arguments to a command flag. There are older > programs which have such options, and it would be nice > if those programs could use a common routine for all > their processing. I expect that I shouldn't like that, as > it means we've deviated getopt(3) from how it is defined > in the standards, but I'll admit I like the idea. Your > idea of using ';' for the flag (to getopt) that indicates > an optional argument seems like a very good choice, too. I prefer "XX:", but that's a stylistic nit, I suppose. I would rather not introduce a new internal flag as such tho, as keep in mind you're saying "-; is not a valid option", which while in practice may be safe, may not be the best thing to say. XX: would not affect anything. > This then suggests we need two command-flags, one which > always takes an argument and one which never takes one. > As to which-is-which, or what the implied argument is > for the flag which never takes an argument, I like -i > for the flag which never takes an argument, and having > -i mean the same as '-I ""', but I'd be equally happy > with any other combination just as long as we are not > adding a command-flag that takes an optional argument. > > I think this -i/-I idea is good enough that many others > would pick up on it when they see it, and it makes > sense to define it in a way that doesn't conflict with > what standards-groups have already said about options. GNU implemented -i for xargs(1), in the way that I wanted to do compatability for. This option occurs in NEXTSTEP3.3 xargs(1), I do not know where it originates. SysV apparently has it... They also introduced '-I' which *required* an arg, and that was picked up by SUS/POSIX. I think if we don't do that we're being fools, and selling short our wonderful new capability for sed(1) [not that it matters, I just love being proud of work I've done]. -- 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 freebsd-arch" in the body of the message