Talk:Single UNIX Specification

History

Would it be possible for the article to mention the history of the drafting of the standard, including major changes that went into each version (for example, at some point the separate "UNIX environment" (shell) standard was rolled into mainline POSIX)? —Preceding unsigned comment added by 199.46.198.232 (talk • contribs) 07:39, January 11, 2005

"Shell and Utilities - a list of utilities and a description of the shell, sh."

Links to a history of the Bourne shell with little info on other shells and NO utilities.

Perhaps someone could add better links. Thank you.

DGerman (talk) 14:35, 29 January 2009 (UTC)

Standard shell

Is the standard shell for POSIX really "Bourne"? —Preceding unsigned comment added by 65.95.10.109 (talk • contribs) 13:51, March 6, 2005

I do think so -> Please check that at the opengroup's site: Posix 3 aka Unix 3 are freely readable there. But: What does the Term "standard shell" mean? - M-e-leypold 16:29, 16 July 2005 (UTC)

OK, I'm augmenting my previous answer: Yes, sh is the "standard shell. Corresponding entry in Unix03 = Posix3 says "sh - shell, the standard command language interpreter". "Standard" means: (a) This shell must be in a conformant system. (b) It's the only shell that must be in a conformant system. - Regards, M-e-leypold 16:38, 16 July 2005 (UTC)

Linux vendors

"Most" Linux vendors don't certify? This should be removed ... has *any* Linux distro *ever* been certified and sold as a UNIX system? —Preceding unsigned comment added by Hobart (talk • contribs) 12:01, June 4, 2005

AFAIK: UNIFIX. Do they still certify? -> I don't know. - M-e-leypold 16:29, 16 July 2005 (UTC)

Unix95

There was a Unix95 mark. Shouldn't that also be mentioned in the article? . M-e-leypold 16:29, 16 July 2005 (UTC).

I have added UNIX93 and UNIX95

--ManoloKosh 15:00, 21 March 2007 (UTC)

Shell Clarification

The SUS shell, or POSIX shell, includes features the Bourne shell doesn't have, including off the top of my head job control, command line editing, and the $(command) parallel to the `command` construct. It's perhaps unfortunate that it's still called "sh".

In Solaris, /usr/bin/sh will (or did) call the Bourne shell, while /usr/bin/xpg4/sh links to /usr/bin/ksh. PhGustaf (talk) 07:03, 26 November 2007 (UTC)

Solaris on PPC

I was deeply involved with the Solaris 2.5.1 PowerPC certification. IBM and Motorola, among others, made computers that used PC memory and controller cards, but PowerPC processors. They didn't make them for long. For complicated reasons, TOG required that we get the certification done in 30 days rather than the 180 we were expecting. I do realize that my unsupported memory is not fit material for an encyclopedia. PhGustaf (talk) 20:24, 9 December 2007 (UTC)

Capitalization?

Why is Unix in this article title (and content) in all caps when the actual Unix page has it spelled Unix (as opposed to UNIX). There needs to be some consistency here, either by moving this article to Single Unix Specification or by moving Unix to UNIX. I'm not going to do it myself until I get some feedback,

Thanks -- stevenrasnick Monday, November 3, 2008 10:20 PM.

Approve Per [discussion], go for it. Richardc020 (talk) 03:41, 17 June 2013 (UTC)

Version 4?

Is IEEE Std 1003.1-2008 part of SUSv4 or v3? Is SUSv4 even a standard (there seem to be no certifcations for it)? —Preceding unsigned comment added by 173.88.150.87 (talk) 00:14, 7 May 2009 (UTC)

Snow Leopard

I am not sure if Mac OS X Snow Leopard (10.6) is Open Brand UNIX 03 registred. The linked documents are for Mac OS X Leopard (10.5) only. —Preceding unsigned comment added by 213.226.213.211 (talk) 12:26, 30 August 2009 (UTC)

• It seems that the problem has been solved :) Chilkes (talk) 16:11, 1 September 2009 (UTC)

Difference between Single Unix Specification and POSIX

What is the difference between Single Unix Specification and POSIX? --Abdull (talk) 23:37, 12 January 2010 (UTC)

POSIX is a single standard based on UNIX. Single UNIX Specification is a small collection of standards, all related, and all based on UNIX. Basically, SUS is an attempt at combining several standards to create something a standard that's much more specific than any of it's parts, thus further ensuring better compatibility between UNIX and UNIX-based operating systems than any one of it's parts would. — Preceding unsigned comment added by Pikidalto (talk • contribs) 16:56, 8 June 2014 (UTC)

OSX not POSIX?

The reliable source for this would be The Open Group, not some random individual citing gossip. TEDickey (talk) 00:55, 24 February 2016 (UTC)

who cares anyway? single unix speification is dead most unixes never were certified. a standard that nobody complies is so very useless! the word single means there is no single compliant system. people don't care about posix certification anymore (if they ever did, except for some corporate marketing drones). all that matters is: does it work on OSX and linux. these are the only unix platforms that matter today. the other unixes are dead anyway. that's the funny thing... the most important unixes are linux, OSX and freebsd; and of those only OSX went for this bullshit, and shily likes to spam that OSX should not have been certified either. gosh, rename it to "single shillix specification" then, grumpy old man! you must be using the only compliant computer. — Preceding unsigned comment added by 79.214.38.230 (talk) 02:20, 26 March 2016 (UTC)

On 23 February 2016, Schily made an edit, to the effect that OS X does not "comply" with UNIX 03, with the rationale "Apple returns zeroed members si.si_code and si.si_pid in siginfo_t for the mandatory waitid() and thus is not POSIX". In my opinion -- I have been member of 3 standardization groups, one of them produced an ISO standard, and I have been implementing standards and test suites --:

• Every software system has bugs (even the test suites for standards).
• All standards can support different readings in the details. Therefore you often encounter the case that what one developer considers a compliance issue, another developer sees as a non-issue.
• That a software complies with a standard means

1. that its list of compliance issues is small and consists of only minor issues, and
2. if there is an organism that certifies the compliance, the software passes the compliance test suite.

Whether an operating system fills in si.si_code for waitid() is extremely irrelevant, because this member has been designed for signal handlers, i.e. in-process handling of signals. Aside from debuggers, I cannot imagine any application that uses si.si_code in waitid(). Schily, it is not appropriate to consider a software to be non-compliant because of such minor details. If you want, you can set up a list of non-compliance issues for the existing implementations; this would be a basis for determining the degree of non-compliance of the various implementations. But removing the label "compliant" from one implementation just because you found 1 compliance issue is not appropriate. Professor Tournesol (talk) 20:09, 8 April 2016 (UTC)

waitid() is a POSIX basic feature and not a minor detail. Please note that it exists in POSIX since more than 20 years. Returning 8 bits instead of 32 bits in waitid() is similar as if read(2) did not allow to read more than 255 bytes at once. Schily (talk) 09:56, 12 April 2016 (UTC)

I disagree here. The ability to wait for processes to terminate is a basic POSIX feature. But the waitid() function is not:

1. Most applications use the waitpid() function, not the waitid() function for this purpose, and it does not have the issue with si.si_code and si.si_pid.
2. This function was not implemented in the then current versions of FreeBSD, NetBSD, OpenBSD around 2005.

Professor Tournesol (talk) 19:28, 15 April 2016 (UTC)

A sledge is no scooter and thus there is no wonder that it has no wheels. The same applies to non-POSIX operating systems: they are not expected to have POSIX features. POSIX on the other side makes waitid() a required interface since 20 years and waitid() was introduced in UNIX 26 years ago. I recommend you to inform yourself about POSIX before answering... Schily (talk) 09:42, 18 April 2016 (UTC)

The Open Group certifies that OS X 10.11 complies with UNIX 03. The Open Group is a reliable and authoritative source on who complies with their standards and who does not (given the existence of formal test suites, and formal procedures for requesting standards interpretations and errata and challenging tests); Schilly's personal observations and interpretations are not. If Schilly believes that The Open Group has got this wrong, they should take it up with them, not here. SJK (talk) 13:34, 25 April 2016 (UTC)

This is your miss-interpretation....

The Open Group did run a set of certification shell scripts and these scripts (that are known to be problematic/incorrect in many cases) did pass. This is a different statement from "OSX is POSIX compliant". Note that some of the test scripts have been fixed since OSX was certified and that OSX would not pass the current state of the test scripts (even for the latest "certified" version of the POSIX standard for OSX).

BTW: The test scripts have been developed on a genetic UNIX and on such a platform, they need to test less than on a non-genetic UNIX like OSX, since most of the code in a genetic UNIX was tested to be correct since a long time. Schily (talk) 10:12, 26 April 2016 (UTC)

You claim OS X is not POSIX compliant. You are not a reliable source. That is your personal opinion which cannot be cited in an encyclopaedia. The Open Group certifies OS X as UNIX 03 compliant. Unlike you, The Open Group is an reliable source for matters of certification under its own standards. SJK (talk) 21:37, 26 April 2016 (UTC)

Given that I am a member of the OpenGroup (POSIX) standardization core team, I am a more reliable source than you and you should finally learn that being "POSIX certified" definitely does not verify that something is "POSIX compliant". Schily (talk) 11:25, 27 April 2016 (UTC)

Taking you at your word that you are indeed a member of that team, how are we supposed to know whether your personal opinion is the consensus of the team or just a minority view? If you believe "POSIX certified" != "POSIX compliant", can you produce a reliable source which states that? Also, in regards to your "I am a more reliable source than you" comment, in the context of Wikipedia a "reliable source" generally means a document that can be cited (whether a web page or a dead tree book), not an individual. Personal testimony (neither mine nor yours) is generally not acceptable as a reliable source. SJK (talk) 22:19, 27 April 2016 (UTC)

In this case, I recommend you to read: Regulatory compliance. Given that OSX does not conform to some important POSIX interface definitions, it cannot be seen as POSIX compliant even though it has been certified using scripts that let OSX pass because of known and meanwhile fixed bugs. The problem with the bugs has been discussed in the Open Group and the Open Group makes mail and other written discussions commonly available. Schily (talk) 10:39, 28 April 2016 (UTC)

I don't understand what regulatory compliance has to do with this. Regulatory compliance is about compliance with government regulations, while POSIX generally speaking isn't a government regulation, it is an industry standard. How about we look at the definition of the English word certify? One of the definitions which Merriam-Webster gives is "to say officially that something or someone has met certain standards or requirements". So, when The Open Group certifies OS X 10.11 against UNIX 03, they are officially saying that OS X 10.11 meets the UNIX 03 standard, or in other words conforms with it. Certification is an official statement or guarantee of conformance with a standard. The existence of bugs in the official test suite is irrelevant; the test suite will always contain bugs, and as long as the test suite continues to be maintained, those bugs will be fixed as they are discovered; OS X 10.11 fails some of the tests at present, but they have been given a temporary waiver (waiver number MSF.X.0113, expiry date 2016-08-11); in order to get this waiver, I understand they have to give a formal commitment to fix the failing tests within a reasonable timeframe, and I expect the vehicle for doing so would be a future patch. If only bug-free software could possibly comply with POSIX, then no software ever has or ever will be POSIX compliant, because software will always have bugs, and compliance test suites will always have bugs too. SJK (talk) 12:09, 28 April 2016 (UTC)

OK, a last time: OSX has been certified but it does not conform with the standard for many reasons. One reason is that waitid() does not work as expected. With the current (bug-fixed) versions of the compliance test scripts, it would not pass. Schily (talk) 12:14, 28 April 2016 (UTC)

Does temporary waiver MSF.X.0113 address the waitid() issue? Would it be true to say, that it conforms to UNIX 03 minus MSF.X.0113? Or are you alleging there are conformance issues in OS X 10.11 beyond what that waiver addresses? SJK (talk) 13:03, 28 April 2016 (UTC)

I am not responsible for doing the tests. I know that Apple recently implemented some fixes to waitid() in the most recent OSX release, so they now seem to fill in si_pid and si_code, but they still only return 24 bits from the exit status. Schily (talk) 13:07, 28 April 2016 (UTC)

To quote UNIX Certification -- The Brand:

In licensing the UNIX brand a vendor warrants and represents that every certified product:

• Conforms to the specification.
• Meets The Open Group's test and certification requirements.
• Will continue to conform to the specification.
• Will be rectified within an agreed time should it be found to be non-conformant.

By licensing the UNIX 03 brand, Apple has warranted and represented that OS X 10.11 conforms to the specification. Under the fourth bullet point, if problems in compliance are found, it agrees to rectify them within a certain timeframe. (I understand the "temporary waiver" they have falls under this bullet point.) No evidence has been presented that it has failed to rectify problems formally brought to its attention within the timeframe required. All software has bugs, so if software is found to not comply with a standard in some corner case, but the vendor has made a commitment to acknowledge that as a valid bug and fix it within a reasonable timeframe, that doesn't negatively impact the conformance status of the software overall. Conformance to a standard is a process and an ongoing commitment. SJK (talk) 13:20, 28 April 2016 (UTC)

References

"obvious facts"

As usual, facts cited on Wikipedia need a reliable source. For example, stating that something is required for POSIX compliance requires a source from the accrediting organization, rather than random opinions of various editors. There is by the way a thread started here which was not concluded. TEDickey (talk) 01:13, 23 March 2016 (UTC)

As usual, you appear to be uninformed and it is obvious that you would revert "1 + 1 = 2" only if you don't like the result even though everybody knows it is true.

waitid() is part of POSIX since the mid-1990s. The rules of POSIX are to integrate existing implementations exactly the way they exist in the reference implementation which is SVr4 for the waitid() call as waitid() appeared in 1989 on SVR4 and a few years later was introduced in POSIX. In addition, the current POSIX text for exit() is:

        The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only
        the least significant 8 bits (that is, status & 0377) shall be available from wait( ) and waitpid( ); the
        full value shall be available from waitid( ) and in the siginfo_t passed to a signal handler for
        SIGCHLD.

Linux is well known for ignoring this. BTW: We could save a lot of time if you did first try to inform yourself before you revert text. Schily (talk) 13:55, 23 March 2016 (UTC)

Schily, please follow the Wikipedia policies of civility and no personal attacks. Phrases like "As usual, you appear to be uninformed" are personal attacks. Professor Tournesol (talk) 20:17, 8 April 2016 (UTC)

Professor Tournesol before you attack the wrong people, please inform yourself about what happened before. Mr. Dickey repeatedly attacks other people and it is obvious that this is the way he likes to get replies :-( The problem with this person is that I've never seen a civil message from him and "as usual" just describes the typical discussion practice from this person, so it is not a personal attack by itself. Schily (talk) 09:52, 12 April 2016 (UTC)

Schily, from what I can see in the 3 edits of this page, Mr. Dickey criticizes the content that you added, without personal attacks. If you see his messages as "attacking other people", you need to learn to distinguish messages that critize the text/content from messages that attack the person. Additionally, even if you get a message that is a personal attack (by your judgement), you should not reply with a personal attack; see no personal attacks. Professor Tournesol (talk) 19:08, 15 April 2016 (UTC)

None of your comment is relevant to the issue being discussed. Where is your reliable source on The Open Group website (or equivalent, e.g., IEEE) supporting your opinion regarding accredition?

Thank you for confirming that your mission is to prevent correct and verified information to appear on Wikipedia in case you don't like that information.

I guess that you are able to read and did read the quotation from the standard. So there of course is a reliable source for my statement. You on the other side don't give a reliable source as usual. Schily (talk) 10:18, 24 March 2016 (UTC)

SCCS - mandatory or optional for SUS compliance

Based on SUS:sccs[1][2], my understanding is that sccs is optional and therefore its absence would not pose a problem for certification. It says "SCCS and its associated utilities are part of the XSI Development Utilities option within the XSI extension." Correct me if I'm wrong, ideally with a source claiming otherwise. I have removed sccs from a sentence linking sccs to lack of compliance. I double-checked at Stack Overflow[3]. --Dan Polansky (talk) 14:49, 10 July 2022 (UTC)

For what it's worth, macOS 1) has achieved compliance and 2) doesn't have SCCS. Guy Harris (talk) 18:59, 10 July 2022 (UTC)

The idea that SCCS is optional is further reinforced by SUSv4 authorized guide[4]:

"UNIX system will provide all the tools in XCU, with the following provisions:

• The DEVELOPMENT utilities need not be provided. These consist of:

  admin,cflow,ctags,cxref,delta,get,lex,make,nm,prs,rmdel,sact,sccs,str ip,unget,val,what,yacc

• [...]

--Dan Polansky (talk) 18:06, 20 July 2022 (UTC)

Change of POSIX:2001 to POSIX.1-2001

I have changed POSIX:2001 to POSIX.1-2001 and similarly for later years since I could not find the colon-forms in authoritative sources.

Some sources:

• SUS 2008 edition[5] mentions "POSIX.1-2008".
• SUS 2018 edition[6] mentions "POSIX.1-2017".
• Read The Single UNIX® Specification, Version 3[7] mentions "POSIX.1-2001, UNIX 98, UNIX 95, POSIX.1-1996, POSIX.2-1992".
• standards(7) man page in man7.org[8] mentions "POSIX.1-2001".
• POSIX.1 (7) man page for Solaris[9] mentions "POSIX.1-2001", "POSIX.1-2004" and "POSIX.1-2008" and has a longer list in table "History: POSIX Standards". It also mentions "SUSv3" as POSIX.1-2001 and "SUSv4" as POSIX.1-2008.
• Python tarfile[10] mentions "POSIX.1-1988" and "POSIX.1-2001".
• Update normative reference to POSIX[11] at open-std.org mentions "POSIX.1-2001" and "POSIX-1.2008".

The dash-forms are also used in the current POSIX article. --Dan Polansky (talk) 19:47, 11 July 2022 (UTC)

compress - mandatory or optional

It is not very clear whether compress is optional. On one hand, it is marked as "[XSI]." On the other hand, it is not listed in SUSv4 authorized guide[12] in the following paragraph:

"UNIX system will provide all the tools in XCU, with the following provisions:

• The DEVELOPMENT utilities need not be provided. These consist of:

  admin,cflow,ctags,cxref,delta,get,lex,make,nm,prs,rmdel,sact,sccs,str ip,unget,val,what,yacc

• [...]

It would have to be clarified whether "[XSI]" alone is sufficient for something to be optional for application of UNIX brand.

The guide says "For example,if functionality is marked with XSI in the margin, it will be available on all UNIX certified systems, but may not be available on systems only supporting the base POSIX.1 requirements." And it says "There are 45 margin codes defined in total in XBD,Section 2.1.6, Options. 40 of these reflect optional features defined within the POSIX base standard, six of which are mandatory in the Single UNIX Specification (FSC, TSA, TSH, TSS, UP, and XSI)."

My reading of this is that "[XSI]" mark alone does not make something optional for SUS compliance; it may be optional in POSIX but not in SUS. --Dan Polansky (talk) 18:13, 20 July 2022 (UTC)