Change Details

Once we've shifted, reset OPTIND. It may be the case that we'll end up in another getopts loop in the case of `man -f` or `man -k`, where we will invoke do_whatis or do_apropos and parse arguments again. FreeBSD's /bin/sh seems to reset OPTIND to 1 after we hit the second getopts loop, rendering the following shift harmless; other /bin/sh implementations will leave it at what we came into the loop at (e.g., bash as /bin/sh), shifting off any keywords that we had. As such, this isn't really a functional change on FreeBSD but rather a correctness and portability fix: there typically aren't other arguments for this second getopts loop to have hit anyways.

From jilles: POSIX requires that a script set `OPTIND=1` before using different sets of parameters with `getopts`, or the results will be unspecified. The specific problem observed here is that we would execute `man -f` or `man -k` without cleaning up state from man_parse_args()' `getopts` loop. FreeBSD's /bin/sh seems to reset OPTIND to 1 after we hit the second getopts loop, rendering the following shift harmless; other /bin/sh implementations will leave it at what we came into the loop at (e.g., bash as /bin/sh), shifting off any keywords that we had.

Once we've shifted, reset OPTIND. It may be the case that we'll end upFrom jilles: POSIX requires that a script set `OPTIND=1` before using in another getopts loop in the case of `man -f` or `man -k`different sets of parameters with `getopts`, where weor the results will be will invoke do_whatis or do_apropos and parse arguments againunspecified. FreeBSD's /bin/sh seems to reset OPTIND to 1 after we hit the secondThe specific problem observed here is that we would execute `man -f` or getopts loop, rendering the following shift harmless; other /bin/sh`man -k` without cleaning up state from man_parse_args()' `getopts` implementations will leave it at what we came into the loop at (e.g.,loop. FreeBSD's /bin/sh seems to reset OPTIND to 1 after we hit the bash as /bin/sh), shifting off any keywords that we had.second getopts loop, As such,rendering the following shift harmless; thisother isn't really a functional change on FreeBSD but rather a correctness/bin/sh implementations will leave it at what we came into the loop at and portability fix: there typically aren't other arguments for this second getopts loop to have hit anyways(e.g., bash as /bin/sh), shifting off any keywords that we had.