On Sun, Oct 02, 2022 at 10:09:32AM -0600, Theo de Raadt wrote: > 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.
You point about getopt not being that precise (by design) makes sense. Many manuals differ in this regard and yet I still consider each of them fine as they are. > 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. I agree, ls(1) seems like the ultimate case where splitting things up is a bad idea. rarpd(8) is small enough where my impression is that refining it a little would be good, but it quickly comes down to personal taste.
