All, To be clear, I don't disagree with fixing the bug. I only disagree with Paul's proposed solution of removing the offending check altogether.
To my surprise, I could not find any message on this mailing list describing the original rationale for checking filenames for trailing slashes. It was added in version 1.20-pre3 [1], without apparent additional comment, or any message from users suggesting the change. I also couldn't find an obvious analogue in earlier code. Only Antonio knows why he added that specific check, though he was making other changes to filename validation around that time. If we agree that passing a filename to ed which is either empty or has a trailing slash is inappropriate, simply changing the error message to "Invalid filename" (or "Improper filename", as Douglas suggests; the precise wording can be chosen by Antonio) is likely the most expedient solution. Alexander [1] https://lists.gnu.org/archive/html/bug-ed/2023-11/msg00032.html On Mon, Jan 12, 2026 at 4:22 PM Douglas McIlroy <[email protected]> wrote: > > I agree that my bug report is low priority, and would accept > a decision that it doesn't merit repair. However, I don't > buy suggestions that fixing it could be counterproductive. > > The easiest repair of all would be to change the wording so it > doesn't mimic a perror diagnostic, e.g. "Improper filename". > > It is wise to keep the check. without the check, this confusing > confusing scenario can arise. > *w FILE/ creates FILE (no "/") > *r FILE/ fails with "Not a directory" > !ls FILE* > FILE > > > First, red (restricted ed) will still > > give its own diagnostic for the example argument: > > > > FILE/: Directory access restricted > > > > This diagnostic cannot be removed, as red is designed not to have > > access to other directories. > > Fair enough, assuming that's that's the diagnostic for any directory name > regardless of whether it exists. > > > > Secondly, the function being modified is invoked by several ed > > commands, including the "f" command, which does no immediate I/O and > > thus will not trigger any warning of its own at all with the patched > > code and given example: > > > > *f FILE/ > > FILE/ > > Ed does not normally object to associating its buffer with a directory name. > This example yields no warning until it matters: > > *f . > . > > > > Thirdly, once a file is written with the example filename, errno is > > still set in such a way as to display basically the same diagnostic as > > before: > > > > *w > > FILE/: Is a directory > > ? > > *h > > Cannot open output file > > Yes, we have a coverup. By conflating EACCESS with EISDIR, ed hides the > evidence that this occurrence of "Is a directory" is a lie. > > It's also bad human engineering to break from the uniform meaning of the > perror diagnostic across thousands of programs. > > That said, it turns out that bash exhibits the same lie. Maybe Chet Ramey > should be in on this discussion. > > On Mon, Jan 12, 2026 at 1:46 AM Paul Eggert <[email protected]> wrote: >> >> On 2026-01-11 21:24, [email protected] wrote: >> > Weren't directories readable in the old (e.g. version 6 or 7 Bell Labs >> > Unix) days >> >> Yes, and POSIX still allows that behavior. However, I don't know of any >> current platforms that still do that. And if there are any, that's OK: >> "ed" doesn't need to do anything special for these oddball platforms.
