On 7/25/09, Garrett D'Amore <gdamore at sun.com> wrote: > Roland Mainz wrote: > > > Garrett D'Amore wrote: > > > > > > > Alan Coopersmith wrote: > > > > > > > > > > Garrett D'Amore wrote: > > > > > > > > > > > > > Personally, I think --man, --html and --nroff and such is a > dangerous > > > > > precedent to set. I'd rather not have them, and instead rely on the > > > > > "man" command to provide this functionality. > > > > > > > > > > > > > > Isn't it a bit late to raise such a concern, since the precedent was > set > > > > in the long list of previous cases that used AST/ksh93 > implementations? > > > > > > > > > > > It might be. I certainly should have raised the issue back then. I'm > > > still not happy about this. > > > > > > > > > > Why ? > > > > > > I'll explain why further down. > > > > > > > > > There's yet another concern, which is that I've found that man <command> > > > and command --man do not generate the same document. So we know > > > introduce a problem were documentation delivered on the system can be > > > inconsistent. > > > > > > > > > > Erm... no. As said in my other email the "--man" output is basically a > > short/terse format and more or less exactly what the "getopts" parser > > sees (it may even be usefull if main documentation and actual code are > > out-of-sync (which is currently the case for many commands)). > > > > > > No, it isn't. (Well, you might have "extra" text in the getopts parser, > but for an example look at the output from sum --help. Its quite a rich > manual page, far beyond the normal getopts kind of messaging.) > > > > > > > > > I feel really strongly that this was a bad idea. > > > > > > > > > > IMO it was a nice idea - see my other email where this feature > > originated from. > > > > > > I understand the notion. And for projects that don't have the same > considerations we do, the idea is elegant. But I'll elaborate further below > why I think this idea is *not* a good idea for our project.
You still failed to provide a sound technical reason why --man should be removed. > > > > > > > Strongly enough that > > > I'm contemplating derailing the case. > > > > > > > > > > And what should we do then ? The only thing we can do is to remove it > > from the case materials - removing it from the code can only be done > > globally (e.g. libast) and that really will break existing&&ARC'ed > > parts. > > > > > > #ifdef SOLARIS ? Are you SERIOUSLY suggesting the project team has to add 2196 #ifdef SOLARIS statements (45 commands, 4 per option, 20 to strip further text strings in the getopt template) in the code of libcmd? Who is going to maintain this code fork? > Seriously, if you want Solaris to adopt these commands in > favor of our current native implementations, then there has to be some > willingness to address architectural issues found on, or even specific to, > Solaris. I think the team working on the Solaris ksh93 project has shown the willingness to address reasonable architectural and technical issues on many occasions, even at the expense of crippling the set of features beyond the point I would consider acceptable. But I do not consider your proposal to strip --man from the code as reasonable. It adds an arbitrary Solaris-specific difference with NO technical justification. Please state technical reason. Irek
