1PATHCHK(P)                 POSIX Programmer's Manual                PATHCHK(P)
2
3
4

NAME

6       pathchk - check pathnames
7

SYNOPSIS

9       pathchk [-p] pathname...
10

DESCRIPTION

12       The  pathchk  utility  shall check that one or more pathnames are valid
13       (that is, they could be used to access or create a file without causing
14       syntax  errors) and portable (that is, no filename truncation results).
15       More extensive portability checks are provided by the -p option.
16
17       By default, the pathchk utility shall  check  each  component  of  each
18       pathname  operand  based  on  the  underlying file system. A diagnostic
19       shall be written for each pathname operand that:
20
21        * Is longer than {PATH_MAX} bytes (see Pathname Variable Values in the
22          Base  Definitions  volume of IEEE Std 1003.1-2001, Chapter 13, Head‐
23          ers, <limits.h>)
24
25        * Contains any component longer than {NAME_MAX} bytes in its  contain‐
26          ing directory
27
28        * Contains any component in a directory that is not searchable
29
30        * Contains  any  character  in  any component that is not valid in its
31          containing directory
32
33       The format of the diagnostic message is not specified, but shall  indi‐
34       cate the error detected and the corresponding pathname operand.
35
36       It  shall  not  be  considered  an error if one or more components of a
37       pathname operand do not exist as long as a file matching  the  pathname
38       specified by the missing components could be created that does not vio‐
39       late any of the checks specified above.
40

OPTIONS

42       The pathchk utility shall conform to the  Base  Definitions  volume  of
43       IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
44
45       The following option shall be supported:
46
47       -p     Instead  of  performing checks based on the underlying file sys‐
48              tem, write a diagnostic for each pathname operand that:
49
50               * Is longer than {_POSIX_PATH_MAX} bytes (see Minimum Values in
51                 the  Base Definitions volume of IEEE Std 1003.1-2001, Chapter
52                 13, Headers, <limits.h>)
53
54               * Contains any component longer than {_POSIX_NAME_MAX} bytes
55
56               * Contains any character in any component that is  not  in  the
57                 portable filename character set
58

OPERANDS

60       The following operand shall be supported:
61
62       pathname
63              A pathname to be checked.
64
65

STDIN

67       Not used.
68

INPUT FILES

70       None.
71

ENVIRONMENT VARIABLES

73       The  following  environment  variables  shall  affect  the execution of
74       pathchk:
75
76       LANG   Provide a default value for the  internationalization  variables
77              that  are  unset  or  null.  (See the Base Definitions volume of
78              IEEE Std 1003.1-2001, Section  8.2,  Internationalization  Vari‐
79              ables  for the precedence of internationalization variables used
80              to determine the values of locale categories.)
81
82       LC_ALL If set to a non-empty string value, override the values  of  all
83              the other internationalization variables.
84
85       LC_CTYPE
86              Determine  the  locale  for  the  interpretation of sequences of
87              bytes of text data as characters (for  example,  single-byte  as
88              opposed to multi-byte characters in arguments).
89
90       LC_MESSAGES
91              Determine  the  locale  that should be used to affect the format
92              and contents of diagnostic messages written to standard error.
93
94       NLSPATH
95              Determine the location of message catalogs for the processing of
96              LC_MESSAGES .
97
98

ASYNCHRONOUS EVENTS

100       Default.
101

STDOUT

103       Not used.
104

STDERR

106       The standard error shall be used only for diagnostic messages.
107

OUTPUT FILES

109       None.
110

EXTENDED DESCRIPTION

112       None.
113

EXIT STATUS

115       The following exit values shall be returned:
116
117        0     All pathname operands passed all of the checks.
118
119       >0     An error occurred.
120
121

CONSEQUENCES OF ERRORS

123       Default.
124
125       The following sections are informative.
126

APPLICATION USAGE

128       The  test  utility  can  be  used to determine whether a given pathname
129       names an existing file; it does not, however, give  any  indication  of
130       whether  or not any component of the pathname was truncated in a direc‐
131       tory where the _POSIX_NO_TRUNC feature is not in  effect.  The  pathchk
132       utility does not check for file existence; it performs checks to deter‐
133       mine whether a pathname does exist or could be created with no pathname
134       component truncation.
135
136       The noclobber option in the shell (see the set special built-in) can be
137       used to atomically create a file. As with all file  creation  semantics
138       in  the System Interfaces volume of IEEE Std 1003.1-2001, it guarantees
139       atomic creation, but still depends on applications to agree on  conven‐
140       tions and cooperate on the use of files after they have been created.
141

EXAMPLES

143       To  verify  that  all pathnames in an imported data interchange archive
144       are legitimate and unambiguous on the current system:
145
146
147              pax -f archive | sed -e '/ == .*/s///' | xargs pathchk
148              if [ $? -eq 0 ]
149              then
150                  pax -r -f archive
151              else
152                  echo Investigate problems before importing files.
153                  exit 1
154              fi
155
156       To verify that all files in the current directory  hierarchy  could  be
157       moved  to  any  system  conforming  to  the System Interfaces volume of
158       IEEE Std 1003.1-2001 that also supports the pax utility:
159
160
161              find . -print | xargs pathchk -p
162              if [ $? -eq 0 ]
163              then
164                  pax -w -f archive .
165              else
166                  echo Portable archive cannot be created.
167                  exit 1
168              fi
169
170       To verify that a user-supplied pathname names a readable file and  that
171       the  application  can  create  a  file extending the given path without
172       truncation and without overwriting any existing file:
173
174
175              case $- in
176                  *C*)    reset="";;
177                  *)      reset="set +C"
178                          set -C;;
179              esac
180              test -r "$path" && pathchk "$path.out" &&
181                  rm "$path.out" > "$path.out"
182              if [ $? -ne 0 ]; then
183                  printf "%s: %s not found or %s.out fails \
184              creation checks.\n" $0 "$path" "$path"
185                  $reset    # Reset the noclobber option in case a trap
186                            # on EXIT depends on it.
187                  exit 1
188              fi
189              $reset
190              PROCESSING < "$path" > "$path.out"
191
192       The following assumptions are made in this example:
193
194        1. PROCESSING represents the code that is used by the  application  to
195           use $path once it is verified that $path.out works as intended.
196
197        2. The  state  of  the  noclobber  option is unknown when this code is
198           invoked and should be set on exit to the state it was in when  this
199           code  was  invoked.  (The reset variable is used in this example to
200           restore the initial state.)
201
202        3. Note the usage of:
203
204
205           rm "$path.out" > "$path.out"
206
207            a. The pathchk command has already verified, at this  point,  that
208               $path.out is not truncated.
209
210            b. With   the  noclobber  option  set,  the  shell  verifies  that
211               $path.out does not already exist before invoking rm.
212
213            c. If the shell succeeded in creating $path.out, rm removes it  so
214               that  the application can create the file again in the PROCESS‐
215               ING step.
216
217            d. If the PROCESSING step wants the file to exist already when  it
218               is invoked, the:
219
220
221               rm "$path.out" > "$path.out"
222
223           should be replaced with:
224
225
226                  > "$path.out"
227
228           which  verifies  that  the  file  did not already exist, but leaves
229           $path.out in place for use by PROCESSING.
230

RATIONALE

232       The pathchk utility was new for  the  ISO POSIX-2:1993  standard.   It,
233       along  with  the set -C( noclobber) option added to the shell, replaces
234       the mktemp, validfnam, and create utilities that appeared in early pro‐
235       posals.  All  of  these utilities were attempts to solve several common
236       problems:
237
238        * Verify the validity (for several different definitions  of  "valid")
239          of  a  pathname  supplied by a user, generated by an application, or
240          imported from an external source.
241
242        * Atomically create a file.
243
244        * Perform various string handling functions to  generate  a  temporary
245          filename.
246
247       The  create  utility,  included in an early proposal, provided checking
248       and atomic creation in a single invocation of the  utility;  these  are
249       orthogonal  issues  and need not be grouped into a single utility. Note
250       that the noclobber option also provides a way of creating  a  lock  for
251       process  synchronization;  since it provides an atomic create, there is
252       no race between a test for existence and the following creation  if  it
253       did not exist.
254
255       Having  a  function like tmpnam() in the ISO C standard is important in
256       many high-level languages. The shell programming language, however, has
257       built-in  string  manipulation  facilities, making it very easy to con‐
258       struct temporary filenames. The names needed obviously  depend  on  the
259       application, but are frequently of a form similar to:
260
261
262              $TMPDIR/application_abbreviation$$.suffix
263
264       In  cases  where there is likely to be contention for a given suffix, a
265       simple shell for or while loop can be used  with  the  shell  noclobber
266       option to create a file without risk of collisions, as long as applica‐
267       tions trying to use the same filename name space are cooperating on the
268       use of files after they have been created.
269

FUTURE DIRECTIONS

271       None.
272

SEE ALSO

274       Redirection , set , test
275
277       Portions  of  this text are reprinted and reproduced in electronic form
278       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
279       --  Portable  Operating  System  Interface (POSIX), The Open Group Base
280       Specifications Issue 6, Copyright (C) 2001-2003  by  the  Institute  of
281       Electrical  and  Electronics  Engineers, Inc and The Open Group. In the
282       event of any discrepancy between this version and the original IEEE and
283       The  Open Group Standard, the original IEEE and The Open Group Standard
284       is the referee document. The original Standard can be  obtained  online
285       at http://www.opengroup.org/unix/online.html .
286
287
288
289IEEE/The Open Group                  2003                           PATHCHK(P)
Impressum