Add diclaimer of copyright to _osname() manual page.
[unix-history] / usr.bin / ar / ar.5.5
CommitLineData
15637ed4
RG
1.\" Copyright (c) 1990, 1991 The Regents of the University of California.
2.\" All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\" notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\" notice, this list of conditions and the following disclaimer in the
11.\" documentation and/or other materials provided with the distribution.
12.\" 3. All advertising materials mentioning features or use of this software
13.\" must display the following acknowledgement:
14.\" This product includes software developed by the University of
15.\" California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\" may be used to endorse or promote products derived from this software
18.\" without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\" @(#)ar.5.5 6.3 (Berkeley) 5/10/91
33.\"
34.Dd May 10, 1991
35.Dt AR 5
36.Os
37.Sh NAME
38.Nm ar
39.Nd archive (library) file format
40.Sh SYNOPSIS
41.Fd #include <ar.h>
42.Sh DESCRIPTION
43The archive command
44.Nm ar
45combines several files into one.
46Archives are mainly used as libraries of object files intended to be
47loaded using the link-editor
48.Xr ld 1 .
49.Pp
50A file created with
51.Nm ar
52begins with the ``magic'' string "!<arch>\en".
53The rest of the archive is made up of objects, each of which is composed
54of a header for a file, a possible file name, and the file contents.
55The header is portable between machine architectures, and, if the file
56contents are printable, the archive is itself printable.
57.Pp
58The header is made up of six variable length
59.Tn ASCII
60fields, followed by a
61two character trailer.
62The fields are the object name (16 characters), the file last modification
63time (12 characters), the user and group id's (each 6 characters), the file
64mode (8 characters) and the file size (10 characters).
65All numeric fields are in decimal, except for the file mode which is in
66octal.
67.Pp
68The modification time is the file
69.Fa st_mtime
70field, i.e.,
71.Dv CUT
72seconds since
73the epoch.
74The user and group id's are the file
75.Fa st_uid
76and
77.Fa st_gid
78fields.
79The file mode is the file
80.Fa st_mode
81field.
82The file size is the file
83.Fa st_size
84field.
85The two-byte trailer is the string "\`\en".
86.Pp
87Only the name field has any provision for overflow.
88If any file name is more than 16 characters in length or contains an
89embedded space, the string "#1/" followed by the
90.Tn ASCII
91length of the
92name is written in the name field.
93The file size (stored in the archive header) is incremented by the length
94of the name.
95The name is then written immediately following the archive header.
96.Pp
97Any unused characters in any of these fields are written as space
98characters.
99If any fields are their particular maximum number of characters in
100length, there will be no separation between the fields.
101.Pp
102Objects in the archive are always an even number of bytes long; files
103which are an odd number of bytes long are padded with a newline (``\en'')
104character, although the size in the header does not reflect this.
105.Sh SEE ALSO
106.Xr ar 1 ,
107.Xr stat 2
108.Sh HISTORY
109There have been at least four
110.Nm ar
111formats.
112The first was denoted by the leading ``magic'' number 0177555 (stored as
113type int).
114These archives were almost certainly created on a 16-bit machine, and
115contain headers made up of five fields.
116The fields are the object name (8 characters), the file last modification
117time (type long), the user id (type char), the file mode (type char) and
118the file size (type unsigned int).
119Files were padded to an even number of bytes.
120.Pp
121The second was denoted by the leading ``magic'' number 0177545 (stored as
122type int).
123These archives may have been created on either 16 or 32-bit machines, and
124contain headers made up of six fields.
125The fields are the object name (14 characters), the file last modification
126time (type long), the user and group id's (each type char), the file mode
127(type int) and the file size (type long).
128Files were padded to an even number of bytes.
129For more information on converting from this format see
130.Xr arcv 8 .
131.Pp
132The current archive format (without support for long character names and
133names with embedded spaces) was introduced in
134.Bx 4.0 .
135The headers were the same as the current format, with the exception that
136names longer than 16 characters were truncated, and names with embedded
137spaces (and often trailing spaces) were not supported.
138It has been extended for these reasons,
139as described above.
140This format is
141.Ud .
142.Sh COMPATIBILITY
143No archive format is currently specified by any standard.
144.At V
145has historically distributed archives in a different format from
146all of the above.