Why not add an option at compile/configure time to reference the native man 
pages for the target OS? That way it's not a Solaris specific feature, but an 
option anyone can use on any target platform?? I think that would be the best 
compromise.

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Virtualization Architect and Consultant
Web: http://unixconsole.blogspot.com
E-Mail: unixconsole at yahoo.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----- Original Message ----
From: I. Szczesniak <iszczesn...@gmail.com>
To: Korn Shell 93 integration/migration project discussion 
<ksh93-integration-discuss at opensolaris.org>
Cc: PSARC-ext at sun.com; Busybox development <busybox-dev at opensolaris.org>
Sent: Saturday, July 25, 2009 5:20:00 AM
Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, 
mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009]

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
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris.org



      

Reply via email to