#1 Bash builtins don't clear target array before assigning elements

[Tetsujin]

When using the socketpair or recvmsg builtins for Bash, array name arguments are not cleared when the command populates them:

$ s=(a b c)        # Some of these array elements will survive:
$ socketpair s
$ echo "${s[@]}"   # We expect just two numbers...
10 11 c
$ msg=(foo bar)
$ fds=(x y z)
$ sendmsg "hello" 2 >&${s[1]}
$ recvmsg msg fds <&${s[0]}
$ echo "${msg[@]}"
hello bar
$ echo "${fds[@]}"
12 y z

The behavior with respect to "msg" is arguably correct: setting $msg is equivalent to setting ${msg[0]}, and this is how read behaves. And since it is not an array argument, the caller is likely to just access $msg, meaning they won't see the other array elements either. However, I feel it is better to wipe out the whole array in this case: receiving a message in $msg should be equivalent to assigning to the variable, and assignment does wipe out the array if there is one.

The behavior with respect to the socket $s and the received file descriptor array $fds is undeniably wrong: after calling recvmsg a caller should be able to use ${#fds[@]} to see how many file descriptors they received, or ${fds[@]} to get all of them. Not clearing the variable before assigning array elements makes it harder to discern what is data from the command, and what is leftover junk from the variable's previous state.

Acceptance Criteria

• When array name arguments are provided to commands that use them, the variables should be cleared before new values are assigned. There should be no "leftover data" in the array after the command is run.
• When non-array variable name arguments are provided to commands that populate them, the variables should be cleared before new values are assigned, Although it somewhat contradicts the example set by read, I think this makes more sense.
• Correct behavior should be established for both ksh and bash: The same behavior should also apply to zsh when zsh support is implemented.
• Regression tests should be added to cover this behavior: All ticket fixes should include a regression test to demonstrate that the code works as expected, and to detect regression if it occurs.