fds above 9 and internal fds

[Stephane Chazelas]

After:

{
  exec 10>&1
  ...
} > /some/file

stdout stays connected to /some/file

I guess it's because the fd 10 is used internally to save
stdout.

{
...
} > /some/file

does a dup(1, 10) # save stdout on fd 10 and then
dup(open(/some/file, 1) # set stdout to /some/file

exec 10>&1 

does a dup(1, 10) # now, fd 10 is not a backup of stdout anymore
and the old stdout is definitely lost.

Then, when bash restores stdout (dup(10, 1)), it actually sets
"/some/file" to stdout.

Maybe there should be reserved fds for bash internal use or only
allow fds 0 to 9 on the LHS of redirections as in other
Bourne-like shells. Or maybe document that it's dangerous (and
not portable) to use fds above 9. Another way would be to save
all the internally used fds when they are used by the user.

-- 
Stephane