Date: Sat, 13 May 2000 01:39:31 -0400 From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: Mark Ovens <mark@dogma.freebsd-uk.eu.org> Cc: Erik Trulsson <ertr1013@student.csd.uu.se>, questions@FreeBSD.ORG Subject: Re: getopt(1) or getopts(1)? Message-ID: <20000513013931.C39310@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <20000512183403.A233@parish>; from mark@dogma.freebsd-uk.eu.org on Fri, May 12, 2000 at 06:34:03PM %2B0100 References: <20000511231319.C1522@parish> <20000512084656.A1146@student.csd.uu.se> <20000512183403.A233@parish>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 12, 2000 at 06:34:03PM +0100, Mark Ovens wrote:
> On Fri, May 12, 2000 at 08:46:56AM +0200, Erik Trulsson wrote:
> > On Thu, May 11, 2000 at 11:13:19PM +0100, Mark Ovens wrote:
> > > Can someone clarify getopt(1) and getopts(1)? According to sh(1):
> > >
> > > getopts optstring var
> > > The POSIX getopts command. The getopts command deprecates the
> > > older getopt(1) command.....
> > >
> > > but there is no manpage for getopts(1), only getopt(1). The latter
> > > includes some sample code which works fine, however if I change
> > > ``getopt'' to ``getopts'' in this code I get:
> > >
> > > parish:/usr/marko{89}% ./foobar -b
> > > getopts: -b: bad variable name
> > > Usage: ...
> > > parish:/usr/marko{90}%
> > >
> > > Since getopt(1) is deprecated it would be better to use getopts(1).
> > > Can anyone explain the above error, or point me to some documentation
> > > for getopts(1)?
> > >
> >
> > On my system (4.0-stable) there is a manpage for getopts(1). It just a link
> > to buiiltin(1) which says that it is a builtin command in sh(1).
>
> Same here (I'm also on 4-stable). I hadn't spotted that it is a copy
> of (not a link to) builtin(1).
It is a link, hardlink.
% cd /usr/share/man/man1
% ls -li getopts.1.gz builtin.1.gz getopt.1.gz
508294 -r--r--r-- 71 root wheel 2407 Mar 25 03:08 builtin.1.gz
508336 -r--r--r-- 1 root wheel 1649 Mar 25 03:10 getopt.1.gz
508294 -r--r--r-- 71 root wheel 2407 Mar 25 03:08 getopts.1.gz
> > The manpage for sh(1) has the following to say about getopts:
> >
> > getopts optstring var
> > The POSIX getopts command. The getopts command deprecates the
> > older getopt(1) command. The first argument should be a series
> > of letters, each possibly followed by a colon which indicates
> > that the option takes an argument. The specified variable is set
> > to the parsed option. The index of the next argument is placed
> > into the shell variable OPTIND. If an option takes an argument,
> > it is placed into the shell variable OPTARG. If an invalid option
> > is encountered, var is set to `?''. It returns a false value (1)
> > when it encounters the end of the options.
> >
> >
>
> The first couple of lines of which I quoted in my original post so,
> yes, I have read it. However it reads as though the syntax is the same
> as getopt(1) (at least to me it does). So the question remains; why
> does the sample code in getopt(1) not work if I change ``getopt'' to
> ``getopts'' in the first line?
It really is nothing like getopt(1). Not sure where it says anything
there that would lead one to believe that.
> I'm quite happy to RTFM, if only I could find a FM to R :)
But this is a very good point. I can't find the FM, but for some
reason, I know how to use this... It works more like getopt(3); maybe
that's why it feels familiar.
To get about the same functionality you see in the getopt(1) manpage,
you would have something like,
while getopts abo: OPT; do
case $OPT in
a|b)
echo flag $OPT set; sflags="${OPT#-}$sflags"
;;
o)
echo oarg is "'"$OPTARG"'"; oarg="$OPTARG"
;;
*)
echo ERROR
exit 2
esac
done
echo single-char flags: "'"$sflags"'"
echo oarg is "'"$oarg"'"
getopts cycles through the argument list on its own. No need to
shift. It places the current option (the single letter) in the var
specified. The argument of the option, if it takes one, is in
OPTARG. Your current position on the command line is stored in OPTIND
(and is started at the first argument if OPTIND is unset).
Almost makes life too easy, huh?
--
Crist J. Clark cjclark@home.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?20000513013931.C39310>