I. Szczesniak wrote:
> 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.
>
Did you actually read the architectural considerations at the bottom of
the message?
- Garrett
> Irek
>
