The <ast_foo.h> headers are helpers for the public ast headers and should not be explicitly included. The one exception is <ast_std.h> which may be explicitly included.

We do have thread-safe versions of sfio and malloc, but these have not been merged into libast yet. The issue now is minimizing space/time penalties for non-threaded applications. Right now the bulk of our applications are non-threaded, but that might be a self-fulfilling consequence.

No. ksh(1) is a standalone executable, so you can run it from any environment. Other commands in a package, however, may be linked with shared or dynamic libraries, and these may require environment incantations to run. ksh(1) compensates by referring to the file .paths in each directory on $PATH. This file may contain definitions for FPATH and LD_LIBRARY_PATH (or the local equivalent.) An FPATH=directory definition causes the specified directory to be search for function definitions. The default value is FPATH=../fun. An LD_LIBRARY_PATH=directory (or its local equivalent) definition causes the specified directory to be prepended on LD_LIBRARY_PATH for any command executed from the directory containing the .paths file. $INSTALLROOT/bin/.paths is automatically initialized when source and binary packages are installed.

The upshot is that if you export $INSTALLROOT/bin anywhere in PATH and run $INSTALLROOT/bin/ksh then any other commands in $INSTALLROOT/bin dynamically linked with shared or dynamic libraries in $INSTALLROOT/lib will find their libraries with no other environment incantations. In addition, all of the files under $INSTALLROOT/bin and $INSTALLROOT/lib are position independent: no other changes are required as long as you copy both directory trees as a unit. And yes, this eliminates the need for package use.

Some tests are susceptible to locale and basic C type size differences and these may cause some failures. Check the test errors link for a list of known test failures by architecture.

probe(1) generates tool-specific compiler information, which can be a relatively expensive operation. probe can operate setuid or not. If it is setuid (to the owner of the $INSTALLROOT/lib/probe tree, not root) then the generated information is shared by all users in $INSTALLROOT/lib/probe. If it is not setuid then the information is generated per-user in the bindir/../lib/probe tree, where bindir must appear in $PATH before $INSTALLROOT/bin, or in the $HOME/.probe directory as a last resort. As an alternative you can manually generate the probe information for each compiler and install the output in a writable file named by probe -k language tool processor. See probe --?override for details.

Running setuid triggers a security feature of runtime linkers that searches for shared libraries in a restricted set of directories, typically /usr/local/lib, /usr/lib and /lib. A symbolic link to the fully qualified libast shared library path (including version numbers) from one of the restricted directories should do the trick.

These commands are implemented as DLLs (aka dynamically linked libraries, shared libraries, dynamic shared objects) that change the semantics of system calls. This is done by intercepting the calls before calling the real (non-intercepted) calls. For this to work the intercept DLL must load before the local system call interface DLL (usually the C library) loads. This is a non-standard operation, but most modern UNIX variants provide an environment variable hook into the runtime dynamic linker. sun provided an early implementation using LD_PRELOAD; sgi followed with _RLD_LIST, _RLD32_LIST or _RLD64_LIST. Other vendors use one of these. 3d(1), ie(1) and warp(1) initialize both environment variables, but do no further checks.

Some of our research cuts across the section 1 commands. Much of the work involves library interfaces for common operations. UNIX commands have a tradition of independence, which for the most part has been a boon to programming. The downside, though, is that for any particular algorithm, chances are it is currently implemented n>1 possibly independent ways on your system. For example, find(1), ls(1) -R, diff(1) -R, and chmod(1) -r probably use separate, hand-coded mechanisms for descending a directory tree. We developed the fts(3) directory stream interface and then re-implemented all of the commands that traverse directory trees to use the interface. This provides consistent behavior across all commands and all host instantiations for those commands, including loop detection when symbolic links are traversed. In other cases we have re-implemented commands to use sfio(3), some with performance improvements of 2 to 5 times. In some cases a command re-implementation may be used as a harness for algorithm comparison. Our sort(1) and sum(1) are built on top of libraries that provide different methods (algorithms) that can be selected at runtime. See sort --?method and sum --?method for more details. As a final example, the command line option library interface optget(3) provides a consistent mechanism for parsing, error message generation, online help and documentation.

Some GNU contributors have taken GNU's Not UNIX to heart. Contemptuous GNU-isms, like POSIXLY_CORRECT and ls --dereference-command-line-symlink-to-dir won't see the light of day in ast. Its a good thing the core of UNIX was designed, implemented and adopted before GNU got on board (man 2 open_file_dereference_symlink_if_dir?) That said, we do appreciate gcc, gdb, --long-options, and open source initiatives fueled by GNU.

The software on this site spans the 80's, 90's and 00's. In the mid 80's we made a conscious decision to use C rather than C++ for portability reasons. The alternative library designs (e.g., discipline/method interface) have served us well enough that we have remained with C. However, the software is compatible with C++ (e.g., no true or false identifiers), and the library interface headers are passed through proto(1) to provide simultaneous compatibility with K&R C, ANSI C, and C++. As far as perl, we're keeping an alternative path alive.

Make sure there is a /bin/ksh entry in /etc/shells.

This seems misleading, but there is an explanation. There are some options common to all ast commands (via optget(3)) and these are not listed with the individual command documentation. You can list these global options by passing the --??? option to any ast command.

Well, because we are concerned with { UNIX POSIX X/Open } portability. If the underlying native system has a non-POSIX path syntax then it is the responsibility of the POSIX emulation layer { cygwin EMX UWIN } to handle the translation. POSIX emulation layers that force windowisms on POSIX applications abdicate their responsibility to emulate POSIX. See http://www.research.att.com/sw/download/win32/ for details on how ast software deals with POSIX/Windows emulation shortcomings. We do recognize emulation limitations: case-ignorant filesystem workarounds have crept into ast ksh(1) and nmake(1) code proper, but the remaining Windows workarounds are in the ast library, preserving the POSIX API for the rest of ast.