The function containing this code, may_access_filename(), is called directly when the program starts, and via the get_filename() function when running four other commands: e/E, f, r, and w/W (and by extension, wq). This addresses the "just one opportunity" part of Paul's last response (since it's called more-or-less from five code paths), and provides several possible rationales for the inclusion of the check (following on from Doug's point).
I personally think we're going around in circles until Antonio explains why the check is needed and what its intended meaning is. Doug's idea of trailing slashes glitching creat() seems reasonable, but we just don't know. I'll hold off on further comments for now. Alexander On Tue, Jan 13, 2026 at 8:10 AM Douglas McIlroy <[email protected]> wrote: > > > Although this issue is sounding more tempesty-in-a-teapotty with every > > passing email, I still fail to see why "./" should be treated > > differently from "." or "foo/..". They all must be directories, no? > > The trailing slash as an indicator of a directory is a convention of ls, not a > hard and fast property of the kernel. See the first line of the example below. > > > Only Antonio knows why he added that specific check, though he was making > > other changes to filename validation around that time. > > As my last message said, without the check, the following weird behavior > is possible.I suspect this is what motivated the check. > > *w FILE/ creat makes an ordinary file named FILE > *r FILE/ open fails with "Not a directory" > !ls FILE* > FILE > > The check exists in bash, too. I don't know whether one copied it from the > other. > > Doug > > On Tue, Jan 13, 2026 at 1:35 AM Paul Eggert <[email protected]> wrote: >> >> On 2026-01-12 16:40, Alexander Jones wrote: >> > If we agree that passing a filename to ed which is either empty or has >> > a trailing slash is inappropriate >> >> Although this issue is sounding more tempesty-in-a-teapotty with every >> passing email, I still fail to see why "./" should be treated >> differently from "." or "foo/..". They all must be directories, no? >> >> Another way to put it: if GNU ed wants to validate file names separately >> and independently of the kernel (though I still don't see why), >> shouldn't GNU ed do a complete job, consistently, with every file name >> it sees, rather than a halfhearted job at just one opportunity?
