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-26 08:23 UTC ====================================================================== Summary: claifications/improvements around command/exec and special built-in redirection errors ======================================================================
---------------------------------------------------------------------- (0006970) larryv (reporter) - 2024-11-26 08:23 https://austingroupbugs.net/view.php?id=1879#c6970 ---------------------------------------------------------------------- <blockquote>1) I assume a redirection error in plain exec in a non-interactive shell is still intended to cause the shell to abort/exit with an error (IIRC, bash doesn't do this).</blockquote>It does in POSIX mode.<blockquote>Perhaps simply like: > If a redirection error occurs, the exit status > shall be a value in the range 1-125 with the > consequences given in 2.8.1 Consequences of Shell Errors.</blockquote>How is this any better than the current text, which already has that xref? You're just moving the xref around.<blockquote> ( command exec 2>/dev/null </does-not-exist/file || exit 100; grep foo ) does seem to work (and I guess the latter should work portably), they'd have of course the downside of also swallowing any stderr from grep. Interestingly, this is also caused by the upper "solution": $ dash -c '( { command exec </does-not-exist/file || exit 100; } 2>/dev/null; grep --sdsd foo )' ; echo $? 100</blockquote>What do you mean? The <i>grep</i> command never runs here. If it does, the error message is printed fine.<pre>% dash -c '( { command exec </dev/null || exit 100; } 2>/dev/null; grep --sdsd foo )' ; echo $? grep: unrecognized option `--sdsd' usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]] [-e pattern] [-f file] [--binary-files=value] [--color=when] [--context[=num]] [--directories=action] [--label] [--line-buffered] [--null] [pattern] [file ...] 2</pre> 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 ======================================================================
