Date: Wed, 8 May 2002 14:32:28 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "Brian F. Feldman" <green@FreeBSD.ORG>, "J. Mallett" <jmallett@FreeBSD.ORG> Cc: arch@FreeBSD.ORG, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <p0511174bb8ff15c41118@[128.113.24.47]> In-Reply-To: <200205080304.g4834BL42647@green.bikeshed.org> References: <200205080304.g4834BL42647@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0511174bb8ff15c41118>