2017-04-24 11:42:12 +0200, Joerg Schilling: [...] > Alan Coopersmith <[email protected]> wrote: > > > That is incorrect. The "update XXX" naming has always been internal to > > Solaris. > > Solaris 10 and prior releases used the date for the marketing name > > ("Solaris 7 > > 8/99", "Solaris 10 8/07", and so on). Solaris 11 adopted the Oracle naming > > conventions, so "Solaris 11 update 1" is marketed as "Oracle Solaris 11.1", > > "Solaris 11 update 3" is "Oracle Solaris 11.3", and so on. > > > > Whether or not interfaces may be broken depends on the declared interface > > stability level - Private or Volatile interfaces can be broken at any time; > > Committed interfaces should not be broken in an update release, whether it's > > named Solaris 10 8/07 or Solaris 11.3. I believe all non-deprecated > > interfaces > > specified by the POSIX & X/Open standards are Committed. > > So is it possible that Stephane is correct and some POSIX interfaces may have > been broken meanwhile? [...]
Solaris 11 is compliant when doing a "desktop" or "full server" install, not when doing a "small server" install. That's why I'm saying that claiming that "Solaris 11" alone is compliant is misleading. According to the guy at https://unix.stackexchange.com/questions/360359/posix-awk-on-solaris-11/360380#360380 it was already the case in Solaris 10, so it's not been "broken" in between 10 and 11 technically. My main concern here is that the Open Group doesn't make it clear what exactly is being certified. >From my perspective as an application (script) writer, POSIX scripts can't be ported to Solaris, you need a dependency on the optional xcu4/xcu6 packages. POSIX scripts wont work out of the box on some system, you need to request the administrator to install some packages. (contrary to what the certificate issued by the opengroup seems to imply). > > > While people know that on Solaris it was sufficient to prepend your PATH > > > with /usr/xpg6/bin:/usr/xpg4/bin to get POSIX behavior, > > > > Hopefully they know that is the current implementation, but the standard > > mechanism is "getconf PATH" as defined in: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/confstr.html > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/getconf.html > > so that if we add /usr/xpg7/bin in a future version, they'd get that too. > > BTW: One problem I see with this method is that there are different versions > of > the standard and that it may be hard for people to know that they would need > to > call > > /usr/xpg6/bin/getconf PATH > > to get the right one. Do you see a better way? [...] >From what I understand, you'd do PATH=$(/usr/xpg6/bin/getconf PATH):$PATH || exit if you *required* SUSv3 conformancce (SUSv2 would not be enough) and PATH=$(/usr/xpg4/bin/getconf PATH):$PATH || exit for SUSv2 compliance. I don't know what /bin/getconf PATH gives you if xcu4 is not installed. PATH=/usr/xpg6/bin:/usr/xpg4/bin:/bin Would give you SUSv3 compliance if xcu6 is installed, SUSv2 if only xcu4 is installed and non-POSIX antiquated environment otherwise (which would likely cause your script to fail). So you don't know what you get. -- Stephane
