|Anonymous | Login||2023-12-06 14:45 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001275||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Objection||Error||2019-07-30 10:17||2023-08-10 15:11|
|Priority||normal||Resolution||Accepted As Marked|
|Organization||The Open Group|
|Final Accepted Text||See Note: 0005884.|
|Summary||0001275: pathname expansion errors|
In the description of patterns used for pathname expansion, the standard
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.However, it does not say what should happen if these permissions are
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 0001273.
(In particular, should glob() always ignore ELOOP, ENAMETOOLONG, ENOENT
and ENOTDIR like shells do?)
On page 2384 line 76274 section 2.13.3, after:
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.add the sentence:
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.
For OPTION1 also add the sentence:
Other error conditions shall cause pathname expansion to fail.
For OPTION2 also add the sentence:
For other error conditions it is unspecified whether pathname expansion fails or they are treated the same as when permission is denied.
Cross-volume changes to XRAT ...
On page 3749 line 128728 section C.2.13.3, after:
Historical systems have varied in their permissions requirements. To match f*/bar has required read permissions on the f* 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.add to the paragraph:
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 foo/*bar 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],
For OPTION1 also add:
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.
For OPTION2 also add:
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.
Cross-volume changes to XSH ...
On page 1109 line 37542 section glob(), change GLOB_ERR from:
Cause glob() to return when it encounters a directory that it cannot open or read. Ordinarily, glob() continues to find matches.to:
Cause glob() 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, glob() shall not treat such conditions as an error, and shall continue to look for matches.
For OPTION2 also add:
Other error conditions may also be treated the same way as error conditions that are related to file system contents.
On page 1110 line 37568 section glob(), change:
If, during the search, a directory is encountered that cannot be opened or read ...to:
If, during the search, an attempt to open, read or search a directory fails ...
On page 1110 line 37574 section glob(), change:
If (*errfunc()) is called and returns non-zero, or if the GLOB_ERR flag is set in flags, glob() shall stop ...to:
OPTION1: If (*errfunc()) is called and returns non-zero, or if errfunc 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, glob() shall stop ...
On page 1111 line 37589 section glob(), change GLOB_ABORTED from:
The scan was stopped because GLOB_ERR was set or (*errfunc()) returned non-zero.to:
OPTION1: The scan was stopped because (*errfunc()) 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.
After applying bug 1255, on page 1111 line 37604 section glob(), change:
glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_ERR, NULL, &globbuf);to:
glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK, NULL, &globbuf);
After applying bug 1255, on page 1111 line 37612 section glob(), change:
glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_ERR, NULL, &globbuf); glob("*.h", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_ERR|GLOB_APPEND, NULL, &globbuf);to:
glob("*.c", GLOB_DOOFFS|GLOB_NOCHECK, NULL, &globbuf); glob("*.h", GLOB_DOOFFS|GLOB_NOCHECK|GLOB_APPEND, NULL, &globbuf);
On page 1112 line 37630 section glob(), add a paragraph to APPLICATION USAGE:
It is recommended that (*errfunc()) should always return a non-zero value if the eerrno 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.
|While I personally agree with option 1 if we were designing from scratch, I feel that it represents enough invention when compared to existing practice that we are better off using option 2 rather than forcing every shell out there to comply with new requirements.|
Don Cragun (manager)
edited on: 2022-07-11 16:15
Make the changes in the Desired Action to implement option 2.
|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||=> ---|
|2019-07-30 10:19||geoffclare||Relationship added||related to 0001273|
|2019-07-30 14:31||eblake||Note Added: 0004502|
|2021-12-21 22:21||dennisw||Issue Monitored: dennisw|
|2022-07-11 16:13||Don Cragun||Note Added: 0005884|
|2022-07-11 16:14||Don Cragun||Final Accepted Text||=> See Note: 0005884.|
|2022-07-11 16:14||Don Cragun||Status||New => Resolved|
|2022-07-11 16:14||Don Cragun||Resolution||Open => Accepted As Marked|
|2022-07-11 16:15||Don Cragun||Tag Attached: tc3-2008|
|2022-07-11 16:15||Don Cragun||Note Edited: 0005884|
|2022-08-05 09:22||geoffclare||Status||Resolved => Applied|
|2023-08-10 15:11||eblake||Relationship added||related to 0001228|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|