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