Frequently Asked Questions
- What is the difference between "UNIX System" and "UNIX system?"
- What is the difference between Unix and UNIX?
- Is Mac OS X a UNIX system?
- Is FreeBSD a UNIX system?
- Is Linux a UNIX system?
- Is Solaris a UNIX system?
- The makefiles in the source code's "std" directory try to run "nawk," but I don't have that command on my system. What do I do?
- When I run the example in Figure 11.5 on a Mac OS X system, why do I get a segmentation fault?
- In the example in Figure 16.9, why do successive attempts to connect fail when the first one fails?
- Why doesn't some of the sample code build on Mac OS X, version 10.4?
- When I run the example in Figure 11.2 on a Linux 2.6 system, why are the process IDs the same?
When we speak of the UNIX System itself as an entity, we capitalize the 'S' in System. When we are speaking about a possible implementation of the UNIX System or a particular UNIX system, we use a lower-case 's'.
The Unix operating system was developed at AT&T Bell Laboratories. When AT&T registered the name as a trademark, they capitalized the name to UNIX. Today the trademark is owned by The Open Group. For a system to call itself UNIX, it needs to meet certain criteria, pass conformance tests, and license the name.
As of version 10.5, Mac OS X has been formally certified to be a UNIX system.
While FreeBSD resembles a UNIX system and provides a UNIX-compatible environment, it has not yet been formally certified as a UNIX system. On the other hand, if it looks like a duck, walks like a duck, and quacks like a duck, then it's probably a duck.
While Linux resembles a UNIX system and provides a UNIX-compatible environment, it has not yet been formally certified as a UNIX system. On the other hand, if it looks like a duck, walks like a duck, and quacks like a duck, then it's probably a duck.
Yes, Solaris has been formally certified to be a UNIX system.
- The makefiles in the source code's "std" directory try to run "nawk," but I don't have that command on my system. What do I do?
ln /bin/gawk /bin/nawk
or
ln -s /bin/gawk $HOME/bin/nawk
or edit the makefile.
- When I run the example in Figure 11.5 on a Mac OS X system, why do I get a segmentation fault?
In Mac OS X, pthread_cleanup_push is implemented as a macro that stores the thread cleanup handler address on the stack. If a thread returns from its start routine, the stack can get overwritten, so the data stored there is no longer valid. When the system tries to run the cleanup handler, you can get a segmentation violation or a bus error if the address is invalid. The Single UNIX Specification specifies that "an implicit call to pthread_exit() is made when a thread other than the thread in which main() was first invoked returns from the start routine that was used to create it." Thus an implementation might try to run thread cleanup handlers when a thread (other than main) returns from its start routine. However, the Single UNIX Specification also makes it clear that the use of a return to "prematurely leave a code block described by a pair of pthread_cleanup_push() and pthread_cleanup_pop() functions" is undefined. (This last bit was added in Technical Corrigendum No. 2.)
- In the example in Figure 16.9, why do successive attempts to connect fail when the first one fails?
The Single UNIX Specification states that if connect fails, then the state of the socket is undefined, and a conforming application must close the socket and open a new one before attempting to reconnect. This is described in UNIX Network Programming by Stevens, Fenner, and Rudoff (see http://www.unpbook.com). So why isn't this shown in Figure 16.9? The answer is that this behavior is specific only to the TCP protocol, and as such, shouldn't be visible in the socket interface. In the ideal view, the socket interface is protocol-independent. The reality, however, is that the interface was designed specifically to support two protocols: TCP and UDP, and this is just one case where the details of the underlying protocol poke through the interface to cause programmers grief. Under the covers, what happens is that the client end of the TCP connection send a SYN segment to the destination. If the destination doesn't have any process willing to accept connections on that port, it responds with an RST segment. When the client receives the RST, it places the socket in an error state and renders it useless. So the bottom line is that with TCP, the example in Figure 16.9 probably won't have the intended effect. I consider this a bug in the sockets implementation.
- Why doesn't some of the sample code build on Mac OS X, version 10.4?
In Mac OS X, the <sys/socket.h> header file changed between version 10.3 and version 10.4. In version 10.4, the CMSG_LEN macro is protected by an #ifndef _POSIX_C_SOURCE test, which means that CMSG_LEN is undefined if _POSIX_C_SOURCE is defined. This will prevent the linker from being able to create the executables that contain references to CMSG_LEN, as this is now an undefined symbol. The easiest solution is to add the definition for CMSG_LEN to apue.h.
- When I run the example in Figure 11.2 on a Linux 2.6 system, why are the process IDs the same?
Linux 2.6-based systems use a different thread implementation than do earlier versions. (There is a nice article about the new threads implementation in the August 2005 issue of Dr. Dobb's Journal -- just go to http://www.ddj.com and search for NPTL.) In short, the threads implementation on Linux 2.6-based systems behaves more like the threads on other Unix systems, including the example ones used in APUE2e. Thus, many of the exceptions noted in the book about the Linux system used to test the examples are no longer true with Linux 2.6. In particular, the areas of thread identification and thread signal handling are much improved over Linux 2.4. Note that while some vendors might choose to offer a port of Linux 2.4 that includes the new threads implementation, most vendors have simply moved to Linux 2.6.