Date: Mon, 15 May 2000 23:40:56 +0100 From: Mark Ovens <mark@ukug.uk.freebsd.org> To: cjclark@home.com Cc: Erik Trulsson <ertr1013@student.csd.uu.se>, questions@freebsd.org Subject: Re: getopt(1) or getopts(1)? Message-ID: <20000515234055.C233@parish> In-Reply-To: <20000514113604.A50543@cc942873-a.ewndsr1.nj.home.com>; from cjc@cc942873-a.ewndsr1.nj.home.com on Sun, May 14, 2000 at 11:36:04AM -0400 References: <20000511231319.C1522@parish> <20000512084656.A1146@student.csd.uu.se> <20000512183403.A233@parish> <20000513013931.C39310@cc942873-a.ewndsr1.nj.home.com> <20000514110900.B232@parish> <20000514113604.A50543@cc942873-a.ewndsr1.nj.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 14, 2000 at 11:36:04AM -0400, Crist J. Clark wrote:
> On Sun, May 14, 2000 at 11:09:00AM +0100, Mark Ovens wrote:
> >
[snip]
> >
> > I'd almost got there, except I didn't know that shift wasn't needed.
> >
> > > Almost makes life too easy, huh?
> >
> > Almost. It does seem somewhat lacking in the error handling dept.
> > though. Using the example code above, if you do:
> >
> > # foobar -o -a -b
> >
> > then getopts(1) thinks that ``-a'' is the argument to ``-o''.
>
> How do you know it is not?
>
If ``-a'' is a valid argument to ``-o'' then it would require special
handling, not unlike filenames starting with ``-'', or containing
metacharacters, they need quoting.
> > Also, if it encounters an error such as an illegal option, or a
> > missing argument then getopts(1) prints it's own error but sets $OPT
> > to ``?'' which makes it difficult to generate your own error message,
> > so instead of:
> >
> > # foobar -a -b -o
> > No arg for -o option
> > #
> >
> > you could output "-o requires a valid path as an argument" which would
> > be easy if $OPT was set to ``o'' as you could test for $OPTARG = "" in
> > the o case. OK, you could probably do it by keeping track of $OPTIND,
> > but that points to the *next* option and if the error occurs on the
> > last option it is set to 1, so you need to track the previous value of
> > $OPTIND.
>
> Problem with your idea is that a null string could be valid input,
>
> $ foo -a -o ""
>
OK, fair comment, although I would expect this to be a rare
occurrence.
> Second, you only can run out of options when the option requiring an
> argument is the last command line argument. You can lookup what the
> last one is pretty easily, `eval LAST=\$$#`.
>
Well, in cases of error it would be better if it still set $OPT to the
option (and obviously $OPTARG to the null string) but also set another
var, e.g. $OPTERR, to some value to signify an error condition. That
way the user code could deal with the situation.
> Are you pointing out weaknesses in the whole "getopt(s)" concept or
> complaining about getopts? getopt(1) has the same issues. getopts is
> definately not for use in all situations and never will be.
OK, I accept that. I am just surprised that it isn't more
flexible/powerful, especially the newer getopts(1). I'm just trying to
make it (the script) idiot-proof - once I get something working the
first thing I try to do is break it.
Anyway, thanks for the help, it's much appreciated.
> --
> Crist J. Clark cjclark@home.com
--
...and on the eighth day God created UNIX
________________________________________________________________
FreeBSD - The Power To Serve http://www.freebsd.org
My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:mark@ukug.uk.freebsd.org http://www.radan.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000515234055.C233>