system call is unmount not umount
[unix-history] / usr / src / lib / libc / gen / fts.3
CommitLineData
c4e1185d
KB
1.\" Copyright (c) 1989 The Regents of the University of California.
2.\" All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms are permitted
5.\" provided that the above copyright notice and this paragraph are
6.\" duplicated in all such forms and that any documentation,
7.\" advertising materials, and other materials related to such
8.\" distribution and use acknowledge that the software was developed
9.\" by the University of California, Berkeley. The name of the
10.\" University may not be used to endorse or promote products derived
11.\" from this software without specific prior written permission.
12.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
13.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
14.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
15.\"
16.\" @(#)fts.3 5.1 (Berkeley) %G%
17.\"
18.TH FTS 3 ""
19.UC 7
20.SH NAME
21fts \- traverse a file hierarchy
22.SH SYNOPSIS
23.nf
24.ft B
25#include <sys/types.h>
26#include <sys/stat.h>
27#include <fts.h>
28
29FTS *
30ftsopen(path, options, compar)
31char *path;
32int options, (*compar)();
33
34FTS *
35ftsopen(path_argv, options | FTS_MULTIPLE, compar)
36char *path_argv[];
37int options, (*compar)();
38
39FTSENT *
40ftsread(ftsp);
41FTS *ftsp;
42
43FTSENT *
44ftschildren(ftsp)
45FTS *ftsp;
46
47ftsset(ftsp, f, options)
48FTS *ftsp;
49FTSENT *f;
50int options;
51
52ftsclose(ftsp)
53FTS *ftsp;
54.ft R
55.fi
56.SH DESCRIPTION
57The
58.IR fts (3)
59utilities are provided for traversing UNIX file hierarchies.
60Two structures are defined (and typedef'd) in the include file <\fIfts.h\fP>.
61The first is FTS, the structure that defines the file hierarchy stream.
62The second is FTSENT, the structure that defines a file in the file
63hierarchy.
64.PP
65The
66.I ftsopen
67routine returns a pointer to a file hierarchy rooted at
68.IR path .
69The
70.I options
71specified are formed by
72.IR or 'ing
73one or more of the following values:
74.TP
75FTS_LOGICAL
76This option causes
77.I ftsread
78to use the function
79.IR stat (2),
80by default, to determine the status of each file.
81If this option is set, the only symbolic links returned to the application
82are those referencing non-existent files.
83Either FTS_LOGICAL or FTS_PHYSICAL
84.B must
85be provided to the
86.I ftsopen
87routine.
88.TP
89FTS_MULTIPLE
90.I Ftsopen
91takes a single file name as a path argument by default.
92If the FTS_MULTIPLE option is specified, the path argument is a pointer
93to an array of character pointers (``argv'') to the paths to be traversed.
94The array must be terminated by a pointer to a NULL string.
95In this case the ``logical'' hierarchy is traversed, i.e. it's as if
96there's a virtual directory that contains the list of paths supplied,
97and the hierarchy is rooted in that directory.
98.TP
99FTS_NOCHDIR
100As a performance optimization,
101.I ftsread
102changes directories as it descends the hierarchy.
103This has the side-effect that applications cannot rely on being
104in any particular directory.
105The FTS_NOCHDIR option turns off this optimization.
106Note that applications should not change the current directory
107(even if FTS_NOCHDIR is specified) unless absolute pathnames were
108provided as arguments to
109.IR ftsopen .
110.TP
111FTS_NOSTAT
112By default,
113.I ftsread
114and
115.I ftschildren
116provide file characteristic information (the
117.I statb
118field) for each file they return.
119This option relaxes that requirement; the contents of the
120.I statb
121field may be undefined, and the
122.I info
123field may be set to FTS_NS.
124.TP
125FTS_PHYSICAL
126This option causes
127.I ftsread
128to use the function
129.IR lstat (2),
130by default, to determine the status of each file.
131If this option is set, all symbolic links are returned to the application
132program.
133Either FTS_LOGICAL or FTS_PHYSICAL
134.B must
135be provided to the
136.I ftsopen
137routine.
138.TP
139FTS_SEEDOT
140This option causes the routine
141.I ftsread
142to return structures for the directory entries ``.'' and ``..''.
143By default they are ignored unless specified as an argument to
144.IR ftsopen .
145.PP
146The argument
147.I compar
148specifies a user-defined routine which is used to order the traversal
149of directories.
150.I Compar
151takes two pointers to pointers to FTSENT structures as arguments and
152should return a negative value, zero, or a positive value to indicate
153if the file referenced by its first argument comes before, in any order
154with respect to, or after, the file referenced by its second argument.
155Note, the
156.I accpath
157and
158.I path
159fields of the FTSENT structures may not be used in this comparison.
160.PP
161If both FTS_MULTIPLE and the user comparison routine are specified,
162the root paths are processed in sorted order.
163Otherwise, the root paths are processed in the order specified by
164the user.
165.PP
166The
167.I ftsclose
168routine closes a file hierarchy stream and changes the current
169directory to the directory
170.I ftsopen
171was called from.
172.I Ftsclose
173returns 0 on success, and -1 if an error occurs.
174.PP
175Each call to the
176.I ftsread
177routine returns a pointer to an FTSENT structure describing a file in
178the hierarchy.
179Directories (that are readable, searchable and do not cause cycles)
180are visited at least twice, before any of their descendants have been
181visited (pre-order) and after all their descendants have been visited
182(post-order).
183All other files are visited at least once.
184.PP
185The FTSENT structure contains at least the following fields:
186.sp
187.RS
188.nf
189.ta .5i +.5i +\w'struct ftsent *parent;\0\0\0'u
190typedef struct ftsent {
191 struct ftsent *parent; /* parent structure */
192 struct ftsent *link; /* cycle or file structure */
193 union {
194 long number; /* local numeric value */
195 void *pointer; /* local address value */
196 } local;
197 char *accpath; /* path from current directory */
198 char *path; /* path from starting directory */
199 char *name; /* file name */
200 short pathlen; /* strlen(path) */
201 short namelen; /* strlen(name) */
202 short level; /* depth (\-1 to N) */
203 unsigned short info; /* flags for entry */
204 struct stat statb; /* stat(2) information */
205} FTSENT;
206.fi
207.RE
208.PP
209The fields are as follows:
210.TP
211parent
212A pointer to a structure referencing the file in the hierarchy
213immediately above the current file/structure.
214A parent structure for the initial entry point is provided as well,
215however, only the
216.I local
217and
218.I level
219fields are guaranteed to be initialized.
220.TP
221link
222If a directory causes a cycle in the hierarchy, either because of a
223hard link between two directories, or a symbolic link pointing to a
224directory, the
225.I link
226field of the structure will point to the structure in the hierarchy
227that references the same file as the current structure.
228Upon return from the
229.I ftschildren
230routine, the
231.I link
232field points to the next structure in the linked list of entries
233from the directory.
234Otherwise, the contents of the link field are undefined.
235.TP
236local
237This field is provided for the use of the application program.
238It can be used to store either a long value or an address.
239.TP
240accpath
241A path that can be used to access the file.
242.TP
243path
244The path for the file relative to the root of the traversal.
245.TP
246name
247The basename of the file.
248.TP
249pathlen
250The length of the string referenced by
251.IR path .
252.TP
253namelen
254The length of the string referenced by
255.IR name .
256.TP
257level
258The depth of the traversal, numbered from \-1 to N.
259The parent structure of the root of the traversal is numbered \-1, and
260the structure for the root of the traversal is numbered 0.
261.TP
262info
263Information describing the file.
264With the exception of directories (FTS_D), all of these entries are
265terminal, i.e. they will not be revisited, nor will their descendants
266be visited (if they have not been visited already).
267.RS
268.TP
269FTS_D
270A directory being visited in pre-order.
271.TP
272FTS_DC
273A directory that causes a cycle.
274The
275.I link
276field of the structure will be filled in as well.
277.TP
278FTS_DEFAULT
279Anything that's not one of the others.
280.TP
281FTS_DNR
282A directory that cannot be read.
283.TP
284FTS_DNX
285A directory that cannot be searched.
286.TP
287FTS_DOT
288A file named ``.'' or ``..'' with a
289.I level
290field not equal to zero, i.e. one not specified as an argument to
291.IR ftsopen .
292(See FTS_SEEDOT.)
293.TP
294FTS_DP
295A directory that is being visited in post-order.
296The contents of the structure will be unchanged from when the
297directory was visited in pre-order.
298.TP
299FTS_ERR
300An error indicator; the external variable
301.I errno
302contains an error number indicating the reason for the error.
303.TP
304FTS_F
305A regular file.
306.TP
307FTS_NS
308No
309.IR stat (2)
310information is available at this time (see FTS_NOSTAT); the
311contents of the
312.I statb
313field are undefined.
314.TP
315FTS_SL
316A symbolic link.
317.TP
318FTS_SLNONE
319A symbolic link with a non-existent target.
320.RE
321.TP
322statb
323.IR Stat (2)
324information for the file.
325.PP
326The
327.IR accpath
328and
329.I path
330fields are guaranteed to be NULL-terminated
331.B only
332for the file most recently returned by
333.IR ftsread .
334The
335.I name
336field is always NULL-terminated.
337To use these fields to reference any other active files may require
338that they be modified using the information contained in the
339.I pathlen
340field.
341Any such modifications should be undone before further calls to
342.I ftsread
343are attempted.
344.PP
345If all the members of the hierarchy have been returned,
346.I ftsread
347returns NULL and sets the external variable
348.I errno
349to 0.
350If an error unrelated to a file in the hierarchy occurs,
351.I ftsread
352returns NULL and sets errno appropriately.
353Otherwise, a pointer to an FTSENT structure is returned, and an
354error may or may not have occurred; see FTS_ERR above.
355.PP
356When the most recently returned file from
357.I ftsread
358is a directory being visited in pre-order,
359.I ftschildren
360returns a pointer to the first entry in a linked list (sorted by
361the comparison routine, if provided) of the directory entries
362it contains.
363The linked list is linked through the
364.I link
365field of the FTSENT structure.
366Each call to
367.I ftschildren
368recreates the list.
369Note, cycles are not detected until a directory is actually visited,
370therefore
371.I ftschildren
372will never return a structure with an
373.I info
374field set to FTS_DC.
375If the current file is not a directory being visited in pre-order,
376or if an error occurs, or the file does not contain any entries
377.I ftschildren
378returns NULL.
379If an error occurs,
380.I ftschildren
381sets errno appropriately, otherwise it sets errno to zero.
382.PP
383The pointers returned by
384.I ftsread
385and
386.I ftschildren
387point to structures which may be overwritten.
388Structures returned by
389.I ftschildren
390and
391.I ftsread
392may be overwritten after a call to
393.I ftsclose
394on the same file hierarchy.
395Otherwise, structures returned by
396.I ftschildren
397will not be overwritten until a subsequent call to either
398.I ftschildren
399or
400.I ftsread
401on the same file hierarchy.
402Structures returned by
403.I ftsread
404will not not be overwritten until a subsequent call to
405.I ftsread
406on the same file hierarchy stream, unless it represents a file of type
407directory, in which case it will not be overwritten until after a
408subsequent call to
409.I ftsread
410after it has been returned by the function
411.I ftsread
412in post-order.
413.PP
414The routine
415.I ftsset
416allows the user application to determine further processing for the
417file
418.I f
419of the stream
420.IR ftsp .
421.I Ftsset
422returns 0 on success, and -1 if an error occurs.
423.I Option
424may be set to any one of the following values.
425.TP
426FTS_AGAIN
427Re-visit the file; any file type may be re-visited.
428The next call to
429.I ftsread
430will return the referenced file.
431The
432.I stat
433and
434.I info
435fields of the structure will be reinitialized at that time,
436but no other fields will have been modified.
437This option is meaningful only for the most recently returned
438file from
439.IR ftsread .
440Normal use is for post-order directory visits, where it causes the
441directory to be re-visited (in both pre and post-order) as well as all
442of its descendants.
443.TP
444FTS_FOLLOW
445The referenced file must be a symbolic link.
446If the referenced file is the one most recently returned by
447.IR ftsread ,
448the next call to
449.I ftsread
450returns the file with the
451.I info
452and
453.I statb
454fields reinitialized to reflect the target of the symbolic link instead
455of the symbolic link itself.
456If the file is one of those most recently returned by
457.IR ftschildren ,
458the
459.I info
460and
461.I statb
462fields of the structure, when returned by
463.IR ftsread ,
464will reflect the target of the symbolic link instead of the symbolic link
465itself.
466In either case, if the target of the link is a directory, the pre-order
467return, followed by the return of all of its descendants, followed by a
468post-order return, is done.
469.TP
470FTS_SKIP
471No descendants of this file are visited.
472.PP
473Hard links between directories that do not cause cycles or symbolic
474links to symbolic links may cause files to be visited more than once,
475or directories more than twice.
476.SH ERRORS
477.I Ftsopen
478may fail and set errno for any of the errors specified for the library
479routine
480.IR malloc (3).
481.PP
482.I Ftsclose
483may fail and set errno for any of the errors specified for the library
484routine
485.IR chdir (2).
486.PP
487.I Ftsread
488and
489.I ftschildren
490may fail and set errno for any of the errors specified for the library
491routines
492.IR chdir (2),
493.IR getgroups (2),
494.IR malloc (3),
495.IR opendir (3),
496.IR readdir (3)
497and
498.IR stat (2).
499.SH SEE ALSO
500find(1), chdir(2), stat(2), qsort(3)
501.SH STANDARDS
502The
503.I fts
504utility is expected to be POSIX 1003.1 compliant.