>
> The zsh manual is not rigorously enough written to be treated as a
> "specification" and would become even less readable than Ray already
> accuses it of being if we tried.  I'd prefer to give a summary and
> then reference the POSIX spec for details (but not via URL-link to it;
> URLs tend to get stale).


My proposed doc update covers most points. So much so that I didn't even
feel the need to link to the POSIX doc. So no URL-link problem :-)

Shouldn't docs of ERR_EXIT explicitly mention that «! true» does not
> cause an exit?


This is implicitly covered by my proposed update.

Philippe




On Sun, Dec 11, 2022 at 2:24 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Sat, Dec 10, 2022 at 6:12 AM Philippe Altherr
> <philippe.altherr@gmail.com> wrote:
> >
> > POSIX' "set -e" specification. That specification is quite a bit longer.
> Should Zsh's specification repeat all of that? Or should it link to it?
>
> The zsh manual is not rigorously enough written to be treated as a
> "specification" and would become even less readable than Ray already
> accuses it of being if we tried.  I'd prefer to give a summary and
> then reference the POSIX spec for details (but not via URL-link to it;
> URLs tend to get stale).
>
> Aside, Martijn Dekker raised a related question back in workers/43874
> -- according to the POSIX chapter on Utilities
> (
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
> )
> there are a bunch of circumstances where a non-interactive shell is
> required to exit "as if the exit builtin were called".  With ERR_EXIT,
> interactive shells are also required to exit in those circumstances.
> I'm pretty sure, though haven't re-tested, that zsh does not in fact
> exit in some of those (such as a redirection error with a special
> builtin) and in some of the cases where it does exit, it does not run
> the SIGEXIT trap as implied by "as if the exit builtin" (that being
> the actual reason for Martijn's message).
>
> And yes, I used a URL that might become stale, in this message.
> Nobody is ever going to need or to be able to go through the archives
> and fix that, whereas documentation would be expected to be kept up to
> date, a burden I don't wish to impose.
>