Christoph Anton Mitterer wrote, on 18 Jan 2025: > > On Tue, 2025-01-14 at 10:51 +0000, Geoff Clare via austin-group-l at > The Open Group wrote: > > I wonder whether perhaps Christoph was thinking that this wording: > > > > If any file descriptors with numbers greater than 2 are opened by > > those redirections, it is unspecified whether those file > > descriptors remain open when the shell invokes another utility. > > > > means that in this part of the command substitution: > > > > command exec 2>&1 >&3 3>&- > > > > "command" is "another utility" and so fd 3 could be closed when the > > shell executes "command", and thus it would not be open when > > "command" > > executes "exec", and the >&3 would fail. > > `command exec` is anyway a special case: > Are the redirections those of command or those of exec?
The standard requires (XCU 2.9.1) that the redirections are done (2.9.1.1) before the shell even works out whether "command" here is a function or the intrinsic utility (2.9.1.4). > From how `command` is defined for special built-ins, I'd say it's > effectively as if the redirections were on `exec` (just without the > special properties of 2.15 Special Built-In Utilities). > > And `exec` in turn is special to, since when no command name is given, > the redirections don't affect `exec` like another utility, but the > current shell execution environment. Actual implementations obviously need to be doing something more complex internally than the simple steps described in the standard in order for the end result of redirections performed with "command exec" and "exec" to be the same (when "command" is the intrinsic utility). The usual "as-if" rule applies. > So I was really mostly thinking about case like: > command exec 3<file; ... utility > > my example was just bad, in that utility didn't use/see the > 2 FD. Okay. Hopefully the discussion thus far has answered your original question in relation to that case. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
