Thank you for the clarification. Btw, I meant importing sed from
Net/Free/Open BSD in item #3 below. Not importing (or otherwise
touching) the very crusty stuff located in Solaris' /usr/ucb.
Its really unfortunate that there is such large differences in how these
tools behave.
-- Garrett
Don Cragun wrote:
> >From psarc-intern-list-request at sun.com Thu Apr 10 17:52:00 2008
>
>> Sorry, I just saw the answers to question #1 in section 4.2. (I.e. "no".)
>>
>> I'll go back under my rock now.
>>
>> -- Garrett
>>
>> Garrett D'Amore wrote:
>>
>>> A few questions (and note that none of these are necessarily any cause
>>> to change anything about this case):
>>>
>>> 1) Can GNU sed become a full replacement for our sed (at least
>>> /usr/bin/sed)? (Yeah, I know its GPL, but so what... it seems like
>>> our own implementation has probably grown crufty over the years, and
>>> is unfortunately also encumbered.)
>>>
>
> As you already noted, the answer is "no".
>
>
>>> 2) If the answer to #1 is "no", would it be possible to introduce some
>>> of the GNU improvements (functional equivalents -- obviously the GPL
>>> requires a totally separate implementation) to our sed, or
>>>
>
> No. Using the standards conformance tests on /usr/xpg4/bin/sed Carol
> found no errors (as required for UNIX branding). Using the same tests
> on /usr/bin/sed found 38 failures. Using the same tests on gsed found
> 14 failures (and 11 of those were not failures in common with
> /usr/bin/sed). People depending on the actions of any one of these
> three will not be likely to be happy using either of the other two as a
> replacement, and merging features of any two together will break
> features of at least one of the versions.
>
>
>>> 3) Would it be possible to convert to using BSD sed (possibly with
>>> GNU-workalike-feature enhancements)?
>>>
>
> /usr/ucb utilities are present only for SunOS 4.x compatibility. There
> is no funding to start enhancing or merging of these utilities with GNU
> (or any other) enhancements.
>
>
>>> Interestingly enough, the only documented difference I can see between
>>> XPG4 sed and Solaris sed is the handling of the "l" pattern space --
>>> xpg4 is a bit nicer. How does GNU sed compare here?
>>>
>>> Architecturally, I'd prefer to have a single sed, but I understand
>>> that GNU features are probably required for FOSS support. A second,
>>> lesser choice is to have the features in our "standard" sed which
>>> provide feature equivalence, so that developers don't feel that they
>>> have no choice but to use GNU sed when developing for Solaris.
>>>
>
> The biggest difference is that POSIX, SVID3, and GNU have different
> definitions for the term "regular expression" (especially in the
> handling of non-US ASCII character sets). So the sed man pages look
> very similar, but since regular expressions control a very large part
> of what sed does, they all behave differently even when using the same
> command line options and sed commands.
>
> - Don
>
>
>>> Thanks.
>>>
>>> - Garrett
>>>
> ... ... ...
>
