On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote: > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote: > > Until a patch from naddy, I wasn't even aware of getopts in sh(1) > > > > Unless I made some mistakes, this translates the example in getopt(1) > > manpage. > > > > It's likely some stronger wording might be adequate, I suspect some > > of the BUGS section in getopt(1) does not apply to the sh(1) built-in. > > > > hi marc. > > is there a reason why you wanted the example in sh(1) and not ksh(1)? > > i think the overall structure is that ksh(1) is the full monty, whereas > sh(1) is really a simplified reference to which bits you can use if you > want to keep things portable. to that end there aren;t really any > examples in sh(1). i felt that having a short page was more beneficial > in the long run (especially since we already have a full on ksh(1) > page). > > having said that, getopts is one of those things that you really won;t > get from reading descriptive text. an example is definitely helpful. so > i'd not be dead against it in sh(1) if there's a good reason. > > there's also the possibility that it may be more helpful to show it in > getopts(1) itself? i guess there are pros and cons there too. > > jmc
getopts(1) is not a separate command. Having built-ins in their separate manpage would be a definitive departure from what we've always done. Some linux distributions do have some of the built-ins in their own man pages so that they're easier to find, which makes all kind of sense to me, even though it's pedantically incorrect. I think it would help, but you are going to ruffle all kinds of feathers. Also, getopts is POSIX. Documenting it in ksh would send the wrong signal in my opinion (but if I replace getopt with getopts, am I still writing a standard shell script). That said, we can easily lift the exact same paragraph in both manpages.
