[Combining responses to multiple subthreads to try to reduce mail load.]
Garrett D'Amore wrote:
>>> 4) Furthermore, the --man output doesn't reflect standards required for
>>> Sun man pages. For example, there is no
>>> ATTRIBUTES table.
>>>
>>
>> That's a good reason why there should also b
John Sonnenschein wrote:
> Sure but for the sake of argument if we have some tools that have --man
> and also man pages, does that mean that the docs people will be putting
> back to ON, or will there be a desynchronization between the man pages
> and the --man pages ?
Hopefully the ON design fl
there seems to be a reasonable understanding of issues on both sides
I don't believe I have been misrepresented/misinterpreted
to show that the ast side is not being bone-headed about not wanting to change,
there is more to the ast upstream than is (or proposed to be) in solaris
I don't expect t
Alan Coopersmith wrote:
> I'm sponsoring this fast-track request on behalf of the
> ksh93-integration and busybox projects. The timeout is
> set for Friday, July 31, 2009.
[snip]
Just to clarify (since both points have IMHO been either ignored or
misinterpreted several times):
1. We do _not_ inte
On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote:
> Roland Mainz wrote:
> > Alan Coopersmith wrote:
> >
> >> I'm sponsoring this fast-track request on behalf of the
> >> ksh93-integration and busybox projects. The timeout is
> >> set for Friday, July 31, 2009.
> >>
> > [snip]
> >
Glenn Fowler wrote:
> On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote:
>
>> Roland Mainz wrote:
>>
>>> Alan Coopersmith wrote:
>>>
>>>
I'm sponsoring this fast-track request on behalf of the
ksh93-integration and busybox projects. The timeout is
set for Fr
Roland Mainz wrote:
> Garret, would you accept the "truce" and remove the "de-rail", please ?
I think you're confused about the process that's in use in the ARC.
"De-rail" does not in any way mean "deny." In fact, it doesn't even
mean that there's anything wrong with the proposed project. I've
On 7/26/09, Josh Hurst wrote:
> On 7/26/09, Jennifer Pioch wrote:
> > On 7/26/09, Garrett D'Amore wrote:
> > > Roland Mainz wrote:
> > >
> > > > John Sonnenschein wrote:
> > > >
> > > >
> > > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > > > >
> > > > >
> > > > > > Jo
On 7/26/09, Jennifer Pioch wrote:
> On 7/26/09, Garrett D'Amore wrote:
> > Roland Mainz wrote:
> >
> > > John Sonnenschein wrote:
> > >
> > >
> > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > > >
> > > >
> > > > > John Sonnenschein wrote:
> > > > >
> > > > >
> > > > > > I've
Roland Mainz wrote:
> Alan Coopersmith wrote:
>
>> I'm sponsoring this fast-track request on behalf of the
>> ksh93-integration and busybox projects. The timeout is
>> set for Friday, July 31, 2009.
>>
> [snip]
>
> Just to clarify (since both points have IMHO been either ignored or
> misin
On 7/26/09, Garrett D'Amore wrote:
> Roland Mainz wrote:
>
> > John Sonnenschein wrote:
> >
> >
> > > On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > >
> > >
> > > > John Sonnenschein wrote:
> > > >
> > > >
> > > > > I've got a question about this...
> > > > > Whose responsibility is it to upda
usybox-dev] AST versions of fold, mktemp,pathchk,& tty
[PSARC/2009/414 FastTrack timeout 07/31/2009]
John Sonnenschein wrote:
> On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > John Sonnenschein wrote:
> >> I've got a question about this...
> >> Whose responsi
Jennifer Pioch wrote:
> On 7/26/09, Garrett D'Amore wrote:
>
>
> Didn't you read what Roland wrote about the project rules?
>
>> in several major and unbreakable rules for this project which
>> includes:
>> - WE DO NOT FORK THE CODE
>> - WE DO NOT BREAK THE KSH93 TEST SUITE
>> - THE KSH93 TE
John Sonnenschein wrote:
> On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> > John Sonnenschein wrote:
> >> I've got a question about this...
> >> Whose responsibility is it to update the man pages and --man
> >> command then? The people whose jobs it is to update man pages, or
> >> the people whos
Garrett D'Amore wrote:
> Alan Coopersmith wrote:
> > Garrett D'Amore wrote:
> >> 1) The commands increase the size of the text segment. Not only does
> >> it add new parsing requirements (you have to at least have enough code
> >> to handle --man, for example), but you also have the text of the m
"I. Szczesniak" wrote:
> On 7/25/09, Garrett D'Amore wrote:
> > Roland Mainz wrote:
> > > Garrett D'Amore wrote:
> > > > Alan Coopersmith wrote:
> > > > > Garrett D'Amore wrote:
[snip]
> > > > Strongly enough that
> > > > I'm contemplating derailing the case.
> > >
> > > And what should we do then
Garrett D'Amore wrote:
> Roland Mainz wrote:
> > Garrett D'Amore wrote:
> >> Alan Coopersmith wrote:
> >>> Garrett D'Amore wrote:
[snip]
> >> There's yet another concern, which is that I've found that man
> >> and command --man do not generate the same document. So we know
> >> introduce a proble
John Sonnenschein wrote:
> On 24-Jul-09, at 11:01 PM, Garrett D'Amore wrote:
> > Roland Mainz wrote:
> >> Garrett D'Amore wrote:
> >>> Alan Coopersmith wrote:
[snip]
> > I will say just one more thing. Where it not for the --man, --
> > nroff, and --html options, I think I would unhesitatingly gi
re eliding portions of libast::optget() usage strings via #ifdef SOLARIS or
whatever
the optget() usage string contains:
(1) information required for short and long options, and proper rendering
of diagnostics for option errors
(2) version, author and copyright information
(3) optional callb
re concerns about libast::optget() string out of sync with .1 man page
I mentioned this in a previous post but it must have gotten lost
amidst the volume of posts: the separate ksh93 sh.1 man page is an
exception rather than the rule for ast section 1 utilities
in almost all other cases the optg
I understand the "sparse message catalog" problem to be
that an ast optget usage string would be treated as
one string in the message catalog
however, this is not how libast::optget() interfaces with
the underlying message catalogs
almost all of the l10n strings in ast src are
arguments to libas
could some kind soul figure out how to clean up the reply
address for this thread so that I (we) only get one copy
of each message
I'm currently getting at least 4 of each message and I'm
sure I have missed at least one tidbit of valuable info
thanks
Roland Mainz wrote:
> John Sonnenschein wrote:
>
>> On 25-Jul-09, at 4:59 PM, James Carlson wrote:
>>
>>> John Sonnenschein wrote:
>>>
I've got a question about this...
Whose responsibility is it to update the man pages and --man
command then? The people whose jobs it
Glenn Fowler wrote:
> re concerns about libast::optget() string out of sync with .1 man page
>
> I mentioned this in a previous post but it must have gotten lost
> amidst the volume of posts: the separate ksh93 sh.1 man page is an
> exception rather than the rule for ast section 1 utilities
>
R
Glenn Fowler wrote:
> I understand the "sparse message catalog" problem to be
> that an ast optget usage string would be treated as
> one string in the message catalog
>
No, what I meant by this is whether or not all output messages are
translated as part of the process of localization. I thi
On 7/25/09, Garrett D'Amore wrote:
> Alan Coopersmith wrote:
>
> > Garrett D'Amore wrote:
> >
> >
> > > 1) The commands increase the size of the text segment. Not only does
> > > it add new parsing requirements (you have to at least have enough code
> > > to handle --man, for example), but you a
> > #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?
Irek,
you cannot comment the getopts option description out without
John Sonnenschein wrote:
> I've got a question about this...
>
> Whose responsibility is it to update the man pages and --man command
> then? The people whose jobs it is to update man pages, or the people
> whose jobs it is to update the command line utility?
>
> Basically if a new flag is adde
On 25-Jul-09, at 4:59 PM, James Carlson wrote:
> John Sonnenschein wrote:
>> I've got a question about this...
>> Whose responsibility is it to update the man pages and --man
>> command then? The people whose jobs it is to update man pages, or
>> the people whose jobs it is to update the comm
While you talk about implementation issues and details below, I'm
unconvinced that my architectural considerations are addressed. It may
be that I chose poor examples, but rest assured I chose them at random.
Some examination of the code makes me think there are are others that
have a lot of
From: "Octave Orgeron" on Saturday, July 25, 2009
12:03 PM:
> 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 th
I've got a question about this...
Whose responsibility is it to update the man pages and --man command
then? The people whose jobs it is to update man pages, or the people
whose jobs it is to update the command line utility?
Basically if a new flag is added in the future for some reason, how
On 7/25/09, Garrett D'Amore 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
k
To: Korn Shell 93 integration/migration project discussion
Cc: PSARC-ext at sun.com; Busybox development
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]
Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>
>> 1) The commands increase the size of the text segment. Not only does
>> it add new parsing requirements (you have to at least have enough code
>> to handle --man, for example), but you also have the text of the man
>> pages themselves. Wh
Garrett D'Amore wrote:
> 1) The commands increase the size of the text segment. Not only does
> it add new parsing requirements (you have to at least have enough code
> to handle --man, for example), but you also have the text of the man
> pages themselves. While you might like to maintain the
I. Szczesniak wrote:
> On 7/25/09, Garrett D'Amore wrote:
>
>> Roland Mainz wrote:
>>
>>
>>> Garrett D'Amore wrote:
>>>
>>>
>>>
Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>
>
>
>> Personally, I think --man, --html and
On Fri, 24 Jul 2009 23:01:51 -0700 Garrett D'Amore wrote:
> Now let me break down the architectural problems I have with --man (and
> also with --nroff and --troff), as they pertain to Solaris:
> 1) The commands increase the size of the text segment. Not only does
> it add new parsing require
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 l
Roland Mainz wrote:
> Garrett D'Amore wrote:
> > Alan Coopersmith wrote:
[snip]
> Yes, at least we cover the following goals:
> - Familarity: GNU+BSD command line options (which increases
> interoperabilty, not only across GNU but BSD and MacOSX, too)
> - Performance:
> 1. The AST implementions a
Garrett D'Amore wrote:
> Alan Coopersmith wrote:
> > I'm sponsoring this fast-track request on behalf of the
> > ksh93-integration and busybox projects. The timeout is
> > set for Friday, July 31, 2009.
> >
> > -Alan Coopersmith- alan.coopersmith at sun.com
> >Sun Microsyst
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 provi
42 matches
Mail list logo
