Anonymous | Login | 2024-12-12 16:53 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001300 | [1003.1(2016/18)/Issue7+TC2] System Interfaces | Editorial | Clarification Requested | 2019-11-15 22:14 | 2024-06-11 09:08 | ||
Reporter | dmitry_goncharov | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Dmitry Goncharov | ||||||
Organization | |||||||
User Reference | |||||||
Section | glob | ||||||
Page Number | 1109 | ||||||
Line Number | 37544-37545 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | See Note: 0004692. | ||||||
Summary | 0001300: clarify GLOB_MARK behavior | ||||||
Description |
The current standard says "GLOB_MARK Each pathname that is a directory that matches pattern shall have a <slash> appended. Please clarify if a symlink to a directory should also have slash appended. I checked various implementations and they all append slashes to both directories and symlinks to directories. It makes sense to append a slash to symlinks to directories, because the user uses such symlinks as directory names. |
||||||
Desired Action |
Replace "Each pathname that is a directory that matches pattern shall have a <slash> appended." with "Each pathname that is a directory or a symlink to a directory that matches pattern shall have a <slash> appended." |
||||||
Tags | issue8 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
Notes | |
(0004658) Don Cragun (manager) 2019-11-15 22:40 edited on: 2019-11-15 22:42 |
0001300 and 0001301 are about the same topic, submitted by the same submitter, and appeared within minutes of each other. 0001301 provides more detail in the description of the problem. This bug is closed. |
(0004660) Don Cragun (manager) 2019-11-15 23:14 |
On closer examination, 0001300 and 0001301 ask different questions. This bug is reopened. |
(0004661) geoffclare (manager) 2019-11-18 15:47 |
The standard requires that symbolic links are always followed except where it explicitly states otherwise. See XBD 4.13 Pathname Resolution (the paragraph starting "If a symbolic link is encountered ...") Since there is no explicit statement in the description of glob() to say that it does not follow symbolic links when determining whether a pathname is a directory, the default rule from XBD 4.13 applies and glob() is therefore required to follow them; no change to the standard is needed. This bug should be rejected. |
(0004662) stephane (reporter) 2019-11-19 07:32 |
Still, since it's at odds with ls -p or the markdirs option of zsh, it wouldn't harm mentioning again in a non-normative section of the glob() spec. (completion listings of most shells (busybox, bash, ksh, Byron's rc, yash, fish at least) work like GLOB_MARK though. csh, tcsh and zsh use a @ suffix à la ls -F). In any case, the wording has a related slight problem: if the current directory is readable, but not searchable, for the expansion of *, an implementation cannot tell whether an entry is a symlink to a directory or to some other file. They may be able to tell if an entry is a directory or not if that information is stored in the directory (d_type of struct dirent returned by readdir() for instance). The "is a directory or a symlink to a directory" wording is ambiguous for files that are a symlink to symlink to a directory. So it should probably be something like: "Each pathname that matches pattern and that is determined to be a directory after symlink resolution shall have a <slash> appended." (whether the inability to "mark" a directory should be flagged as an error with GLOB_ERR was mentioned on the ML or a different bug not too long ago IIRC, but I don't remember the outcome). |
(0004692) Don Cragun (manager) 2019-12-19 17:36 edited on: 2019-12-20 10:06 |
Note that the changes specified below address the issues raised in this bug report and in 0001301. Interpretation response ------------------------ The standard states "Each pathname that is a directory that matches pattern shall have a <slash> appended.", and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- Requiring the pathname "/" to be converted to "//" and the pathname "//" to be converted to "///" was not considered when this issue was first standardized. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 1109 line 37544 section glob(), change: Each pathname that is a directory that matches pattern shall have a <slash> appended.to: For each pathname that matches pattern and is determined to be a directory after pathname resolution, process the pathname so the result is as if the following steps are applied in order: Append the following new paragraphs to the glob() rationale after P1112, L37648: Earlier versions of this standard defined the behavior associated with the flag GLOB_MARK as: |
(0004710) ajosey (manager) 2020-01-07 13:37 |
Interpretation proposed: 7 January 2020 |
(0004784) ajosey (manager) 2020-02-19 17:26 |
Interpretation approved: 19 Feb 2020 |
(0004857) geoffclare (manager) 2020-05-05 14:51 |
When applying this bug it occurred to me that the uses of "shall" in the rationale were a problem. I therefore used quotation marks instead of indentation, so that the uses of "shall" are contained in quotations of (what would be) normative text. |
Issue History | |||
Date Modified | Username | Field | Change |
2019-11-15 22:14 | dmitry_goncharov | New Issue | |
2019-11-15 22:14 | dmitry_goncharov | Name | => Dmitry Goncharov |
2019-11-15 22:14 | dmitry_goncharov | Section | => glob |
2019-11-15 22:36 | Don Cragun | Relationship added | duplicate of 0001301 |
2019-11-15 22:40 | Don Cragun | Note Added: 0004658 | |
2019-11-15 22:40 | Don Cragun | Status | New => Closed |
2019-11-15 22:40 | Don Cragun | Resolution | Open => Duplicate |
2019-11-15 22:42 | Don Cragun | Note Edited: 0004658 | |
2019-11-15 23:13 | Don Cragun | Relationship deleted | 0001301 |
2019-11-15 23:14 | Don Cragun | Note Added: 0004660 | |
2019-11-15 23:14 | Don Cragun | Status | Closed => New |
2019-11-15 23:14 | Don Cragun | Resolution | Duplicate => Open |
2019-11-15 23:16 | Don Cragun | Relationship added | related to 0001301 |
2019-11-18 15:47 | geoffclare | Note Added: 0004661 | |
2019-11-19 07:32 | stephane | Note Added: 0004662 | |
2019-12-19 17:36 | Don Cragun | Note Added: 0004692 | |
2019-12-19 17:38 | Don Cragun | Note Edited: 0004692 | |
2019-12-19 17:39 | Don Cragun | Status | New => Resolved |
2019-12-19 17:39 | Don Cragun | Resolution | Open => Accepted As Marked |
2019-12-19 17:39 | Don Cragun | Tag Attached: issue8 | |
2019-12-19 17:45 | Don Cragun | Project | Online Pubs => 1003.1(2016/18)/Issue7+TC2 |
2019-12-19 17:46 | Don Cragun | Page Number | => (page or range of pages) |
2019-12-19 17:46 | Don Cragun | Line Number | => (Line or range of lines) |
2019-12-19 17:46 | Don Cragun | Interp Status | => --- |
2019-12-19 17:46 | Don Cragun | Final Accepted Text | => See Note: 0004692. |
2019-12-19 18:01 | Don Cragun | Page Number | (page or range of pages) => 1109 |
2019-12-19 18:01 | Don Cragun | Line Number | (Line or range of lines) => 37544-37545 |
2019-12-19 18:01 | Don Cragun | Category | Base Definitions => System Interfaces |
2019-12-19 18:15 | Don Cragun | Note Edited: 0004692 | |
2019-12-19 18:16 | Don Cragun | Interp Status | --- => Pending |
2019-12-19 18:16 | Don Cragun | Status | Resolved => Interpretation Required |
2019-12-20 10:06 | Don Cragun | Note Edited: 0004692 | |
2020-01-07 13:37 | ajosey | Interp Status | Pending => Proposed |
2020-01-07 13:37 | ajosey | Note Added: 0004710 | |
2020-02-19 17:26 | ajosey | Interp Status | Proposed => Approved |
2020-02-19 17:26 | ajosey | Note Added: 0004784 | |
2020-05-05 14:51 | geoffclare | Note Added: 0004857 | |
2020-05-05 14:51 | geoffclare | Status | Interpretation Required => Applied |
2024-06-11 09:08 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |