Slashdot Mirror

By definition, long and endless testing, the way it works. OS X is UNIX. In fact, Unix 03 standard (Intel distro).

So the Unix you seem to show as dying to add some emotion to your otherwise good article is approaching 10% of market share and completely changed mobile scene (as iPhone runs mini OS X). It is the only serious competitor to MS in Desktop and in same sense, it is the only OS MS would bother to code apps for.

If writing an article about UNIX and mentioning the open group, having such strict standards, OS X is UNIX 03 compliant operating system. Also POSIX is making its way to Mobile in mini form or real form.

Like it or not or downplay as OS from iPhone maker, OS X is UNIX and even more interestingly, it is also Mach based. It is not a very easy thing to achieve, ask any UNIX admin how huge set of tests and standards it requires to get that certificate.

http://www.opengroup.org/comm/press/19-2-nov07.htm

I think that The Open Group would disagree with your overly broad definition of Unix

Then he needs to put a * in the right place; they can still whine about it, but they can't pretend the notion to which "Un*x" or "Unix-like" refers doesn't exist.

I think that The Open Group would disagree with your overly broad definition of Unix

Then he needs to put a * in the right place; they can still whine about it, but they can't pretend the notion to which "Un*x" or "Unix-like" refers doesn't exist.

I think that The Open Group would disagree with your overly broad definition of Unix

That strncpy probably isn't what you're looking for. From here: "If the array pointed to by s2 is a string that is shorter than n bytes, null bytes are appended to the copy in the array pointed to by s1, until n bytes in all are written." So that function isn't a very good idea if your destination buffer is really large and your source buffer is very small.

For a safe strcpy, you're probably going to want something like strcpy(dest, src, (dest src ? dest : src)). You can expand that out to a full if statement if inline conditionals give you a headache.

Okay, so list the systems which are "B" Posix compliant. ie. ps ax shows all processes, while ps -ax only shows processes from user "x"

Huh?

It's "ps -aux" (identical to "ps -a -u x") that brings user "x" into the picture. Plain "ps -ax" (identical to "ps -a -x") has a "-x" option that POSIX does not define. POSIX allows "ps -ax" to be a usage error, but requires "ps -aux" to print processes for user "x".

OpenBSD's ps man page even admits to being non-POSIX, oddly right after claiming to be compliant. (WTF?)

Compare yourself:

• POSIX and UNIX
• OpenBSD

Completely incompatible options include: -e -u

Missing options include: -A -d -f -G -g -n

Other problems are incorrect long ("-l") format, lack of support for multiple users with the -U option or multiple tty with the -t option, missing "etime" keyword... and I think I've abused the pitiful thing enough today.

OS X 10.5 on intel is certified Unix 03 by the Open Group. Other certified Unix include Solaris, HPUX, and AIX.

No. You write a loop that terminates when close() succeeds.

BTW:

http://www.opengroup.org/onlinepubs/000095399/functions/close.html

"If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified. If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified."

You may successfully close the file and never get a successful return from close.

Yes, you can open() a directory on Mac OS X. That in no way contradicts my statement about the standard.

The "Single Unix Specification" you mentioned says you can open() a directory with O_SEARCH, too. MacOS doesn't have that.

Where did you get that idea? At least in the version I saw (http://www.unix.org/single_unix_specification/), the open documentation does not mention O_SEARCH or directories at all.

Either way, I expect you'll be able to fsync() that fd; that's all you need.

The Subversion code I linked to explicitly said that opening a directory fails on some platforms, so your expectation is incorrect.

It isn't a flaw. It is documented and the programmers didn't follow the docs. There is a specific command called fsync to flush the buffers to prevent the problem.
In fact here is a link to that call http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html

Yes if we had a prefect world we would have instant IO but we do not. The flaw is in the application plan and simple.
They didn't use the api properly and it really is just that simple.

The first system to fully conform to POSIX was OpenVMS (the Open- prefix indicated POSIX compliance; previous versions were just called VMS), a system that was very different from UNIX. Windows NT was also POSIX compliant, but didn't implement any of the optional parts of POSIX which, it turns out, includes most of the specification (a large number of calls are required to exist but may return ENOTIMPLEMENTED in all cases). Neither of these are UNIX, although it may be possible to persuade Windows with SFU or Cygwin installed to come close to passing the SUS tests.

One of the nice things about the SUS is that, unlike POSIX, it is free to access. Copies of POSIX still cost money, but you can infer what they say by reading the SUS and checking the bits at the bottom of each page which highlight the SUS extensions to POSIX (and, often, to the C standard, which is also not freely available).

It's also worth noting that you are only allowed to call a system UNIX if it has been certified by the Open Group (who own the UNIX trademark) as conforming to the SUS. The conformance test is for a specific version of an OS on specific hardware. OS X 10.5 on x86 is UNIX, but OS X 10.5 on PowerPC is not. Solaris 10 on SPARC is UNIX, but Solaris 10 on x86 is not. Both OS X on PowerPC and Solaris on x86 will run the same set of programs as their certified counterparts, but Sun and Apple chose not to pay for certification for their system on both platforms. I think the rules were changed recently, but it used to also be the case that the version requirements were very strict, so OS X 10.5 on x86 can be UNIX, but OS X 10.5.1 would have required recertifying.

It wasn't broad. A Unix is a certified Unix. Anything else isn't. Hence GNU--"GNU's Not Unix".

Oh, this was one of those situations where posting on slashdot was easier than googleing, wasn't it?

Here you are, http://www.opengroup.org/openbrand/register/ .

No, but Mac OS 10.5.x can properly be called Unix, but only the Intel version, not the PPC version.

Fair enough about those things being extensions, though many are supported so broadly (the $(()) math syntax, for example) that it surprises people when they don't work. Unless you code on the Almquist or Debian Almquist shell regularly, chances are very good that you'll be in for a rude awakening if you ever switch to it. Things that nearly every /bin/sh implementation on the planet has provided for a decade or more (not just bash) simply don't work in ash or dash because they depend on behavior that isn't explicitly specified in the POSIX spec. That makes operating systems that use those shells great test platforms for testing scripts, albeit painful platforms for actual end users. :-)

That said, I would disagree with your criticism that awk, sed, etc. are not part of the shell and are thus not relevant to a discussion of script portability. If you want to talk only about pure shell scripts that don't actually run any programs, then yeah, they're pretty close to perfectly portable as long as you avoid a handful of gotchas, and they are pretty close to useless, too. In any reasonable discussion of shell scripting, you can't realistically limit discussion to talking about the language itself. You can't do much without exceeding the bounds of shell control statements and shell builtins (which, BTW, vary from shell to shell as well even within the Bourne-compatible camp). Okay, so maybe awk is a little too obscure, but that's just the tip of the iceberg.

Beyond really trivial scripts, most scripts that actually do something useful are likely to have to call, at minimum, sed, grep, echo, and expr; a sizable percentage will also use tr, bc, head or tail. With the possible exception of bc, everything on that list, IIRC, has at least one significant flag difference among Linux, the *BSDs, and Mac OS X, not even counting differences on AIX, Solaris, or any of the other myriad UNIX systems. That's why people find portable shell scripting so difficult; they end up accidentally using some flag or feature that is Linux-specific, BSD-specific, Mac OS X-specific, etc. without knowing they are doing so because the documentation doesn't mention that the flags are not part of the POSIX spec.

The POSIX specification is a good place to start when writing shell scripts that you expect to work correctly on other platforms. If you design to that, you'll only have a handful of compatibility problems (such as the echo -n blah vs. echo 'blah\c' problem).

As for your assertion that tools like awk should stay the same if you change shells, that is only partially true. There are parts of Mac OS X that automatically define magic shell variables (documented in the man pages for the various tools) that turn on or off support for legacy BSD syntax support. This allows POSIX compliance for passing the compliance tests and for general shell scripts while maintaining backwards compatibility for certain critical scripts like parts of startup items, installer preflight and postflight scripts, and so on. So even a given utility on a given OS can't be guaranteed to work the same way in every environment. That's why it is important to pay attention to these sorts of details when writing shell scripts. :-)

Total moderation failure...

Here's how the standard defines the meaning of "seconds since the epoch" in relation to UTC dates: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14
As you can see, the meaning is actually "seconds since the epoch, excluding leap seconds." Always read the definitions.

According to that definition, the time_t value of "Friday the 13th, 2009 at 11:31:30pm UTC" is:
30 + 31*60 + 23*3600 + 43*86400 + (109-70)*31536000 + ((109-69)/4)*86400 - ((109-1)/100)*86400 + ((109+299)/400)*86400
= 30 + 1860 + 39600 + 3715200 + 1229904000 + 864000 - 86400 + 86400
= 1234567890

So, to answer the question which started this: Not including leap seconds.

Besides, it should be "Friday the 13th, 2009 at 23:31:30 UTC." The am/pm notation is not without ambiguities.

The meaning of a UNIX operating system is well defined here.You will notice that it does not define anything about the kernel other than two device nodes. It does, however, specify a C compiler and a large number of C standard library functions. On a GNU/Linux system, these are provided by GNU libc, which calls into the Linux kernel for some functions, but can also support HURD and FreeBSD kernels.

FreeBSD is not a certified UNIX, according to The Open Group, which handles that certification.

Is it true that this rev is the first to be certified as UNIX? I'll take your word for it.

You don't have to take his word for it go to the source, it clearly states that OS X 10.5 is the first and to date only Apple pruduct to bear the open group cert.

Maybe that works in Linux---I haven't tried---but it is definitely neither portable nor POSIX-compliant. The POSIX spec for stty says nothing about it changing the O_NONBLOCK flag, so if an OS modifies that flag with stty raw or -raw, that is a bug. Writing software that depends on a broken behavior is generally a bad idea. Here's the spec for what stty is supposed to do:

stty POSIX spec

Furthermore, it is not even guaranteed that setting O_NONBLOCK in a child process will result in it getting changed in the parent process. If it could be guaranteed across all OSes, I would simply have set the flag once upon entering the app like I do for everything else. It does in Linux. In OSes derived from System-V (AT&T UNIX), however, AFAIK, this does not occur. In BSD OSes, this at least used to behave the way Linux does, though there has been some debate and I'm not sure if it still behaves that way or not. In fact, there are so many portability problems involved with using O_NOBLOCK or O_NDELAY that it almost isn't worth using. It certainly can't be used in anything remotely resembling a portable fashion without getting your hands dirty and writing some C code....

Yeah, it's ugly, but there's just not a viable alternative.

Also calling Mac OS Unix is like calling Windows NT VMS. Sure, you can do Unix stuff on it as that's what it was built on but what makes it Mac OS is all the proprietary stuff Apple have built on top of it.

Mac OS is UNIX: Exhibit A. Anyway, who said UNIX proper couldn't have proprietary components? There are dozens of brands of UNIX with proprietary stuff added, Apple was by no means the first vendor to add their own components to UNIX.

How as a developer is a Mac locking you in? Of course they are control freaks you can't natively run OSX on a typical x86 system sitting around because it has to be their hardware. That doesn't mean that if you have a Mac that you are locked in, you can install windows, Linux and OSX all on the same machine. You can run windows and Linux virtualized in OSX. As someone pointed out OSX is unix 03 certified

So can you explain how it locks you in? Is it locking you into one piece of software is it not letting you run something I'm not aware of? The only think that you get locked in with is that you have to run OSX on a Mac(even then there are hackintoshes). I would really like to know what you mean.

Come to think of it what do you even mean by locking you in?

You would think that the fact that OS X is UNIX 03 certified might be of some interest to developers as well.

Sure, maybe not as much as the reasons stated above, but... it is worth mentioning. And just the fact that it is any flavor of Unix-like OS is attractive to many.

I took a hiatus too. I didn't miss the show - I was just sidelined playing with stuff I knew was good. It didn't take me more than three months of Windows development to figure out that it was a trap. The last month of that I spent looking for specifications for a sound card so I could do audio capture before I discovered that the company that wrote the drivers for SoundBlaster was actually a wholly owned Microsoft subsidiary that wasn't giving up the specs at any price or terms I could live with.

I started with Unix in late 1981, Linux in late 1995 and I have very nearly spent more time with Linux than Unix. Unix in the form of its descendents Linux and Mac OS X is still very much alive.

OS X bought Unix certification because it was an important selling point. They had to do significant engineering to qualify for the mark, but they have it not in recognition of their engineering, but because they licensed the right to call OS X a Unix from The Open Group.

Unix is not what it was in the 1960s and 1970s - the love child of great minds. It's now just a service mark. A brand. Intellectual property law ruined it, and Ransom Love killed it with his hubris. It's time to let it go.

No, BSD is not Unix. To say that BSD is Unix is perhaps like saying that grass is rice. That's not quite correct. Some grasses are rice. Some grasses are differently purposed and differently used. They may share some genetic material but a putting green is not a bowl of cereal.

However, all rices are grasses. All of the currently used Unixes owe the vast majority of their genetic material to the University of California at San Diego and Berkeley. It would be fair to say that modern Unixes are all Berkeley System Developments with proprietary "enhancements". This is perhaps the acknowledgment you were looking for. That's not the same thing as saying that BSD is Unix.

But the whole of a Unix was never Open until Open Solaris, which as I said is still in doubt. In fact, since Open Solaris hasn't been accepted by The Open Group, who bought the name "Unix" and certify Unix systems, it's not a Unix either. Nor is any particular flavor of BSD.

And still... Linux Is Not UniX. It was never intended to be. Linux is Linux. It's its own brand and that's all it needs to be. It doesn't need to carry forward the heritage from the Information Science pirates of a byegone era. To the extent that it pays homage to the great minds that went before, it's standing on the shoulders of giants as all great art does. It doesn't steal their intellectual property -- it just acknowledges the best of their ideas in new and creative ways and creates on that foundation new expressions that, in our litigation constrained environment, can be used and expanded upon freely.

posix_fadvise and posix_madvise seem to be standard posixy way to give hints to the cache. madvise(..) and fadvise(..) also exist granted some of the kernels don't properly use the hints.

posix_fadvise and posix_madvise seem to be standard posixy way to give hints to the cache. madvise(..) and fadvise(..) also exist granted some of the kernels don't properly use the hints.

Well written applications will tell the memory manager what their expected usage pattern will be using functions like posix_madvise and posix_fadvise.

If an application is uploading a 4GB data file and uses POSIX_FADV_SEQUENTIAL followed by POSIX_FADV_DONTNEED for the bits it's done with, then the memory manager shouldn't do stupid things like "trying to cache a 4 GB data file which was uploaded the other night".

Of course, this presupposes well written applications, which may be a bit much to ask...

Well written applications will tell the memory manager what their expected usage pattern will be using functions like posix_madvise and posix_fadvise.

If an application is uploading a 4GB data file and uses POSIX_FADV_SEQUENTIAL followed by POSIX_FADV_DONTNEED for the bits it's done with, then the memory manager shouldn't do stupid things like "trying to cache a 4 GB data file which was uploaded the other night".

Of course, this presupposes well written applications, which may be a bit much to ask...

http://www.apple.com/macosx/technology/unix.html http://www.opengroup.org/openbrand/certificates/1190p.pdf *cough*

That's a great site.

Also, The Open Group's SUS Reference for UNIX programming in C/C++. Better than googling.

My bad... I hadn't realized it, but the client also is UNIX certified, when run on Intel-based Macs.
http://www.opengroup.org/openbrand/register/brand3555.htm

P.S. No, the Open Gorup is not a bunch of Mac fanboys.

Then you really don't understand what Unix is.

The user-level UI stuff (for example, all the frameworks that make Mac OS X way much more than just another Unix) is completely orthogonal to whether an OS is Unix. While these days everybody seems to think that Unix means X11, that's only the . CMU's Andrew project's wm, SunWindows, NeWS, and others (including NeXTStep) all competed with X11 years ago, and they were all Unix - back then, they all tended to even have fairly incompatible sets of system calls (which inspired the creation of Posix compliance).

Mac OS X is Unix. It just happens to be much much more than just Unix, and it's the widest deployed desktop Unix in the world today.

Unfortunately, it doesn't work very well, since POSIX doesn't (AFAIK) specify the largest write that is guaranteed to be atomic. Hence, unless you're careful, you may end up with log entries from two processes being interleaved.

Indeed. Thanks for the info.

Unfortunately, it doesn't work very well, since POSIX doesn't (AFAIK) specify the largest write that is guaranteed to be atomic. Hence, unless you're careful, you may end up with log entries from two processes being interleaved.

"it is dissapointing from my point of view!"

I'm not surprised. Check out the kernel it's running on.

guest@goosh.org:/web> uname -r
    1) uname
The uname() function shall return a string naming the current system in the character array sysname. Similarly, nodename shall contain the name of this node ...
http://www.opengroup.org/onlinepubs/009695399/functions/uname.html

    2) uname 1

http://www.freebsd.org/cgi/man.cgi?query=uname&sektion=1

    3) uname function.
uname is NOT in the ANSII library but is handy for getting system information. It will return handy things like:. System type (name). Host name (Nodename). ...
http://www.space.unibe.ch/comp_doc/c_manual/C/FUNCTIONS/uname.html

    4) Unix man pages: uname (2)
UNAME(2) Linux Programmer's Manual UNAME(2) NAME uname - get name and information about current kernel SYNOPSIS #include int uname(struct ...
http://www.rt.com/man/uname.2.html

Forget apple.com. How about The Open Group saying that OS X is Unix?

It has been my experience that people that exclaim how Mac OS X is a "true UNIX" are often the type that never touch the command-line and haven't experienced the level of crap that is apple glomming-on all their filesystem meta-data to the things that resemble unix the most.

I suppose that would include the Open Group which does all the certifications for Unix. FYI, the Open Group was the entity that AT&T spun off to handle Unix certification and it owns the Unix trademark. It has certified OS X Leopard for Intel as UNIX 03. Apple has done a lot of customization for OS X but so has every other Unix vendor.

http://www.opengroup.org/openbrand/register/brand3555.htm

I would say no, there's no corresponding UNIX 03 certification for 10.5 on PPC.

Not quite a classic like the Apple material, but the Motif style guide is likely to be helpful: http://www.opengroup.org/pubs/catalog/t254.htm

Linux would fail certification because of the differences between the Single UNIX Specification and Linux Standard Base. These incompatibilities are documented on the website of The Open Group:

http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=6075

http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=5992

Linux would fail certification because of the differences between the Single UNIX Specification and Linux Standard Base. These incompatibilities are documented on the website of The Open Group:

http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=6075

http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=5992

• ssh
• aptitude (or apt-get when I forget about aptitude)
• svn
• ls
• cd
• cp
• rm
• mv
• less
• grep
• fgrep
• su / sudo
• wc
• tar
• w
• ps
• kill
• vi / nano
• man
• which

1. Utility names should be between two and nine characters, inclusive.
2. Utility names should include lowercase letters (the lower character classification) and digits only from the portable character set.

time_t can be unsigend (sic)

Yes. The C standard requires that time_t is an arithmetic type (see section 7.23.1 of the C99 standard). That means it can be an integer or floating type (see section 6.2.5 of the C99 standard), and therefore could be a float, double, long double, a complex-number (WTF?), a char, a signed integer type or an unsigned integer type. The C standard requires that (time_t)(-1) is not a valid time value, so it can be used it indicate a failure (as a previous poster pointed out, this is what mktime() can do; see section 7.23.2.3 of the C99 standard).

POSIX requires that a time_t records time in seconds and must be an integer or real-floating type. POSIX also requires that the time() function return the number of seconds since the Epoch, and therefore implicitly need not be able to represent times before the Epoch, so a time_t need not be a signed type. POSIX also provides the following rationale.

Implementations in which time_t is a 32-bit signed integer (many historical implementations) fail in the year 2038. IEEE Std 1003.1-2001 does not address this problem. However, the use of the time_t type is mandated in order to ease the eventual fix.

POSIX also notes the following as a future direction.

In a future version of this volume of IEEE Std 1003.1-2001, time_t is likely to be required to be capable of representing times far in the future. Whether this will be mandated as a 64-bit type or a requirement that a specific date in the future be representable (for example, 10000 AD) is not yet determined.

time_t can be unsigend (sic)

Yes. The C standard requires that time_t is an arithmetic type (see section 7.23.1 of the C99 standard). That means it can be an integer or floating type (see section 6.2.5 of the C99 standard), and therefore could be a float, double, long double, a complex-number (WTF?), a char, a signed integer type or an unsigned integer type. The C standard requires that (time_t)(-1) is not a valid time value, so it can be used it indicate a failure (as a previous poster pointed out, this is what mktime() can do; see section 7.23.2.3 of the C99 standard).

POSIX requires that a time_t records time in seconds and must be an integer or real-floating type. POSIX also requires that the time() function return the number of seconds since the Epoch, and therefore implicitly need not be able to represent times before the Epoch, so a time_t need not be a signed type. POSIX also provides the following rationale.

Implementations in which time_t is a 32-bit signed integer (many historical implementations) fail in the year 2038. IEEE Std 1003.1-2001 does not address this problem. However, the use of the time_t type is mandated in order to ease the eventual fix.

POSIX also notes the following as a future direction.

In a future version of this volume of IEEE Std 1003.1-2001, time_t is likely to be required to be capable of representing times far in the future. Whether this will be mandated as a 64-bit type or a requirement that a specific date in the future be representable (for example, 10000 AD) is not yet determined.

I think OS X is not a very 'native UNIX environment'

I think you're wrong. :) OS X is, in fact, an officially certified UNIX[tm]. http://www.opengroup.org/openbrand/register/brand3555.htm It conforms to the Single UNIX Specification Version 3. It's not just "UNIX-like," it is UNIX. Linux is not. :) (Granted, only because (presumably) no one cares enough to cough up the $$ to certify a Linux distribution, and/or put in the effort it would (again, presumably) take to tweak Linux to pass the certification process.)

what's funny is that in an attempt to mimic Windows the KDE guys decided to also "borrow" from CDE.

I remember using it the first time and thinking "I hate CDE, why would I like this?"

So let's take a von Neumann architecture, which has inherent security problems due to it using the same address space for data and code

Oh crap! If only there were a way to partition the address space into data and code parts, and have the processor enforce that! Oh wait, there is.

I never thought I'd see these two words together. UNIX is what happens when you meet a set of interfaces defined by a standards body known as The Open Group.

This Unix certification seems to only apply to one particular compilation of the OS. Apple only did this for Mac OS X 10.5 for the Intel version of their OS, not the PPC version. I'm not quite sure whether subsequent updates to the software invalidate this though. See here