From owner-freebsd-arch Wed May 8 11:32:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id ABC7B37B409; Wed, 8 May 2002 11:32:35 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g48IWTnG234048; Wed, 8 May 2002 14:32:29 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200205080304.g4834BL42647@green.bikeshed.org> References: <200205080304.g4834BL42647@green.bikeshed.org> Date: Wed, 8 May 2002 14:32:28 -0400 To: "Brian F. Feldman" , "J. Mallett" From: Garance A Drosihn Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Cc: arch@FreeBSD.ORG, Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 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. On the other hand, when it comes to any brand new option for some command, then I (personally) think there is no need to have flags which take optional arguments. The recent standards committees are definitely not fond of optional arguments, and as a user (including a user of perl) I find them more of a hassle than they are worth. By "standards", I am referring to Utility Syntax Guidelines in Single Unix Spec v2, guideline 7, which says: "Option-arguments should not be optional". [which reminds me, I still haven't received the copy of SUS-v3 that I ordered...] 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. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message