NAME

pax - portable archive interchange

SYNOPSIS

pax [-cdnvK] [-b size] [-f file] [-s replstr] [-x hdr] [patterns]

pax -r[cdiknuvK] [-b size] [-f file] [-o options] [-p priv] [-s replstr] [-x hdr] [patterns]

pax -w[adiHtuvLX] [-b size] [-f file] [-o options] [-s replstr] [-x hdr] [files]

pax -rw[diHklntuvLX] [-p priv] [-s replstr] [files] directory

DESCRIPTION

Pax creates and extracts file archives and copies files.

If neither the -r or -w options are given, pax works in list mode and prints the contents of the archive.

With the -r option, pax works in `read' mode and extracts files from a file archive. By default, the archive is read from standard input. Optional arguments are interpreted as patterns and restrict the set of extracted files to those matching any of the patterns. The syntax is identical to that described in glob(7), except that the slash character `/' is matched by meta-character constructs with `*', `?' and `['. Care must be taken to quote meta-characters appropriately from the shell. If a pattern matches the prefix name of a directory in the archive, all files below that directory are also extracted. File permissions are set to those in the archive; if the caller is the super-user, ownerships are restored as well. options are specified. Archives compressed with bzip2(1), compress(1), gzip(1), or rpm(1) are transparently decompressed on input.

With -w, pax works in `write' mode, creates archives and writes them to standard output per default. A list of filenames to be included in the archive is read from standard input; if the name of a directory appears, all its members and the directory itself are recursively included in the archive. The find(1) utility is useful to generate a list of files (see also its -cpio and -ncpio operators). When producing a filename list for pax, find should always be invoked with -depth since this makes it possible to extract write-protected directories for users other than the super-user. If files are given on the command line, they are included in the archive in the same manner as described above and standard input is not read.

The -rw options selects `copy' mode; a list of files is read from standard input or taken from the command line as described for -w; files are copied to the specified directory, preserving attributes as described for -r. Special files are re-created in the target hierarchy, and hard links between copied files are preserved.

When a premature end-of-file is detected with -r and -w and the archive is a block or character special file, the user is prompted for new media.

The following options alter the behavior of pax:

-a

Append files to the archive. The archive must be seekable, such as a regular file or a block device, or a tape device capable of writing between filemarks.

-b size[w|b|k|m]

Blocks input and output archives at size byte records. The optional suffix multiplies size by 2 for w, 512 for b, 1024 for k, and 1048576 for m.

-c

Reverses the sense of patterns such that a file that does not match any of the patterns is selected.

-d

Causes pax to ignore files below directories. In read mode, patterns matching directories cause only the directory itself to extracted, files below will be ignored unless another pattern applies to them. In write mode, arguments or standard input lines referring to directories do not cause files below the respective directory to be archived.

-f file

Selects a file that is read with the -r option instead of standard input or written with the -w option instead of standard output.

-H

Follow symbolic links given on the command line when reading files with -w or -rw, but do not follow symbolic links encountered during directory traversal.

-i

Rename files interactively. Before a file is extracted from the archive, its file name is printed on standard error and the user is prompted to specify a substitute file name. If the line read from the terminal is empty, the file is skipped; if the line consists of a single dot, the name is retained; otherwise, the line forms the new file name.

-k

Causes existing files not to be overwritten.

-K

Try to continue operation on read errors and invalid headers. If an archive contains another archive, files from either archive may be chosen.

-l

Link files instead of copying them with -rw if possible.

-L

Follow symbolic links when reading files with -w or -rw. /usr/posix2001/bin/pax terminates immediately when it detects a symbolic link loop with this option.

-n

If any pattern arguments are present, each pattern can match exactly one archive member; further members that could match the particular pattern are ignored. Without pattern arguments, only the first occurence of a file that occurs more than once in the archive is selected, the following are ignored.

-o option,[option,...]

Specifies options as described for -x pax.

-p string

Specifies which file modes are to be preserved or ignored. string may contain one or more of

If file ownership is preserved, pax tries to set the group ownerships to those specified in the archive or the original hierarchy, respectively, regardless of the privilegues of the invoking user. /usr/5bin/pax, /usr/5bin/s42/pax, and /usr/5bin/posix/pax try to set the user ownerships only if invoked by the super-user; if invoked by regular users, /usr/5bin/posix2001/pax will produce an error for any file that is not owned by the invoking user.

-s /regular expression/replacement/[gp]

Modifies file names in a manner similar to that described in ed(1). The p flag causes each modified file name to printed. Any character can be used as delimiter instead of `/'. If a file name is empty after the replacement is done, the file is ignored.

-t

Resets the access times of files that were included in the archive with -r.

-u

In read mode, pax will not overwrite existing target files that were modified more recently than the file in the archive when this option is given. In write mode, pax will read the archive first. It will then only append those files to the archive that are not already included or were more recently modified.

-v

Prints the file names of archived or extracted files with -r and -w and a verbose output format if neither of them is given.

-x header

Specifies the archive header format to be one of:

newc	SVR4 ASCII cpio format;
crc	SVR4 ASCII cpio format with checksum;
sco	SCO UnixWare 7.1 ASCII cpio format;
scocrc	SCO UnixWare 7.1 ASCII cpio format with checksum;
odc	traditional ASCII cpio format, as standardized in IEEE Std. 1003.1, 1996;
cpio	same as odc;
bin	binary cpio format;
bbs	byte-swapped binary cpio format;
sgi	SGI IRIX extended binary cpio format;
cray	Cray UNICOS 9 cpio format;
cray5	Cray UNICOS 5 cpio format;
dec	Digital UNIX extended cpio format;
tar	tar format;
otar	old tar format;
ustar	IEEE Std. 1003.1, 1996 tar format;
pax[:option,[option,...]]
	IEEE Std. 1003.1, 2001 pax format. Format-specific options are: +2n linkdata For a regular file which has multiple hard links, the file data is stored once for each link in the archive, instead of being stored for the first entry only. This option must be used with care since many implementations are unable to read the resulting archive. times Causes the times of last access and last modification of each archived file to be stored in an extended pax header. This in particular allows the time of last access to be restored when the archive is read. -2n

sun	Sun Solaris 7 extended tar format;
bar	SunOS 4 bar format;
gnu	GNU tar format;
zip[:cc]	zip format with optional compression method. If cc is one of en (normal, default), ex (extra), ef (fast), or es (super fast), the standard deflate compression is used. e0 selects no compression, and bz2 selects bzip2 compression.

This option is ignored with -r unless the -K option is also present. The default for -w is traditional ASCII cpio (odc) format.

Characteristics of archive formats are as follows:

The byte order of binary cpio archives depends on the machine on which the archive is created. Unlike some other implementations, pax fully supports archives of either byte order. -x bbs can be used to create an archive with the byte order opposed to that of the current machine.

The sgi format extends the binary format to handle larger files and more device bits. If an archive does not contain any entries that actually need the extensions, it is identical to a binary archive. -x sgi archives are always created in MSB order.

The odc format was introduced with System III and standardized with IEEE Std. 1003.1. All known cpio and pax implementations since around 1980 can read this format.

The dec format extends the odc format to support more device bits. Archives in this format are generally incompatible with odc archives and need special implementation support to be read.

The -x newc format was introduced with System V Release 4. Except for the file size, it imposes no practical limitations on files archived. The original SVR4 implementation stores the contents of hard linked files only once and with the last archived link. This pax ensures compatibility with SVR4. With archives created by implementations that employ other methods for storing hard linked files, each file is extracted as a single link, and some of these files may be empty. Implementations that expect methods other than the original SVR4 one may extract no data for hard linked files at all.

The crc format is essentially the same as the -x newc format but adds a simple checksum (not a CRC, despite its name) for the data of regular files. The checksum requires the implementation to read each file twice, which can considerably increase running time and system overhead. As not all implementations claiming to support this format handle the checksum correctly, it is of limited use.

The sco and scocrc formats are variants of the -x newc and -x crc formats, respectively, with extensions to support larger files. The extensions result in a different archive format only if files larger than slightly below 2 GB occur.

The cray format extends all header fields to 64 bits. It thus imposes no practical limitations of any kind on archived files, but requires special implementation support to be read. Although it is originally a binary format, the byte order is always MSB as on Cray machines. The cray5 format is an older variant that was used with UNICOS 5 and earlier.

The otar format was introduced with the Unix 7th Edition tar utility. Archives in this format can be read on all Unix systems since about 1980. It can only hold regular files (and, on more recent systems, symbolic links). For file names that contain characters with the most significant bit set (non-ASCII characters), implementations differ in the interpretation of the header checksum.

The ustar format was introduced with IEEE Std. 1003.1. It extends the old tar format with support for directories, device files, and longer file names. Pathnames of single-linked files can consist of up to 256 characters, dependent on the position of slashes. Files with multiple links can only be archived if the first link encountered is no longer than 100 characters. Due to implementation errors, file names longer than 99 characters can not considered to be generally portable. Another addition of the ustar format are fields for the symbolic user and group IDs. These fields are created by pax, but ignored when reading such archives.

With -x tar, a variant of the ustar format is selected which stores file type bits in the mode field to work around common implementation problems. These bits are ignored by pax when reading archives.

The pax format is an extension to the ustar format. If attributes cannot be archived with ustar, an extended header is written. Unless the size of an entry is greater than 8 GB, a pax archive should be readable by any implementation capable of reading ustar archives, although files may be extracted under wrong names and extended headers may be extracted as separate files. If a file name contains non-UTF-8 characters, it may not be archived or extracted correctly because of a problem of the pax format specification.

The sun format extends the ustar format similar as the pax format does. The extended headers in sun format archives are not understood by implementations that support only the pax format and vice-versa. The sun format has also problems with non-UTF-8 characters in file names.

The GNU tar format is mostly compatible with the other tar formats, unless an archive entry actually uses its extended features. There are no practical limitations on files archived with this format. The implementation of pax is limited to expanded numerical fields and long file names; in particular, there is no support for sparse files or incremental backups. If pax creates a multi-volume GNU archive, it just splits a single-volume archive in multiple parts, as with the other formats; GNU multi-volume archives are not supported.

The bar format is similar to the tar format, but can store longer file names. It requires special implementation support to be read.

The zip format can be read in many non-Unix environments. There are several restrictions on archives intended for data exchange: only regular files should be stored; file times, permissions and ownerships might be ignored by other implementations; there should be no more than 65536 files in the archive; the total archive size should not exceed 2 GB; only deflate compression should be used. Otherwise, pax stores all information available with other archive formats in extended zip file headers, so if archive portability is of no concern, the zip implementation in pax can archive complete Unix file hierarchies. Pax supports the zip64 format extension for large files; it automatically writes zip64 entries if necessary. Pax can extract all known zip format compression codes. It does not support zip encryption. Multi-volume zip archives are created as splitted single-volume archives, as with the other formats written by pax; generic multi-volume zip archives are not supported.

EXAMPLES

Extract all files named Makefile or makefile from the archive stored on /dev/rmt/c0s0, overwriting recent files:

List the files contained in a software distribution archive:

Write a gzip(1) compressed ustar archive containing all files below the directory project to the file project.tar.gz, excluding all directories named CVS or SCCS and their contents:

Copy the directory work and its contents to the directory savedfiles, preserving all file attributes:

Self-extracting zip archives are not automatically recognized, but can normally be read using the -K option, as with

ENVIRONMENT VARIABLES

LANG, LC_ALL

See locale(7).

LC_CTYPE

Selects the mapping of bytes to characters used for matching patterns and regular expressions.

LC_TIME

Sets the month names printed in list mode.

SEE ALSO

cpio(1), find(1), tar(1)

DIAGNOSTICS

Pax exits with

NOTES

Device and inode numbers are used for hard link recognition with the various cpio formats. Since the header space cannot hold large numbers present in current file systems, devices and inode numbers are set on a per-archive basis. This enables hard link recognition with all cpio formats, but the link connection to files appended with -a is not preserved.

If a numeric user or group id does not fit within the size of the header field in the selected format, files are stored with the user id (or group id, respectively) set to 60001.

Use of the -a option with a zip format archive may cause data loss if the archive was not previously created by cpio or pax itself.

If the file names passed to pax -w begin with a slash character, absolute path names are stored in the archive and will be extracted to these path names later regardless of the current working directory. This is normally not advisable, and relative path names should be passed to pax only. The -s option can be used to substitute relative for absolute path names and vice-versa.

Pax does not currently accept the -o delete, -o exthdr.name, -o globexthdr.name, -o invalid, -o listopt, and -o keyword options from POSIX.1-2001.