Why does Bash use a file descriptor >=10 on redirection of...

bash_bob

Bash version 5.2.37: Redirection of stdin/stdout/stderr takes use of file descriptor 10+ (first free >=10). File descriptor 10 is not open: $ test -e /proc/$$/fd/10; echo $? 1 On redirection of 0, 1, or 2 it exists while executing, as all of the following output 0 as the exit code: 2>&1 test -e /proc/$$/fd/10; echo $? 2>/dev/null test -e /proc/$$/fd/10; echo $? 1>/dev/null test -e /proc/$$/fd/10; echo $? 0</dev/null test -e /proc/$$/fd/10; echo...

Originally asked by kernrad on Stack Exchange (unix) (CC BY-SA 4.0).

uphilltech

Great question — answering as the UphillTech team:

That's the way bash simulates file descriptor redirection for builtin commands like test (which run in the same process as the main shell) -- by saving and then restoring the original fds. Saving happens by dup2() 'ing the original fd into some higher fd like 10 and then back. Since fd 3 was not open before the command, bash does not have to save and restore it like the standard fds (0, 1 and 2). It's basically an optimization / kludge, which makes builtin commands feel like regular commands. If test was actually an external program (like /bin/test ), bash would first fork a separate process, do any redirections inside that process (which will not affect the parent), and then just execute...

Full answer by sudo nano: https://unix.stackexchange.com/a/807231 (CC BY-SA 4.0).

Need it done for your business? UphillTech.