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



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


NNAAMMEE
       pathchk -- check pathnames

SSYYNNOOPPSSIISS
       pathchk [[-p]] [[-P]] _p_a_t_h_n_a_m_e...

DDEESSCCRRIIPPTTIIOONN
       The _p_a_t_h_c_h_k 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 --pp and --PP
       options.

       By default, the _p_a_t_h_c_h_k utility shall check each component of each
       _p_a_t_h_n_a_m_e operand based on the underlying file system. A diagnostic
       shall be written for each _p_a_t_h_n_a_m_e operand that:

        *  Is longer than {PATH_MAX} bytes (see PPaatthhnnaammee VVaarriiaabbllee VVaalluueess in
           the Base Definitions volume of POSIX.1-2008, <<lliimmiittss..hh>>)

        *  Contains any component longer than {NAME_MAX} bytes in its
           containing directory

        *  Contains any component in a directory that is not searchable

        *  Contains any byte sequence 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 corresponding _p_a_t_h_n_a_m_e operand.

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

OOPPTTIIOONNSS
       The _p_a_t_h_c_h_k utility shall conform to the Base Definitions volume of
       POSIX.1-2008, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s.

       The following option shall be supported:

       --pp        Instead of performing checks based on the underlying file
                 system, write a diagnostic for each _p_a_t_h_n_a_m_e operand that:

                  *  Is longer than {_POSIX_PATH_MAX} bytes (see MMiinniimmuumm
                     VVaalluueess in the Base Definitions volume of POSIX.1-2008,
                     <<lliimmiittss..hh>>)

                  *  Contains any component longer than {_POSIX_NAME_MAX}
                     bytes

                  *  Contains any character in any component that is not in
                     the portable filename character set

       --PP        Write a diagnostic for each _p_a_t_h_n_a_m_e operand that:

                  *  Contains a component whose first character is the
                     <hyphen> character

                  *  Is empty

OOPPEERRAANNDDSS
       The following operand shall be supported:

       _p_a_t_h_n_a_m_e  A pathname to be checked.

SSTTDDIINN
       Not used.

IINNPPUUTT FFIILLEESS
       None.

EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS
       The following environment variables shall affect the execution of
       _p_a_t_h_c_h_k:

       _L_A_N_G      Provide a default value for the internationalization
                 variables that are unset or null. (See the Base Definitions
                 volume of POSIX.1-2008, _S_e_c_t_i_o_n _8_._2, _I_n_t_e_r_n_a_t_i_o_n_a_l_i_z_a_t_i_o_n
                 _V_a_r_i_a_b_l_e_s the precedence of internationalization variables
                 used to determine the values of locale categories.)

       _L_C___A_L_L    If set to a non-empty string value, override the values of
                 all the other internationalization variables.

       _L_C___C_T_Y_P_E  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).

       _L_C___M_E_S_S_A_G_E_S
                 Determine the locale that should be used to affect the format
                 and contents of diagnostic messages written to standard
                 error.

       _N_L_S_P_A_T_H   Determine the location of message catalogs for the processing
                 of _L_C___M_E_S_S_A_G_E_S.

AASSYYNNCCHHRROONNOOUUSS EEVVEENNTTSS
       Default.

SSTTDDOOUUTT
       Not used.

SSTTDDEERRRR
       The standard error shall be used only for diagnostic messages.

OOUUTTPPUUTT FFIILLEESS
       None.

EEXXTTEENNDDEEDD DDEESSCCRRIIPPTTIIOONN
       None.

EEXXIITT SSTTAATTUUSS
       The following exit values shall be returned:

        0    All _p_a_t_h_n_a_m_e operands passed all of the checks.

       >0    An error occurred.

CCOONNSSEEQQUUEENNCCEESS OOFF EERRRROORRSS
       Default.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       The _t_e_s_t 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
       directory where the _POSIX_NO_TRUNC feature is not in effect. The
       _p_a_t_h_c_h_k 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 _n_o_c_l_o_b_b_e_r option in the shell (see the _s_e_t special built-in) can be
       used to atomically create a file. As with all file creation semantics
       in the System Interfaces volume of POSIX.1-2008, 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.

       To verify that a pathname meets the requirements of filename
       portability, applications should use both the --pp and --PP options
       together.

EEXXAAMMPPLLEESS
       To verify that all pathnames in an imported data interchange archive
       are legitimate and unambiguous on the current system:

           ## TThhiiss eexxaammppllee aassssuummeess tthhaatt nnoo ppaatthhnnaammeess iinn tthhee aarrcchhiivvee
           ## ccoonnttaaiinn <<nneewwlliinnee>> cchhaarraacctteerrss..
           ppaaxx --ff aarrcchhiivvee || sseedd --ee ''ss//[[^^[[::aallnnuumm::]]]]//\\\\&&//gg'' || xxaarrggss ppaatthhcchhkk ----
           iiff [[ $$?? --eeqq 00 ]]
           tthheenn
               ppaaxx --rr --ff aarrcchhiivvee
           eellssee
               eecchhoo IInnvveessttiiggaattee pprroobblleemmss bbeeffoorree iimmppoorrttiinngg ffiilleess..
               eexxiitt 11
           ffii

       To verify that all files in the current directory hierarchy could be
       moved to any system conforming to the System Interfaces volume of
       POSIX.1-2008 that also supports the _p_a_x utility:

           ffiinndd .. --eexxeecc ppaatthhcchhkk --pp --PP {{}} ++
           iiff [[ $$?? --eeqq 00 ]]
           tthheenn
               ppaaxx --ww --ff ....//aarrcchhiivvee ..
           eellssee
               eecchhoo PPoorrttaabbllee aarrcchhiivvee ccaannnnoott bbee ccrreeaatteedd..
               eexxiitt 11
           ffii

       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:

           ccaassee $$-- iinn
               **CC**))    rreesseett=="""";;;;
               **))      rreesseett==""sseett ++CC""
                       sseett --CC;;;;
           eessaacc
           tteesstt --rr ""$$ppaatthh"" &&&& ppaatthhcchhkk ""$$ppaatthh..oouutt"" &&&&
               rrmm ""$$ppaatthh..oouutt"" >> ""$$ppaatthh..oouutt""
           iiff [[ $$?? --nnee 00 ]];; tthheenn
               pprriinnttff ""%%ss:: %%ss nnoott ffoouunndd oorr %%ss..oouutt ffaaiillss \\
           ccrreeaattiioonn cchheecckkss..\\nn"" $$00 ""$$ppaatthh$$ppaatthh""
               $$rreesseett    ## RReesseett tthhee nnoocclloobbbbeerr ooppttiioonn iinn ccaassee aa ttrraapp
                         ## oonn EEXXIITT ddeeppeennddss oonn iitt..
               eexxiitt 11
           ffii
           $$rreesseett
           PPRROOCCEESSSSIINNGG << ""$$ppaatthh"" >> ""$$ppaatthh..oouutt""

       The following assumptions are made in this example:

        1. PPRROOCCEESSSSIINNGG represents the code that is used by the application to
           use $$ppaatthh once it is verified that $$ppaatthh..oouutt works as intended.

        2. The state of the _n_o_c_l_o_b_b_e_r 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 rreesseett variable is used in this example to
           restore the initial state.)

        3. Note the usage of:

               rrmm ""$$ppaatthh..oouutt"" >> ""$$ppaatthh..oouutt""

            a. The _p_a_t_h_c_h_k command has already verified, at this point, that
               $$ppaatthh..oouutt is not truncated.

            b. With the _n_o_c_l_o_b_b_e_r option set, the shell verifies that
               $$ppaatthh..oouutt does not already exist before invoking _r_m.

            c. If the shell succeeded in creating $$ppaatthh..oouutt, _r_m removes it so
               that the application can create the file again in the
               PPRROOCCEESSSSIINNGG step.

            d. If the PPRROOCCEESSSSIINNGG step wants the file to exist already when it
               is invoked, the:

                   rrmm ""$$ppaatthh..oouutt"" >> ""$$ppaatthh..oouutt""

               should be replaced with:

                   >> ""$$ppaatthh..oouutt""

               which verifies that the file did not already exist, but leaves
               $$ppaatthh..oouutt in place for use by PPRROOCCEESSSSIINNGG.

RRAATTIIOONNAALLEE
       The _p_a_t_h_c_h_k utility was new for the ISO POSIX-2:1993 standard. It,
       along with the _s_e_t --CC(_n_o_c_l_o_b_b_e_r) option added to the shell, replaces
       the _m_k_t_e_m_p, _v_a_l_i_d_f_n_a_m, and _c_r_e_a_t_e utilities that appeared in early
       proposals. 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 _c_r_e_a_t_e 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 _n_o_c_l_o_b_b_e_r option also provides a way of creating a lock for
       process synchronization; since it provides an atomic _c_r_e_a_t_e, there is
       no race between a test for existence and the following creation if it
       did not exist.

       Having a function like _t_m_p_n_a_m() 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
       construct temporary filenames. The names needed obviously depend on the
       application, but are frequently of a form similar to:

           $$TTMMPPDDIIRR//_a_p_p_l_i_c_a_t_i_o_n___a_b_b_r_e_v_i_a_t_i_o_n$$$$.._s_u_f_f_i_x

       In cases where there is likely to be contention for a given suffix, a
       simple shell ffoorr or wwhhiillee loop can be used with the shell _n_o_c_l_o_b_b_e_r
       option to create a file without risk of collisions, as long as
       applications trying to use the same filename name space are cooperating
       on the use of files after they have been created.

       For historical purposes, --pp does not check for the use of the <hyphen>
       character as the first character in a component of the pathname, or for
       an empty _p_a_t_h_n_a_m_e operand.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _S_e_c_t_i_o_n _2_._7, _R_e_d_i_r_e_c_t_i_o_n, _s_e_t, _t_e_s_t

       The Base Definitions volume of POSIX.1-2008, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t
       _V_a_r_i_a_b_l_e_s, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s, <<lliimmiittss..hh>>

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of
       Electrical and Electronics Engineers, Inc and The Open Group.  (This is
       POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) 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.unix.org/online.html .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2013                           PATHCHK(1)
