Date: Tue, 7 May 2002 19:20:21 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "J. Mallett" <jmallett@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <p0511173fb8fe1074d26d@[128.113.24.47]> In-Reply-To: <20020507191959.GA26441@FreeBSD.ORG> References: <20020507184519.GB28857@FreeBSD.ORG> <XFMail.20020507150637.jhb@FreeBSD.org> <20020507191959.GA26441@FreeBSD.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:20 PM +0000 5/7/02, J. Mallett wrote:
>On Tue, May 07, 2002 at 03:06:37PM -0400, John Baldwin wrote:
> > Personally, I won't use sed -i if it insists on leaving
> > backup files around that I have to go the trouble to delete.
> > I might as well just do
> > sed 'foo' < foo > foo.bak
this does not work well when you're also using 'sudo'...
>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.
--
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 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?p0511173fb8fe1074d26d>