>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 ... ... ...
