UnixWare standards conformance

UNIX95 conformance

The X/Open UNIX^®95 Brand (Single UNIX Specification) standard affects commands, utilities, system services, and the development system. This section summarizes the compatibility impacts of this standard, which is the default implementation for UnixWare 7.

The Single UNIX Specification encompasses five X/Open Common Applications Environment specifications:

System Interface Definitions, Issue 4, Version 2 (XBD)
System Interfaces and Headers, Issue 4, Version 2 (XSH)
Commands and Utilities, Issue 4, Version 2 (XCU)
Networking Services, Issue 4
X/Open Curses, Issue 4

NOTE: The development utilities in XCU are not required for the Single UNIX Specification brand. The utilities are supported by UnixWare, but they are not considered conformant to XCU.

For an overview of the Single UNIX Specification, and information about its history and business implications, browse The Open Group Web Site on the Internet.

UNIX95 Source code compatibility

UnixWare 7 includes many header file changes (relative to SCO UnixWare 2.1 and SCO OpenServer) to comply with the X/Open Single UNIX Specification. Many of these changes add new symbols and restrictions on the namespace. The symbols added for alignment to the specification are, by default, made visible when the header file is included.

Compilation errors may be encountered if symbols in the header files conflict with symbols already declared in your source code. Many of these conflicting identifiers are function declarations that did not exist before, or function declaration parameter types that were changed to conform with the Single UNIX Specification (for example, char * to void *). Below are some examples of the more common conflicts you may encounter during source recompilation.

The random function external declaration was added to stdlib.h. An error occurs if this function is already declared locally. Often it is sufficient to use the function declared in stdlib.h and remove the local declaration.
In some cases, new identifiers in a header file require the local declaration of the identifier and all references to it to be renamed.
The declaration for mmap(2) in /usr/include/sys/mman.h was changed from caddr_t to a void *. This may cause the following error if mmap is declared locally
```
   identifier redeclared: mmap.
```
The proposed resolution is to remove the local declaration of mmap.
The following fields of iovec_t in /usr/include/sys/uio.h are redefined:

old definition Single UNIX definition

caddr_t iov_base void *iov_base

int iov_len size_t iov_len

The change to iov_base causes failures when arithmetic operations are performed on it without casting it to a data type that can be used in arithmetic operation.
The member names of the internal FILE structure defined in stdio.h have changed to begin with a leading double underscore. Any application that directly references these members instead of using the standard I/O interfaces that are supplied in the Standard C Library result in a compilation error.
Two new header files formerly included only in the SCO UnixWare 2.1 BSD Compatibility package (bsdcompat) have been moved to /usr/include as part of the standard header file distribution. These files are:
```
   /usr/include/ndbm.h
   /usr/include/strings.h
```
(In SCO UnixWare 2.1 these header files were located only in /usr/ucbinclude.)
The putmsg(2) system call returns ENXIO when a hangup is generated downstream. This behavior is different from SCO UnixWare 2.1 and SCO OpenServer, where EIO was generated. EIO is only generated now if the file descriptor refers to a streams-based pipe, and the other end of the pipe is closed. This behavior is the same as the EPIPE error condition.

old definition	Single UNIX definition
`caddr_t iov_base`	`void *iov_base`
`int iov_len`	`size_t iov_len`

UNIX95 Commands and utilities

UnixWare 7 includes many command and utility changes (relative to SCO UnixWare 2.1 and SCO OpenServer) to comply with the X/Open Single UNIX Specification. This list summarizes the major changes.

--: Standard utilities that accept a list of operands use ``--'' (a double dash) to terminate the list, allowing portable applications to distinguish the operand list from any additional command line options a particular implementation may support. Examples of utilities using this delimiter are: basename(1), pack(1), unpack(1), nohup(1), od(1), pg(1), printf(1), spell(1), strings(1), xargs(1).
patch: The patch(1) utility now exits with exit status 1 if any rejections occur. The SCO UnixWare 2.1 version exited with the number of rejections.
strings: The strings(1) utility previously exited after encountering a file access error. Now, it continues processing the subsequent file(s) instead of exiting immediately.
xargs: Exit status values have changed from &uw21 The command exits with 127 if the utility on the command line could not be found, and with 126 if it could be found, but not executed. The SCO UnixWare 2.1 version exited with status 1 in both cases. See xargs(1).
rm: User input is required where none was needed before. Using -r to remove a write protected directory when stdin is a terminal and -f is not specified, you are prompted to confirm that the directory and its contents should be removed. Using -ri prompts twice before removing the directory, even if it is empty. See rm(1).
awk: The value of $0 within the END block has changed (see awk(1)). Instead of being empty, it now retains the value of the last input record. Previously, within an END block, print $0 would behave the same as a print statement by itself and print a blank line. Because $0 now contains the contents of the last input line within the END block, applications must use print "" instead of using a print statement by itself to print a blank line.
Also, the close function was changed to return a value indicating success or failure. An undocumented feature of the previous awk was that a call to close did not require parenthesis to be effective. Now, a close function without parenthesis silently has no effect because it is not a true function call. This can cause old awk scripts to run out of file descriptors.
sed: The way that the sed(1) l command displays non-printable characters was changed to match the POSIX.2 standards. Specifically, these characters are displayed using escape sequences like those in the ANSI C standard (\t for tab, and so on), falling back on three octal digits for others (for example, \001 for ASCII Ctrl-A).
crontab: The cron(1M) daemon must execute crontab(1) and at(1) jobs with the POSIX.2 shell. Since /usr/bin/sh is not the POSIX.2 shell, cron was changed to use a different shell for certain users. The user's shell from /etc/passwd is used provided that shell ends in the letters sh. Otherwise it uses the shell in /usr/bin/sh.
echo: The behavior of the ksh(1) builtin echo command conforms with the X/Open Command and Utilities Version 4 Issue 2 standard. Consequently, it does not recognize the -n option supported by older versions of the shell and the /bin/echo command that suppresses the newline character normally returned at the end of the echoed string. There are two ways to obtain the old behavior: explicitly invoke the command /bin/echo; or, type builtin -d echo to dynamically remove the echo builtin command (causing /bin/echo to be used, instead).
find: The behavior of the find(1) command was changed to conform with the X/Open Command and Utilities Version 4 Issue 2 standard. The /bin/find command now returns exit code ``18'' when the directory or file in the search path does not exist. Previously, exit code ``0'' was returned.

UNIX95 Sockets

The default action on both SCO UnixWare 2.1.X and UnixWare 7 is UNIX95 sockets behavior; this essentially translates to linking with /usr/lib/libsocket.so.2. The following list describes the major differences between UnixWare 7 and SCO UnixWare 2.1.X sockets (/usr/lib/libsocket.so.1, provided for compatibility only). See the X/Open System Interface Definition, Issue 4 Version 2 for more detail.

Also see ``Sockets interface'' for a review of the differences between UnixWare 7 and SCO OpenServer sockets.

Error handling: A number of new errors have been added and some existing error checks have been rearranged. In some cases, different errno values than the ones used by the UnixWare library are set by the POSIX.2 library for the same condition.
Socket options: The Transport Provider interface has been changed to allow setting options in the TS_UNBND and TS_DATA_XFER states (previously, this was allowed only in the TS_IDLE state).
Address length: The computation of address lengths for UNIX domain sockets was changed to yield the actual length of path names, not the maximum length.
Nonblocking sockets: Connection attempts on nonblocking UNIX domain sockets continue to set errno to EINPROGRESS, but now they also go on to complete the connection.
MSG_WAITALL flag: The new MSG_WAITALL flag is supported in the receive functions (recv, recvfrom, and recvmsg). These calls now block until the receive buffer is full.
System calls: The following system calls now go through the POSIX.2 sockets library so that behavior specific to sockets can be provided: close(2), fstat(2), lseek(2), read(2), readv(2), write(2), and writev(2).

UNIX95/UNIX98 curses

UnixWare provides the X/Open curses library in libcurses.a. This library is compliant with The Single UNIX Specification, Version 2.

See ``curses (libocurses) interface'' and Intro(3curses) for more details.

ksh-93 vs. ksh-88

The Single UNIX Specification requires that a user's login shell must be a POSIX.2 compliant shell, and that it must be accessed as sh. The POSIX.2 compliant shell used is the 1993 version of the Korn shell (ksh-93 Version D) with SCO enhancements.

ksh-93 provides many new and expanded capabilities including improvements for associative arrays, floating point arithmetic, internationalized messages, command and file completion, pattern matching and new builtins and reference variables. See The New KornShell Command and Programming Language, by Morris I. Bolsky and David G. Korn, Prentice Hall PTR, 1995, for information about ksh-93.

You can still use the older version of the Korn shell included with SCO UnixWare 2.1.X and SCO OpenServer. It is included on UnixWare 7 in the file /usr/bin/ksh88.

Both of these shells have their own manual pages; see ksh(1) and ksh88(1).

There are some minor incompatibilities between ksh-93 (the standard UnixWare 7 Korn shell, found in /usr/bin/ksh) and the version of the Korn shell that is standard on SCO UnixWare 2.1.X and SCO OpenServer (known as ksh-88 and found on UnixWare 7 in /usr/bin/ksh88). These incompatibilities are documented in this section. Cases that are clearly bugs in ksh-88, and features that are completely upward compatible, are not included.

Functions, defined with the name command in ksh-93 are compatible with the POSIX standard, not with ksh-88. No local variables are permitted, and there is no separate scope. Functions defined with the function command syntax maintain compatibility with ksh-88. Function traces are also affected.
The exclamation point character (!) is now a reserved word. As a result, any command by that name no longer works with ksh-93.
The -x attribute of alias and typeset -f is no longer effective, and the ENV file is only read for interactive shells. You need to use FPATH to make function definitions visible to scripts.
A built-in command (named command) has been added that is always found before the PATH search. Any script which uses this name as the name of a command (or function) is not compatible with ksh-93.
The output format for some built-ins has changed: set, typeset and alias now have single quotes around values that have special characters. The output for trap, without arguments, has a format that can be used as input.
In ksh-88, a dollar sign followed by a single quote ($') was interpreted literally. Now it is an ANSI-C string. You must quote the dollar sign to get the previous behavior. Also, a $ in front of a double-quote ($") indicates that the string needs to be translated for locales other than C or POSIX. The $ is ignored in the C and POSIX locale.
With ksh-88, tilde expansion did not take place inside parameter substitutions. With ksh-93
```
   ${foo-~}
```
causes tilde expansion if foo is not set. You need to escape the tilde (\~) for the previous behavior.
Some changes in the tokenizing rules were made that might cause some scripts with previously ambiguous use of quoting to produce syntax errors.
Programs that rely on specific exit values for the shell (rather than 0 or non-zero) may not be compatible. The exit status for many shell failures has been changed.
Built-ins in ksh-88 were always executed before looking for the command in the PATH variable; this is not true in ksh-93. With ksh-93, if you have the current directory first in your PATH, and you have a program named test in your directory, it is executed when you enter test at the command line; the built-in version is run at the point /bin is found in your PATH.
Some undocumented combinations of argument passing to builtin commands in ksh-88 no longer work because ksh-93 conforms to the getopts(1) standard with respect to its built-ins. For example,
```
   typeset -8I
```
in ksh-88 would work as a synonym for
```
   typeset -i8
```
Command substitution and arithmetic expansion are now performed on PS1, PS3, and ENV when they are expanded. Thus, \` and $( as part of the value of these variables must be preceded by a backslash (\) to preserve their ksh-88 behavior.
The ERRNO variable is not supported in ksh-93.
If the file name following a redirection symbol contains pattern characters they are only expanded for interactive shells, not for scripts.
The arguments to a dot script are restored when it completes.
The list of tracked aliases is not displayed by the alias builtin unless the -t option is specified.
The POSIX standard requires that
```
   test "$arg"
```
have an exit status of 0, if and only if $arg is null. However, since this breaks programs that use the -toption of the test command, ksh-93 treats the following two commands as equivalent:
```
   test -t
   test -t 1
```
The ^T directive of emacs mode has been changed to work the way it does in gnu-emacs.
ksh-88 allowed unbalanced parentheses within
```
   ${name op val}
```
whereas ksh-93 does not. Thus:
```
   ${foo-(}
```
needs to be typed:
```
   ${foo-\(}
```
The second command works the same in both ksh-93 and ksh-88.
The kill -l command in ksh-93 lists only the signal names, not their numerical values.
Local variables defined by typeset are statically scoped in ksh-93. In ksh-88 they were dynamically scoped, although this behavior was never documented.
To conform to the POSIX standard, the value of the variable given to getopts is set to ? when the end of options is reached.
The behavior of the builtin echo command conforms with the X/Open Command and Utilities Version 4 Issue 2 standard. Consequently, it does not recognize the -n option supported by older versions of the shell and the /bin/echo command that suppresses the newline character normally returned at the end of the echoed string. There are two ways to obtain the old behavior: explicitly invoke the command /bin/echo; or, type builtin -d echo to dynamically remove the echo builtin command (causing /bin/echo to be used, instead).

UNIX95 compliant compilation environment

To use the Single UNIX Specification namespace of identifiers and prototypes in header files, the _XOPEN_SOURCE macro must be defined in each source file prior to including any header file. This exposes those definitions aligned with POSIX.1 and POSIX.2. In addition, the statement

   #define _XOPEN_SOURCE_EXTENDED 1

must appear prior to inclusion of any headers.

Use the c89(1) interface to the standard C compilation system. This utility allows you to take advantage of the standard API and the X/Open curses and POSIX-2 socket libraries.

Enabling and disabling the UNIX95 user environment

Although the UNIX95 ksh is the default shell, strict UNIX95 compliance for the user execution environment is not enabled by default.

The simplest way to do this is with the suscfg(1M) command (found in /u95/bin); you must be logged in as root to use this command. The following are examples of how to use this command.

To check to see if the UNIX95 user environment conformance is currently enabled or disabled, enter:

   # /u95/bin/suscfg -n
   Single UNIX Specification not configured.
   #

To enable UNIX95 user environment conformance, enter:

# /u95/bin/suscfg -e UX:idbuild: INFO: The unix kernel will be rebuilt now. This will take some time. Please wait.

UX:idbuild: INFO: The unix kernel has been rebuilt. A system reboot is required to complete setup or removal of the Single UNIX Specification configuration. #

To disable UNIX95 conformance, enter:

# /u95/bin/suscfg -d UX:idbuild: INFO: The unix kernel will be rebuilt now. This will take some time. Please wait.

UX:idbuild: INFO: The unix kernel has been rebuilt. A system reboot is required to complete setup or removal of the Single UNIX Specification configuration. #

NOTE: Enabling and disabling UNIX95 with suscfg reconfigures the system kernel. A system reboot is needed after using either of these commands to complete the transition to the new system configuration.

Enabling and disabling UNIX95 conformance for existing users

In addition to using suscfg(1M) to enable system-level UNIX95 conformance and conformance for newly added users, /u95/bin/sh must be made the default shell for all existing users who want to have a UNIX95-compliant execution environment. (/u95/bin/sh is a link to /usr/bin/ksh, which is ksh-93.)

This is done with the command:

   usermod -s /u95/bin/sh login

where login is the login of the existing user

Since /u95/bin/sh is a link to /usr/bin/ksh, there's no need to change the login shell should you disable UNIX95 conformance with suscfg -d, unless those users do not want ksh-93 as their login shell. If required, you can do this with a command like the following:

   usermod -s /usr/bin/sh login

which sets the login shell for login to the System V Bourne shell.

Tasks performed by suscfg(1M)

The following tasks are performed by the suscfg(1M) command to enable or disable Single UNIX Specification compliance:

The RSTCHOWN kernel tunable is set to 1 to enable UNIX95, or to 0 to disable. (POSIX specifies two types of chown behavior and UnixWare supports both types; but turning on RSTCHOWN satisfies additional FIPS and XPG standards that mandate that a user cannot give ownership of files away.)
The suscfg script does this with the following two commands:
```
   /etc/conf/bin/idtune -g RSTCHOWN 2>/dev/null | /usr/bin/cut -f1 > /u95/bin/rstchown.orig
   /etc/conf/bin/idtune -f RSTCHOWN 1 > /dev/null 2>&1
```
To reset RSTCHOWN to its previous value, suscfg uses these commands:
```
   val="`/usr/bin/cat /u95/bin/rstchown.orig`"
   /etc/conf/bin/idtune -f RSTCHOWN "$val" 1>/dev/null 2>&1
   /usr/bin/rm /u95/bin/rstchown.orig
```
Similarly, the script sets the PROCSET_ZOMBIES tunable to 1 to enable UNIX95, or to 0 to disable.
To comply with UNIX95, the system default login shell for new users is changed so that new users added to the system are Single UNIX Specification compliant; this is done with the command:
```
   defadm useradd SHELL=/u95/bin/sh
```
To disable UNIX95, suscfg uses:
```
   defadm useradd SHELL=/usr/bin/sh
```
making sh(1) the default login shell for new users.
The file /etc/profile (executed as part of the login sequence for all users) must be changed so that the environment variable POSIX2 is set to on and /u95/bin is prepended to the PATH environment variable for all users whose login shell (the shell listed in /etc/passwd) is /u95/bin/sh. The following code is added to or removed from /etc/profile to enable or disable (respectively) UNIX95 conformance:
```
   if [ "$SHELL" = "/u95/bin/sh" ]
   then
   	PATH=/u95/bin:/usr/bin:/usr/sbin:$PATH
           POSIX2=on
           export PATH POSIX2
   fi
```
Note that this also has the effect of setting the CS_PATH variable, used with the getconf(1) command.