Hi Joerg, Joerg Jung wrote on Wed, Nov 13, 2019 at 02:55:17PM +0100: > martijn@ wrote:
>> Also the manpage is incorrect. It states [address] [limit], while >> if you want to limit the address is non-optional (from reading the >> code). So this should be [address [limit]]. Strictly speaking, martijn@ is right. Per convention in manual pages, [...] [...] means that you can given none, or either of them, or both, while [... [...]] means that you can give none, or the first, or both, but not the second alone. Examples of [...] [...] with the meaning explained above include atrm(1), cal(1), grep(1), lpq(1), lprm(1), nc(1), systat(1), ... In such cases, often the syntax of both arguments is sufficiently different that it's clear which one is intended when only one is given (for example, a number vs. a string of letters); in other cases, the first argument can be left out when a certain option is specified, like grep(1) -e or nc(1) -l. That said, synopses sometimes cannot be absolutely precise without becoming excessively complicated. But i don't think there is a problem of that kind here. > I don't think that this is incorrect, but a rather common idiom found > in other man pages as well, because: > foo [bar [baz [bat [ban [address [limit]]]]]] I don't buy that argument. On the one hand, taking six arguments in a fixed order would seem pretty poor UI design to me. Usually, making them option arguments like foo [-a bar] [-b baz] [-c bat] [-d ban] [address [limit]] would be better UI design because it wouldn't force you to repeat all the defaults just to be able to specify a limit - and it wouldn't force users to learn the order. Besides, i quickly looked through /usr/share/man/man1/ and failed to find a single example where [...] [...] is used but [... [...]] is intended. Admittedly, i might have missed one, but it certainly doesn't look like a common idiom to me. On the other hand, i quickly found several examples of [... [...]]: cmp(1), colrm(1), gprof(1), ksh(1), patch(1), rs(1), split(1), su(1), tmux(1), tradcpp(1), xargs(1), ... > is just not very readable and multiple arguments have always > non-optional predecessors anyways. Absolutely not. That is clearly not true, see the examples above. > But I'm not a manpage syntax expert, > maybe Ingo or jmc can chime in and correct me to be wrong here. At your service. ;-) Admittedly, this is a fringe issue for a port and shouldn't hinder importing. I'm also slightly concerned about large corporations promoting non-portable software and languages and the possibly resulting vendor-lockin, but i'm not a language expert, so my opinion doesn't mean all that much in that respect. I don't doubt the argument, though, that portability ought to be *considered* when making decisions about tools to be used. Either way, even having chosen a poorly-portable language should not hinder committing a port; sometimes, even non-free software gets ported, after all. I can't comment on the port itself. Yours, Ingo
