A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1876 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1876 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: 2.15 Special Built-In Utilities Page Number: 2554 Line Number: 83295, ff. Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-11-18 23:54 UTC Last Modified: 2024-11-19 16:14 UTC ====================================================================== Summary: clarify, whether a trap action that is executed from a context where set -e is ignored, would have set -e ignored, too ======================================================================
---------------------------------------------------------------------- (0006966) geoffclare (manager) - 2024-11-19 16:14 https://austingroupbugs.net/view.php?id=1876#c6966 ---------------------------------------------------------------------- > Well it doesn't specifically say that it's about the *whole* command 2.11 Job Control says:<blockquote>For a list consisting of one or more sequentially executed AND-OR lists followed by at most one asynchronous AND-OR list, the whole list shall form a single foreground job up until the sequentially executed AND-OR lists have all completed execution, at which point the asynchronous AND-OR list (if any) shall form a background job as described above.</blockquote> Admittedly that's "foreground job" not "foreground command" (which isn't a defined term), and job control isn't enabled in the test script, but if the behaviour changed with job control enabled, that would be very surprising. > neither dash nor bash print end after Ctrl-C. That looks like a bug (or at least a non-conformance) in dash and bash. Ksh (all versions - 88, old 93, 93u+m) does print "end". However, it also prints "b" (meaning set -e is suppressed) so doesn't conform to my interpretation of the requirements for set -e. Looks like this is one to raise with the various shell authors to get their input. Issue History Date Modified Username Field Change ====================================================================== 2024-11-18 23:54 calestyo New Issue 2024-11-18 23:54 calestyo Name => Christoph Anton Mitterer 2024-11-18 23:54 calestyo Section => 2.15 Special Built-In Utilities 2024-11-18 23:54 calestyo Page Number => 2554 2024-11-18 23:54 calestyo Line Number => 83295, ff. 2024-11-19 10:45 geoffclare Note Added: 0006962 2024-11-19 15:42 calestyo Note Added: 0006964 2024-11-19 16:13 oguzismailuysalNote Added: 0006965 2024-11-19 16:14 geoffclare Note Added: 0006966 ======================================================================
