Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001275 [1003.1(2016)/Issue7+TC2] Shell and Utilities Objection Error 2019-07-30 10:17 2019-07-30 14:31
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
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
Summary 0001275: pathname expansion errors
Description In the description of patterns used for pathname expansion, the standard
states:
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
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 0001273.
(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:
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 ...

OPTION2: If (*errfunc()) is called and returns non-zero, or, optionally, 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.

OPTION2: The scan was stopped because (*errfunc()) 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.

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.
Tags No tags attached.
Attached Files

- Relationships
related to 0001273New glob()'s GLOB_ERR/errfunc and non-directory files 

-  Notes
(0004502)
eblake (manager)
2019-07-30 14:31

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.

- 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 => ---
2019-07-30 10:19 geoffclare Relationship added related to 0001273
2019-07-30 14:31 eblake Note Added: 0004502


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker