A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1879 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1879 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: Shell Command Language Page Number: various Line Number: various Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-11-26 04:30 UTC Last Modified: 2024-11-30 05:14 UTC ====================================================================== Summary: claifications/improvements around command/exec and special built-in redirection errors ======================================================================
---------------------------------------------------------------------- (0006978) calestyo (reporter) - 2024-11-30 05:14 https://austingroupbugs.net/view.php?id=1879#c6978 ---------------------------------------------------------------------- > Looks like Note: 0006973 got truncated. Indeed. Strange. But IIRC, in the missing part I merely brought up again, that to even in that case it wouldn't be clear to me whether or not exec <does-not-exist || echo foo, would cause foo to be printed. @geoffclare As for my original point (1), with which your proposed changed on page 2539 line 82804 deals with: I can live with that, though would personally think that the parentheses should rather go behind the "the shell does not exit" because 2.8.1 is where it's explained when it exits, isn't it? Also is it still clear by that, that in the case of the shell exiting (because of 2.8.1), the exit status is *also* in 1-125? Cause that used to be the definition in the 2018 edition. But with the proposed wording, one could argue that if it has an exit status (and the shell does not exit), it's between 1-125, while when the exits because of 2.8.1 the exit status (of the shell) is, AFAIU, defined to be... well actually only for the case of a subshell it says "exit from the subshell environment with a non-zero status"... which would be more than just the 1-125. As for my point (2b) and your proposed changes on page 2498 line 81135: So command special-built-in is indeed expected to also prevent the shell from aborting because of any redirection errors, right? And thus command exec <redirection> *is* the only portable way to differ the utility exit status from "redirection exit statuses". As for my point (2a) and your proposed changes on page 2526 line 82346 section 2.15 Special Built-In Utilities: Fine with that. The only thing I'd ask to consider: Is it necessary to explicitly mention for `command`, that in `command exec <redirections>` the redirections are on `exec` not on command. Or rather, because of: > In every other respect, if command_name is not the name > of a function, the effect of command (with no options) > shall be the same as omitting command,... I'd say that this is even the case for any command_name of the `command`-utility, which has "Stdin Not used." but does have a "Stdout" defined, though only for the -v -V cases. IMO, I'd say because of the sentence I've quoted above, no special explanation is needed... but maybe I'm wrong. As for my point (3) and your comment in #0006977: But, for `grep` in specific, this would only mean that one cannot differentiate between possible different error statuses, while one can differentiate between the "success statuses" 0 and 1 and an error condition. Also, `grep` was just an example of mine, which I chose because for it the exit status 1 is not really an error. There may be plenty of (non-POSIX) programs, for which it's known that e.g. all errors are exit status 2 or whatever. So I'd still say that such example would be useful (perhaps not with `grep` but `utility`, of course with the information, that the application must ensure that that whichever chosen exit status that indicates the redirection error is not used y the utility. Anyway, was just a proposal. Issue History Date Modified Username Field Change ====================================================================== 2024-11-26 04:30 calestyo New Issue 2024-11-26 04:30 calestyo Name => Christoph Anton Mitterer 2024-11-26 04:30 calestyo Section => Shell Command Language 2024-11-26 04:30 calestyo Page Number => various 2024-11-26 04:30 calestyo Line Number => various 2024-11-26 08:23 larryv Note Added: 0006970 2024-11-26 08:26 larryv Note Edited: 0006970 2024-11-26 08:27 larryv Note Edited: 0006970 2024-11-26 18:48 calestyo Note Added: 0006971 2024-11-27 07:19 larryv Note Added: 0006972 2024-11-27 20:47 calestyo Note Added: 0006973 2024-11-27 22:57 larryv Note Added: 0006974 2024-11-28 16:21 geoffclare Note Added: 0006975 2024-11-28 16:23 geoffclare Note Edited: 0006975 2024-11-28 16:45 geoffclare Note Added: 0006976 2024-11-28 16:49 geoffclare Note Added: 0006977 2024-11-28 16:51 geoffclare Note Edited: 0006977 2024-11-30 05:14 calestyo Note Added: 0006978 ======================================================================
