pathchk man page on CentOS

Man page or keyword search:  
man Server   8420 pages
apropos Keyword Search (all sections)
Output format
CentOS logo
[printable version]

PATHCHK(P)		   POSIX Programmer's Manual		    PATHCHK(P)

PROLOG
       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
       implementation of this interface may differ (consult the	 corresponding
       Linux  manual page for details of Linux behavior), or the interface may
       not be implemented on Linux.

NAME
       pathchk - check pathnames

SYNOPSIS
       pathchk [-p] pathname...

DESCRIPTION
       The pathchk utility shall check that one or more	 pathnames  are	 valid
       (that is, they could be used to access or create a file without causing
       syntax errors) and portable (that is, no filename truncation  results).
       More extensive portability checks are provided by the -p option.

       By  default,  the  pathchk  utility  shall check each component 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,	 Head‐
	  ers, <limits.h>)

	* Contains  any component longer than {NAME_MAX} bytes in its contain‐
	  ing 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 indi‐
       cate the error detected and the corresponding pathname operand.

       It shall not be considered an error if one  or  more  components	 of  a
       pathname	 operand  do not exist as long as a file matching the pathname
       specified by the missing components could be created that does not vio‐
       late any of the checks specified above.

OPTIONS
       The  pathchk  utility  shall  conform to the Base Definitions 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 underlying  file  sys‐
	      tem, write a diagnostic for each pathname operand that:

	       * Is longer than {_POSIX_PATH_MAX} bytes (see Minimum Values in
		 the Base Definitions volume of IEEE Std 1003.1-2001,  Chapter
		 13, Headers, <limits.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 internationalization variables
	      that are unset or null. (See  the	 Base  Definitions  volume  of
	      IEEE Std 1003.1-2001,  Section  8.2,  Internationalization Vari‐
	      ables for the precedence of internationalization variables  used
	      to determine the values of locale categories.)

       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 messages 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, however, give any indication of
       whether or not any component of the pathname was truncated in a	direc‐
       tory  where  the	 _POSIX_NO_TRUNC feature is not in effect. The pathchk
       utility does not check for file existence; it performs checks to deter‐
       mine 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 Interfaces volume of IEEE Std 1003.1-2001, it  guarantees
       atomic  creation, but still depends on applications to agree on conven‐
       tions and cooperate on the use of files after they have been created.

EXAMPLES
       To verify that all pathnames in an imported  data  interchange  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 hierarchy 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  extending  the  given	 path  without
       truncation and without overwriting 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:

	1. PROCESSING  represents  the code that is used by the application to
	   use $path once it is verified that $path.out works 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 is not truncated.

	    b. With  the  noclobber  option  set,  the	shell  verifies	  that
	       $path.out does not already exist before invoking rm.

	    c. If  the shell succeeded in creating $path.out, rm removes it so
	       that the application can create the file again in the  PROCESS‐
	       ING 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 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 pro‐
       posals. All of these utilities were attempts to	solve  several	common
       problems:

	* Verify  the  validity (for several different definitions 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 generate a temporary
	  filename.

       The create utility, included in an early	 proposal,  provided  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 existence 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 programming language, however, has
       built-in string manipulation facilities, making it very	easy  to  con‐
       struct  temporary  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 applica‐
       tions trying 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 Operating System Interface (POSIX),	The  Open  Group  Base
       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute 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.opengroup.org/unix/online.html .

IEEE/The Open Group		     2003			    PATHCHK(P)
[top]

List of man pages available for CentOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net