A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1273 ====================================================================== Reported By: stephane Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1273 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Stephane Chazelas Organization: User Reference: Section: glob() Page Number: 1109, 1110 (in 2018 edition) Line Number: 35742, 35768 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2019-07-27 10:49 UTC Last Modified: 2019-07-28 06:44 UTC ====================================================================== Summary: glob()'s GLOB_ERR/errfunc and non-directory files ======================================================================
---------------------------------------------------------------------- (0004494) stephane (reporter) - 2019-07-28 06:44 http://austingroupbugs.net/view.php?id=1273#c4494 ---------------------------------------------------------------------- Re: http://austingroupbugs.net/view.php?id=1273#c4493 Yes, it's actually not clear how stat() is meant to be used here. I had assumed, lstat() was meant instead as in the ./*/file cases where implementations don't open the subdirs of ., but instead try lstat(./subdir/file) on each of them. But GLOB_ERR/errfunc being meant to report errors upon opening/reading *directories*, it can't report errors of lstat(). Maybe the spec wants implementations to call stat() on directories to check if they are searchable? If we step back from the implementation detail to look at what the intention of the interface should be: AFAICT a glob(*/*.c) should return the matching files and GLOB_ERR/errfunc should identify the problems that prevent us from doing so. /etc/passwd/*.c or non-existing/*.c doesn't match any file. The ENOTDIR/ENOENT failure upon trying to opening those non-directories is not an error preventing us from expanding the glob, it's on the contrary confirmation that the glob can't match. Where it becomes more ambiguous is when ELOOP/ENAMETOOLONG is returned (where the files may exist using a shortened path). FreeBSD's glob() does return errors in those cases which IMO sounds like the best thing to do. The real problem with the interface is that it doesn't allow reporting the lstat() errors in the */foo/bar/baz cases. Since errfunc only takes a path and errno arguments, calling it with a subdir/foo/bar/baz and EACCESS for instance could cause confusion and imply subdir/foo/bar/baz is a directory that cannot be read, while actually it's probably either subdir, subdir/foo or subdir/foo/bar that is not searchable. I'm not sure we want to force implementations to stat() those 3 directories just to report an error. Maybe we don't want to over-specify here and just say GLOB_ERR/errfunc should report the errors upon accessing directories (and directories or files assumed to be directories only) that prevent it from expanding the glob pattern without going into details of the implementation. And an application usage section clarifying that non-existing/*.c should not be reported as an error since the ENOENT failure of accessing the non-existing assumed-to-be-directory doesn't prevent us from expanding the glob, quite the contrary. Issue History Date Modified Username Field Change ====================================================================== 2019-07-27 10:49 stephane New Issue 2019-07-27 10:49 stephane Name => Stephane Chazelas 2019-07-27 10:49 stephane Section => glob() 2019-07-27 10:49 stephane Page Number => 1109, 1110 (in 2018 edition) 2019-07-27 10:49 stephane Line Number => 35742, 35768 2019-07-28 00:48 Don Cragun Interp Status => --- 2019-07-28 00:48 Don Cragun Category Shell and Utilities => System Interfaces 2019-07-28 01:42 shware_systems Note Added: 0004493 2019-07-28 06:44 stephane Note Added: 0004494 ======================================================================
