1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
|
pathchk(P) pathchk(P)
NAME
pathchk - check pathnames
SYNOPSIS
pathchk [-p] pathname...
DESCRIPTION
The pathchk utility shall check that one or more path-
names are valid (that is, they could be used to access
or create a file without causing syntax errors) and por-
table (that is, no filename truncation results). More
extensive portability checks are provided by the -p
option.
By default, the pathchk utility shall check each compo-
nent of each pathname operand based on the underlying
file system. A diagnostic shall be written for each
pathname operand that:
Is longer than {PATH_MAX} bytes (see Pathname
Variable Values in the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 13, Headers, <lim-
its.h>)
Contains any component longer than {NAME_MAX}
bytes in its containing directory
Contains any component in a directory that is not
searchable
Contains any character in any component that is
not valid in its containing directory
The format of the diagnostic message is not specified,
but shall indicate the error detected and the corre-
sponding pathname operand.
It shall not be considered an error if one or more com-
ponents of a pathname operand do not exist as long as a
file matching the pathname specified by the missing com-
ponents could be created that does not violate any of
the checks specified above.
OPTIONS
The pathchk utility shall conform to the Base Defini-
tions volume of IEEE Std 1003.1-2001, Section 12.2,
Utility Syntax Guidelines.
The following option shall be supported:
-p Instead of performing checks based on the under-
lying file system, write a diagnostic for each
pathname operand that:
Is longer than {_POSIX_PATH_MAX} bytes (see Mini-
mum Values in the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 13, Headers, <lim-
its.h>)
Contains any component longer than
{_POSIX_NAME_MAX} bytes
Contains any character in any component that is
not in the portable filename character set
OPERANDS
The following operand shall be supported:
pathname
A pathname to be checked.
STDIN
Not used.
INPUT FILES
None.
ENVIRONMENT VARIABLES
The following environment variables shall affect the
execution of pathchk:
LANG Provide a default value for the internationaliza-
tion variables that are unset or null. (See the
Base Definitions volume of IEEE Std 1003.1-2001,
Section 8.2, Internationalization Variables for
the precedence of internationalization variables
used to determine the values of locale cate-
gories.)
LC_ALL If set to a non-empty string value, override the
values of all the other internationalization
variables.
LC_CTYPE
Determine the locale for the interpretation of
sequences of bytes of text data as characters
(for example, single-byte as opposed to multi-
byte characters in arguments).
LC_MESSAGES
Determine the locale that should be used to
affect the format and contents of diagnostic mes-
sages written to standard error.
NLSPATH
Determine the location of message catalogs for
the processing of LC_MESSAGES .
ASYNCHRONOUS EVENTS
Default.
STDOUT
Not used.
STDERR
The standard error shall be used only for diagnostic
messages.
OUTPUT FILES
None.
EXTENDED DESCRIPTION
None.
EXIT STATUS
The following exit values shall be returned:
0 All pathname operands passed all of the checks.
>0 An error occurred.
CONSEQUENCES OF ERRORS
Default.
The following sections are informative.
APPLICATION USAGE
The test utility can be used to determine whether a
given pathname names an existing file; it does not, how-
ever, give any indication of whether or not any compo-
nent of the pathname was truncated in a directory where
the _POSIX_NO_TRUNC feature is not in effect. The
pathchk utility does not check for file existence; it
performs checks to determine whether a pathname does
exist or could be created with no pathname component
truncation.
The noclobber option in the shell (see the set special
built-in) can be used to atomically create a file. As
with all file creation semantics in the System Inter-
faces volume of IEEE Std 1003.1-2001, it guarantees
atomic creation, but still depends on applications to
agree on conventions and cooperate on the use of files
after they have been created.
EXAMPLES
To verify that all pathnames in an imported data inter-
change archive are legitimate and unambiguous on the
current system:
pax -f archive | sed -e '/ == .*/s///' | xargs pathchk
if [ $? -eq 0 ]
then
pax -r -f archive
else
echo Investigate problems before importing files.
exit 1
fi
To verify that all files in the current directory hier-
archy could be moved to any system conforming to the
System Interfaces volume of IEEE Std 1003.1-2001 that
also supports the pax utility:
find . -print | xargs pathchk -p
if [ $? -eq 0 ]
then
pax -w -f archive .
else
echo Portable archive cannot be created.
exit 1
fi
To verify that a user-supplied pathname names a readable
file and that the application can create a file extend-
ing the given path without truncation and without over-
writing any existing file:
case $- in
*C*) reset="";;
*) reset="set +C"
set -C;;
esac
test -r "$path" && pathchk "$path.out" &&
rm "$path.out" > "$path.out"
if [ $? -ne 0 ]; then
printf "%s: %s not found or %s.out fails \
creation checks.\n" $0 "$path" "$path"
$reset # Reset the noclobber option in case a trap
# on EXIT depends on it.
exit 1
fi
$reset
PROCESSING < "$path" > "$path.out"
The following assumptions are made in this example:
PROCESSING represents the code that is used by the
application to use $path once it is verified that
$path.out works as intended.
The state of the noclobber option is unknown when this
code is invoked and should be set on exit to the state
it was in when this code was invoked. (The reset vari-
able is used in this example to restore the initial
state.)
Note the usage of:
rm "$path.out" > "$path.out"
<ol type="a">
The pathchk command has already verified, at this point,
that $path.out is not truncated.
With the noclobber option set, the shell verifies that
$path.out does not already exist before invoking rm.
If the shell succeeded in creating $path.out, rm removes
it so that the application can create the file again in
the PROCESSING step.
If the PROCESSING step wants the file to exist already
when it is invoked, the:
rm "$path.out" > "$path.out"
should be replaced with:
> "$path.out"
which verifies that the file did not already exist, but
leaves $path.out in place for use by PROCESSING.
RATIONALE
The pathchk utility was new for the ISO POSIX-2:1993
standard. It, along with the set -C( noclobber) option
added to the shell, replaces the mktemp, validfnam, and
create utilities that appeared in early proposals. All
of these utilities were attempts to solve several common
problems:
Verify the validity (for several different defi-
nitions of "valid") of a pathname supplied by a
user, generated by an application, or imported
from an external source.
Atomically create a file.
Perform various string handling functions to gen-
erate a temporary filename.
The create utility, included in an early proposal, pro-
vided checking and atomic creation in a single
invocation of the utility; these are orthogonal issues
and need not be grouped into a single utility. Note that
the noclobber option also provides a way of creating a
lock for process synchronization; since it provides an
atomic create, there is no race between a test for exis-
tence and the following creation if it did not exist.
Having a function like tmpnam() in the ISO C standard is
important in many high-level languages. The shell pro-
gramming language, however, has built-in string manipu-
lation facilities, making it very easy to construct tem-
porary filenames. The names needed obviously depend on
the application, but are frequently of a form similar
to:
$TMPDIR/application_abbreviation$$.suffix
In cases where there is likely to be contention for a
given suffix, a simple shell for or while loop can be
used with the shell noclobber option to create a file
without risk of collisions, as long as applications try-
ing to use the same filename name space are cooperating
on the use of files after they have been created.
FUTURE DIRECTIONS
None.
SEE ALSO
Redirection , set , test
COPYRIGHT
Portions of this text are reprinted and reproduced in
electronic form from IEEE Std 1003.1, 2003 Edition,
Standard for Information Technology -- Portable Operat-
ing System Interface (POSIX), The Open Group Base Speci-
fications Issue 6, Copyright (C) 2001-2003 by the Insti-
tute of Electrical and Electronics Engineers, Inc and
The Open Group. In the event of any discrepancy between
this version and the original IEEE and The Open Group
Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be
obtained online at http://www.open-
group.org/unix/online.html .
POSIX 2003 pathchk(P)
|
