freebsd-skq/usr.bin/getopt
cracauer cfa91c2e40 1) Fix the case where a shellscript using getopt is called with a
parameter that has space in it, both in getopt.c and in the manpage
   example.

2) Fix the example in the manpage. The set(1) command is required to
   return 0 (POSIX 1003.2, section 3.14.11), so you can't test for
   getopt's exit status like the example did:

  #! /bin/sh
  set -- `getopt abo: $*`
  if test $? != 0  # wrong, tests for set's exit status, which is
                   # always zero, no for getopt(1)'s.

Fixes PR bin/5845, which thought it was getopt's fault, but in fact
the manpage was wrong.

I also updated the example to be more useful and updated the BUGS
section.

PR:		bin/5845
1999-04-03 22:24:36 +00:00
..
getopt.1 1) Fix the case where a shellscript using getopt is called with a 1999-04-03 22:24:36 +00:00
getopt.c 1) Fix the case where a shellscript using getopt is called with a 1999-04-03 22:24:36 +00:00
Makefile
README

/***** unido:mod.std.unix / ut-sally!jsq /  8:54 pm  Jul  4, 1985*/
From: John Quarterman (moderator) <ut-sally!std-unix>
 
Topic: yet more on getopt (command line arguments)
 
Two more messages, the first a followup to a previous posting, and
the second public domain sources and man pages for getopt(3) and getopt(1).
	-mod

----------------------------------------------------------------------

From: ihnp4!utzoo!henry
Date: 3 Jul 85 18:34:41 CDT (Wed)
To: ihnp4!ut-sally!std-unix
Subject: Re: command line arguments

> > A group of bundled options may end with an option that has an argument.
> 
> This creates confusion in using C-Kermit when you want to send an image
> file.  For example:
> 
> 	send -is filename     < ---  works fine
>         send -si filename     < ---  bombs the program

The AT&T syntax standard (which getopt does not completely enforce)
actually forbids both of these usages.  Options with arguments are not
allowed to be bundled, and they must be separated from their arguments
by a space.

> I would *much* prefer to bundle the flags, then
> have those with arguments pick them up in the same order as the flags are
> listed.

The few existing commands that use such a convention, notably tar(1), are
(in my experience) the worse for it.  It's seriously error-prone.  I think
the AT&T people did the right thing.

------------------------------

Date: Tue, 2 Jul 85 13:07:09 edt
From: ihnp4!utcs!ian (Ian F. Darwin)
To: ihnp4!ut-sally!jsq@tzec.UTEXAS.ARPA
Subject: here is getopt

Here is the source for getopt(3), the function that should be in
everybody's C program, and getopt(1), a program that uses it to
make shell programs comprehensible and consistent. There are man
pages for both. Please send these on to the mod. group. Thanks.

[ I have hacked the following shell script slightly so that
it doesn't extract directly into system source directories,
rather into the current directory.  It should be assumed that
this code comes with no warranty from me, Ian Darwin, or anyone
else as to whether it accurately represents getopt as distributed
with System V, or any command line standard, or that it works
at all, or that it will cause no damage when extracted or used. -mod]