The following issue has been SUBMITTED. ====================================================================== http://austingroupbugs.net/view.php?id=1275 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1275 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section: 2.13.3 Page Number: 2384 Line Number: 76271 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2019-07-30 10:17 UTC Last Modified: 2019-07-30 10:17 UTC ====================================================================== Summary: pathname expansion errors Description: In the description of patterns used for pathname expansion, the standard states:<blockquote>Specified patterns shall be matched against existing filenames and pathnames, as appropriate. Each component that contains a pattern character shall require read permission in the directory containing that component. Any component, except the last, that does not contain a pattern character shall require search permission.</blockquote>However, it does not say what should happen if these permissions are denied.
The rules about error handling in utilities (1.4) and in the shell (2.8.1) seem to imply that the shell should report it as an error and a non-interactive shell should exit, but this is not what existing shells do. They instead treat it as a successful "no match" condition. There are other error conditions that should also be treated the same way, such as ELOOP, ENAMETOOLONG, ENOENT and ENOTDIR, since they imply that there are no matches (that are accessible to the process). For other conditions such as EMFILE, ENFILE, EIO and EOVERFLOW, there are opposing views as to how they should be handled. (For details refer to the email thread with subject "Re: [1003.1(2016)/Issue7+TC2 0001255]: improper shell code in glob() example" starting on Jul 21.) Thus the suggested changes have two options, one which requires that the shell treats these as an error and the other making it unspecified. Changes are also proposed for glob(), since this is intended to mimic how the shell does pathname expansion (when GLOB_NOCHECK is used). However, these changes may need tweaking in the light of bug http://austingroupbugs.net/view.php?id=1273. (In particular, should glob() always ignore ELOOP, ENAMETOOLONG, ENOENT and ENOTDIR like shells do?) Desired Action: On page 2384 line 76274 section 2.13.3, after:<blockquote>Each component that contains a pattern character shall require read permission in the directory containing that component. Any component, except the last, that does not contain a pattern character shall require search permission.</blockquote>add the sentence:<blockquote>If these permissions are denied, or if an attempt to open or search a directory fails because of an error condition that is related to file system contents, this shall not be considered an error and pathname expansion shall continue as if the directory had existed and had been successfully opened or searched, and no matching directory entries had been found in it.</blockquote> For OPTION1 also add the sentence:<blockquote>Other error conditions shall cause pathname expansion to fail.</blockquote> For OPTION2 also add the sentence:<blockquote>For other error conditions it is unspecified whether pathname expansion fails or they are treated the same as when permission is denied.</blockquote> Cross-volume changes to XRAT ... On page 3749 line 128728 section C.2.13.3, after:<blockquote>Historical systems have varied in their permissions requirements. To match <b>f*/bar</b> has required read permissions on the <b>f*</b> directories in the System V shell, but the Shell and Utilities volume of POSIX.1-2017, the C shell, and KornShell require only search permissions.</blockquote>add to the paragraph:<blockquote>If read or search permission is denied, shells do not report an error but treat this as a successful "no match" condition. Error conditions that are related to file system contents and occur when attempting to read or search a directory are also required to be treated the same way because they imply that there are no matches (that are accessible to the process). For example, if the pattern is <b>foo/*bar</b> and attempting to open the directory foo fails because it does not exist or is not a directory, then there can be no matching pathnames. The error conditions listed in [xref to XSH 2.3] that are related to file system contents and could occur when attempting to open or search a directory are [EACCES], [ELOOP], [ENAMETOOLONG], [ENOENT] and [ENOTDIR]. Error conditions that are not related to file system contents or which occur when reading a directory, notably [EMFILE] and [ENFILE] but also things like [EIO], [ENOMEM] and [EOVERFLOW],</blockquote> For OPTION1 also add:<blockquote>are treated as errors because to do otherwise would mean the shell could execute a command with an unchanged pattern when pathnames matching the pattern exist. Implementations which encounter non-standard error conditions should handle them appropriately according to whether or not they are related to file system contents.</blockquote> For OPTION2 also add:<blockquote>can either be treated as errors or be treated the same way as when permission is denied. Treating them as errors is seen as desirable, because to do otherwise would mean the shell could execute a command with an unchanged pattern when pathnames matching the pattern exist, but it is not historical practice. Implementations that handle the two categories of error differently should also handle non-standard error conditions appropriately, if encountered, depending on which category they fit into.</blockquote> Cross-volume changes to XSH ... On page 1109 line 37542 section glob(), change GLOB_ERR from:<blockquote>Cause <i>glob</i>() to return when it encounters a directory that it cannot open or read. Ordinarily, <i>glob</i>() continues to find matches.</blockquote>to:<blockquote>Cause <i>glob</i>() to return when an attempt to open, read or search a directory fails because of an error condition that is related to file system contents. If this flag is not set, <i>glob</i>() shall not treat such conditions as an error, and shall continue to look for matches.</blockquote> For OPTION2 also add:<blockquote>Other error conditions may also be treated the same way as error conditions that are related to file system contents.</blockquote> On page 1110 line 37568 section glob(), change:<blockquote>If, during the search, a directory is encountered that cannot be opened or read ...</blockquote>to:<blockquote>If, during the search, an attempt to open, read or search a directory fails ...</blockquote> On page 1110 line 37574 section glob(), change:<blockquote>If (*<i>errfunc</i>()) is called and returns non-zero, or if the GLOB_ERR flag is set in flags, <i>glob</i>() shall stop ...</blockquote>to:<blockquote>OPTION1: If (*<i>errfunc</i>()) is called and returns non-zero, or if <i>errfunc</i> is a null pointer and the attempt failed because of an error condition that is not related to file system contents, or if the GLOB_ERR flag is set in flags, <i>glob</i>() shall stop ... OPTION2: If (*<i>errfunc</i>()) is called and returns non-zero, or, optionally, if <i>errfunc</i> is a null pointer and the attempt failed because of an error condition that is not related to file system contents, or if the GLOB_ERR flag is set in flags, <i>glob</i>() shall stop ...</blockquote> On page 1111 line 37589 section glob(), change GLOB_ABORTED from:<blockquote>The scan was stopped because GLOB_ERR was set or (*<i>errfunc</i>()) returned non-zero.</blockquote>to:<blockquote>OPTION1: The scan was stopped because (*<i>errfunc</i>()) was called and returned non-zero, or errfunc was a null pointer and an attempt to open, read or search a directory failed because of an error condition that is not related to file system contents, or GLOB_ERR was set. OPTION2: The scan was stopped because (*<i>errfunc</i>()) was called and returned non-zero, or, optionally, errfunc was a null pointer and an attempt to open, read or search a directory failed because of an error condition that is not related to file system contents, or GLOB_ERR was set.</blockquote> After applying bug 1255, on page 1111 line 37604 section glob(), change:<pre> glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_ERR, NULL, &globbuf);</pre>to:<pre> glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK, NULL, &globbuf);</pre> After applying bug 1255, on page 1111 line 37612 section glob(), change:<pre> glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_ERR, NULL, &globbuf); glob("*.h", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_ERR|GLOB_APPEND, NULL, &globbuf);</pre>to:<pre> glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK, NULL, &globbuf); glob("*.h", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_APPEND, NULL, &globbuf);</pre> On page 1112 line 37630 section glob(), add a paragraph to APPLICATION USAGE:<blockquote>It is recommended that (*<i>errfunc</i>()) should always return a non-zero value if the <i>eerrno</i> parameter indicates an error condition that is not related to file system contents. See [xref to C.2.13.3] for information about which error conditions are related to file system contents.</blockquote> ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2019-07-30 10:17 geoffclare New Issue 2019-07-30 10:17 geoffclare Name => Geoff Clare 2019-07-30 10:17 geoffclare Organization => The Open Group 2019-07-30 10:17 geoffclare Section => 2.13.3 2019-07-30 10:17 geoffclare Page Number => 2384 2019-07-30 10:17 geoffclare Line Number => 76271 2019-07-30 10:17 geoffclare Interp Status => --- ======================================================================
