On 16/03/20 14:37, Robert Elz wrote:
Date: Sun, 15 Mar 2020 14:44:51 +0000 From: Dirk Fieldhouse <fieldho...@gmx.net> Message-ID: <55e0c45a-f13c-fa1d-db22-4c0a1b02d...@gmx.net>...> You need to read the whole standard to understand it, you cannot simply read one section here and there and expect that to make sense. It is not a tutorial, not even an advanced user manual.
Except when it is: <https://launchpad.net/ubuntu/+source/manpages-posix> From the standard's Introduction: "The intended audience for POSIX.1-2017 is all persons concerned with an industry-wide standard operating system based on the UNIX system. This includes at least four groups of people: - Persons buying hardware and software systems - Persons managing companies that are deciding on future corporate computing directions - Persons implementing operating systems, and especially - Persons developing applications where portability is an objective" I have been in or advised or acted for all of these groups, especially the final "especially" group. I read standards for breakfast, or at least shortly afterwards. Compared with something like the ISO MPEG series, POSIX is a light read. As someone who has written and maintained plenty of shell scripts, the EXIT trap is one area that I hadn't really exercised. A programmer who relied on 'man dash' or 'man ksh' could be completely unaware of this feature; 'man bash' does mention it in a simple description of 'exit' that doesn't attempt to deal with execution environments. And certainly the DESCRIPTIONs of 'exit' and 'trap' are the only sections of the standard that cover it. So it would be fair to say that these sections provide the only good documentation of the feature.
| -- which the standard contrasts with | "otherwise, the shell utility shall terminate...". I have no idea what the "contrasts" is there.
You did once you'd read my response to Harald.
... | Should the standard say instead that the trap is executed "before the | shell exits from the current execution environment," It could say that, rather than "terminates", but the effect is the same ... If anything were to change, it would be better to say "before the current execution environment terminates" - the reason for "terminate" rather than "exit" is that this is the description of the exit command. If we just say (in more words) "exit causes the shell to exit" it looks kind of like a circular definition "x does x" - which is not very illuminating. Hence "terminate" as the action for the exit command.
Definitely +1 for "before the current execution environment terminates" or even "before the shell leaves the current execution environment", or "before leaving the current execution environment".
... it is really difficult to believe that any of this part can possibly be misinterpreted. And no, I don't believe that the wording that you quoted in your reply to Harald is in any real way confusing.
The meaning ought to be obvious to someone who doesn't have a portfolio of shell source codes and binaries to help resolve ambiguity. If I hadn't already seen the results that you presented using such resources, I would have gone with what I said the text "appears to require", and I'd have tested that if were writing a test suite.
The issues that arose (the can of worms) are what is to happen when a subshell execution environment (in a function) ends because of a return command - all shells have the execution environment end when that happens, but a couple don't run the exit trap. Since currently that return gives unspecified results, it would be plausible (if a little bizarre) for those shells to claim that their unspecified result is to exit without running an exit trap.
Sure, but to be sure of triggering an EXIT trap in a POSIX-conformant shell the programmer could have used 'exit' instead of 'return'. Doctor, when I hit my hand with the hammer it hurts: what should I do?
If we were to update the standard to specify that a return command in a subshell in a function causes the subshell to exit, then we need to be clear what happens with exit traps.
Which could be seen as a reason to let that whole aspect remain in limbo? /df -- London SW6 UK
