My error. I was looking at getopt(1) rather than getopt(3). Of course optind is documented, it's the way to find non-flag arguments. I don't know why the Hancock authors chose to make rsort into a subroutine rather than just piping into the command. Perhaps something to do with the software release process? On Wed, Mar 11, 2020 at 5:29 PM Warner Losh wrote: > > > On Wed, Mar 11, 2020 at 11:43 AM John P. Linderman > wrote: > >> This is *great*, Kurt. The source in src/runtime/hrs/src for rsort.c is >> their version of my external sort, modified to be a subroutine. There's >> some lessons to be learned about "software hygiene". I was cavalier about >> freeing what I allocated dynamically. As a result, their version leaks like >> a sieve if the subroutine is called repeatedly. Apropos of which, they came >> to me having noted that only the first call was acting as expected. There's >> a wonderful irony (I'm big on irony). I had replaced my do-it-yourself >> argument processing with getopt. The code has the following comment >> >> ** Use getopt() for portability. >> >> A few lines later, you see >> >> optind = 1; /* reset after use in Hancock program * >> while ((c = getopt(argc, argv, "cCiIjmrsSuvb:f:D:o:p:T:x:y:z:")) != >> EOF) { >> >> optind??? Seems getopt has an undocumented global flag to prevent >> reprocessing the arguments. How portable:-) >> > > It's documented: > > The variables opterr and optind are both initialized to 1. The optind > variable may be set to another value before a set of calls to > getopt() in > order to skip over more or less argv entries. > > is what the FreeBSD man page has to say about it. So this just resets any > scanning that had happened before this... > > Warner >