Op 07-08-2026 om 20:03 schreef Theo de Raadt:
> Let's try your approach by looking at the open(2) manual page.
> 
> DESCRIPTION
>       The file name specified by path is opened for reading and/or writing as
>       specified by the argument flags and the file descriptor returned to the
>       calling process.  The flags argument may indicate the file is to be
> 
> So shall we interpret that if we pass O_CREAT|O_WRONLY and then an error
> happens the file *MAY* have been created in the filesystem, but an error
> is returned?
> 
> Your opinion on ambiguity here is not correct.
[...]> And let me see, to open(2) we should add this text:
> 
>      In case of any error, the requested file is not created.
> 
> Right?


No, my argument is in fact the precise opposite of that. I say that close(2) 
should point out that, in case of any error, a valid file descriptor IS STILL 
closed in spite of that error.

Upthread, you termed this a non-ACID operation: "even when returning an error, 
it has performed a step". This is not obvious and should be documented.


> I think that's bullshit.  The first sentence was clear.


Yes, it is. Even so, in case of failure, the requested file is not opened, so 
that first sentence doesn't apply. This is clear and obvious, and there is no 
problem with the open(2) manual.

Whereas in close(2), in case of any error, the requested file is, in fact, 
closed. By your own arguments, the obvious reading of the manual would be that 
the job fails, so the file remains open. Which is wrong.

If you still cannot see the problem here, I don't know what to tell you. This 
is not a matter of opinion, nor is it difficult. It's a matter of basic logic.

I will admit, though, that I was merely being polite in allowing that the 
close(2) manual page might be ambiguous. It is unambiguously wrong.

And if neither the manual nor the behaviour have changed for 30 years, then 
the manual has been wrong for 30 years. Which would hardly be shocking. I've 
found and fixed shell bugs that are older than that.

As for why I'm not reading the kernel code of OpenBSD and every Unix under the 
sun: I have a life, and surely you don't actually mean to imply that the 
OpenBSD documentation shouldn't be relied on...?


[...]> And now I've hit my limit on interest in this area.


Indeed.

This is not the first time I've noticed this community being more interested 
in winning arguments by ad hominem fallacies and shouty appeals to authority, 
than in correct information and correct operation.

There was a time, about a decade ago, when you personally asked me to help fix 
shell bugs in the OpenBSD version of pdksh. I gave up when it became apparent 
the community is not actually interested in correct operation of the shell.

It's sad that nothing seems to have changed there. So I'll give up, again.


-- 
||	modernish -- harness the shell
||	https://github.com/modernish/modernish
||
||	KornShell lives!
||	https://github.com/ksh93/ksh