pathchk(1) [osf1 man page]
pathchk(1) General Commands Manual pathchk(1) NAME
pathchk - Checks path names SYNOPSIS
pathchk [-p] pathname... STANDARDS
Interfaces documented on this reference page conform to industry standards as follows: pathchk: XCU5.0 Refer to the standards(5) reference page for more information about industry standards and associated tags. OPTIONS
Performs path name checks based on POSIX portability standards. An error message is sent if any of the following conditions are true: The byte length of the full path name is longer than allowed by POSIX standards ({_POSIX_PATH_MAX}). The byte length of a component is longer than allowed by POSIX standards ({_POSIX_NAME_MAX}). A character in any component is not in the portable file name character set. OPERANDS
The path name to be checked. DESCRIPTION
The pathchk command checks that one or more path names are valid (that is, they can be used to access or create a file without causing syn- tax errors) and portable (that is, no file name truncation will result). By default, the pathchk command checks each component of each path name specified by the pathname argument based on the underlying file system. If the -p option is not specified, pathchk sends an error message if any of the following conditions are true: The byte length of the full path name is longer than allowed by the system ({PATH_MAX} bytes). The byte length of a component is longer than allowed by the system ({NAME_MAX} bytes). Search permission is not allowed for a component. A character in any component is not valid in its containing directory. It is not considered an error if one or more components of a path name do not exist, as long as a file matching the path name specified by the pathname argument could be created without violating any of the preceding criteria. EXAMPLES
To check the validity and portability of the /u/bob/work/tempfiles path name, enter: pathchk /u/bob/work/tempfiles To check the validity and portability of the /u/bob/temp path name for POSIX standards, enter: pathchk -p /u/bob/temp ENVIRONMENT VARIABLES
The following environment variables affect the execution of pathchk: Provides a default value for the internationalization variables that are unset or null. If LANG is unset or null, the corresponding value from the default locale is used. If any of the internationalization variables contain an invalid setting, the utility behaves as if none of the variables had been defined. If set to a non-empty string value, overrides the values of all the other internationalization variables. Determines the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multibyte characters in arguments). Determines the locale for the format and contents of diagnostic messages written to standard error. Determines the location of message catalogues for the processing of LC_MESSAGES. FILES
System maximum values EXIT STATUS
The pathchk command returns the following exit values: All path name operands passed the checks. An error occurred. SEE ALSO
Commands: test(1) Files: limits(4) Standards: standards(5) pathchk(1)
Check Out this Related Man Page
pathchk(1) User Commands pathchk(1) NAME
pathchk - check path names SYNOPSIS
pathchk [-p] path... DESCRIPTION
The pathchk command will check that one or more path names are valid (that is, they could be used to access or create a file without caus- ing syntax errors) and portable (that is, no filename truncation will result). More extensive portability checks are provided by the -p option. By default, pathchk will check each component of each path operand based on the underlying file system. A diagnostic will be written for each path operand that: o is longer than PATH_MAX bytes. o contains any component longer than NAME_MAX bytes in its containing directory o contains any component in a directory that is not searchable o contains any character in any component that is not valid in its containing directory. The format of the diagnostic message is not specified, but will indicate the error detected and the corresponding path operand. It will not be considered an error if one or more components of a path operand do not exist as long as a file matching the path name speci- fied by the missing components could be created that does not violate any of the checks specified above. OPTIONS
The following option is supported: -p Instead of performing checks based on the underlying file system, write a diagnostic for each path operand that: o is longer than _POSIX_PATH_MAX bytes o contains any component longer than _POSIX_NAME_MAX bytes o contains any character in any component that is not in the portable filename character set. OPERANDS
The following operand is supported: path A path to be checked. USAGE
See largefile(5) for the description of the behavior of pathchk when encountering files greater than or equal to 2 Gbyte ( 2**31 bytes). EXAMPLES
Example 1: Using the pathchk command To verify that all paths in an imported data interchange archive are legitimate and unambiguous on the current system: example% 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 hierarchy could be moved to any system conforming to the X/Open specification that also supports the pax(1) command: example% 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 path names a readable file and that the application can create a file extending the given path without trun- cation and without overwriting any existing file: example% 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. " $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: 1. PROCESSING represents the code that will be used by the application to use $path once it is verified that $path.out will work as intended. 2. 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 variable is used in this example to restore the initial state.) 3. Note the usage of: rm "$path.out" > "$path.out" a. The pathchk command has already verified, at this point, that $path.out will not be truncated. b. With the noclobber option set, the shell will verify that $path.out does not already exist before invoking rm. c. If the shell succeeded in creating $path.out, rm will remove it so that the application can create the file again in the PRO- CESSING step. d. 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 will verify that the file did not already exist, but leave $path.out in place for use by PROCESSING. ENVIRONMENT VARIABLES
See environ(5) for descriptions of the following environment variables that affect the execution of pathchk: LANG, LC_ALL, LC_CTYPE, LC_MESSAGES, and NLSPATH. EXIT STATUS
The following exit values are returned: 0 All path operands passed all of the checks. >0 An error occurred. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Availability |SUNWcsu | +-----------------------------+-----------------------------+ |Interface Stability |Standard | +-----------------------------+-----------------------------+ SEE ALSO
pax(1), test(1), attributes(5), environ(5), largefile(5), standards(5) SunOS 5.10 1 Feb 1995 pathchk(1)