The getopt language is imprecise, and attempts to be precise with it
usually go poorly.

For example,

SYNOPSIS
     ls [-1AaCcdFfgHhikLlmnopqRrSsTtux] [file ...]

% ls -1AaCcdFfgHhikLlmnopqRrSsTtux

The result may seem surprising.  I claim the result is not surprising.

It is unsurprising because the getopt langauge makes no claim about
which options are prioritized over other options, nor does it make
claims about which option combinations will be rejected and result
in error.

It only lists possibilities.  Sometimes the words in the manual page
describe the subset that will work, but sometimes it doesn't.  Sometimes
a program enforces a strict set of combinations, and somethings there
are surprises.

And that's fine.  Imagine trying to change the ls SYNOPSIS into 15 valid
combination so options, and then enforcing the priority and overlap
inside ls.c, and describing the reason why the priorites are chosen as
such (and probably introducing incompatibilities with other systems in
the process).  I think that would be a gigantic waste of time to do just
in ls, and I think we should only try to improve this in extremely
narrow cases when it really matters.

Klemens Nanni <k...@openbsd.org> wrote:

> rarpd(8) either "Listen[s] on all the Ethernets attached to the system"
> or requires an explicit list, not both:
> 
>       $ rarpd -a em0
>       usage: rarpd [-adflt] if0 [... ifN]
>       $ ./obj/rarpd -a em0
>       usage: rarpd [-dflt] -a | if ...
> 
> Or would this be better?
>       rarpd [-dflt] if ...
>       rarpd -a [-dflt]
> 
> Feedback? OK?
> 
> Index: rarpd.8
> ===================================================================
> RCS file: /cvs/src/usr.sbin/rarpd/rarpd.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 rarpd.8
> --- rarpd.8   28 Oct 2015 10:02:59 -0000      1.21
> +++ rarpd.8   29 Sep 2022 21:04:29 -0000
> @@ -29,8 +29,8 @@
>  .Nd reverse ARP daemon
>  .Sh SYNOPSIS
>  .Nm rarpd
> -.Op Fl adflt
> -.Ar if0 Op Ar ... ifN
> +.Op Fl dflt
> +.Fl a | Ar if ...
>  .Sh DESCRIPTION
>  .Nm
>  services Reverse ARP requests on the Ethernet connected to
> Index: rarpd.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/rarpd/rarpd.c,v
> retrieving revision 1.79
> diff -u -p -r1.79 rarpd.c
> --- rarpd.c   15 Nov 2021 15:14:24 -0000      1.79
> +++ rarpd.c   29 Sep 2022 21:05:35 -0000
> @@ -217,7 +217,7 @@ init_all(void)
>  __dead void
>  usage(void)
>  {
> -     (void) fprintf(stderr, "usage: rarpd [-adflt] if0 [... ifN]\n");
> +     fprintf(stderr, "usage: rarpd [-dflt] -a | if ...\n");
>       exit(1);
>  }
>  
> 

Reply via email to