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