Austin Group Defect Tracker

Aardvark Mark IV


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 2020-05-05 14:51
Reporter dmitry_goncharov View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
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
related to 0001301Resolved clarify glob("/", GLOB_MARK, ...) behavior 

-  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:

         
  1. If the pathame is <slash>, do not modify the pathname and skip the remaining steps.

  2.      
  3. If the pathname is <slash><slash> and the implementation handles pathname resolution of a pathname starting with exactly two successive <slash> characters differently than it handles a pathname starting with only a single <slash>, do not modify the pathname and skip the remaining steps.

  4.      
  5. If the pathname does not end with a <slash>, append a <slash> to the pathname and skip the remaining steps.

  6.      
  7. A <slash> may be appended to the pathname.

  8.      
  9. If there are multiple <slash> characters at the end of the pathname, all but one of those trailing <slash> characters may be removed from the pathname.


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:
        
Each pathname that is a directory that matches pattern shall have a <slash> appended.

This was undesirable if the matched pathname was <slash> or if the matched pathname was <slash><slash> and the implementation treats a leading <slash><slash> differently than it treats a pathname with a single leading <slash>. Only a few implementations were known to conform to this requirement (maybe only one) and there was a lot of variation in the way other implementations behaved. The current wording allows many of the alternative behaviors that were observed, except that the pathnames "/" and "//" (if it is treated differently than "/") must not be modified.

Implementations should consider the following much simpler requirement (which is allowed by the current standard) when processing the GLOB_MARK flag:
        

Each pathname that matches pattern, is determined to be a directory after pathname resolution, and does not end with a <slash> shall have a <slash> appended.


(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


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