Bugs pertaining to pathname expansion and field splitting (when IFS is null), caused by use of literal space to separate words generated by "dollar at" expansions

[Stahlman Family]

This post is essentially a follow-up to a previous post, initially made just
before New Year's, which appears to have been overlooked. After making the
original post, I delved into the bash source to determine why I was seeing the
behavior described, and what I found convinced me that the behavior was not by
design, but was a bug. I posted my findings in a follow-up post, which also
appears to have been overlooked. In case the non-explicit subject line, or the
verbosity of the original and follow-up posts discouraged anyone from reading,
I'll try to summarize more concisely under a more explicit subject line...

I believe that multiple issues may be caused by the implementation's use of a
literal space character to separate words created by various forms of "dollar
at" expansions. My previous email describes two such issues in detail, but
there may well be others. The two issues I noticed may be summarized as
follows:

*** Issue #1 ***
When IFS is null, spaces embedded within the elements of array will result in
spurious word breaks when the ${array[@]/pattern/string} construct is expanded
outside of double quotes. (Same problem occurs for ${array[@]#pattern},
${array[@]%pattern}, and perhaps others...) Moreover, if the aforementioned
expansion occurs within a word containing other, non-dollar-at expansions
(e.g., ${param}${array[@]/pattern/string}), the other expansions are affected
as well. For details on the problem, see previous post:

"Re: Unexpected behavior observed when using ${parameter[@]/pattern/string}
construct"

Specifically, see text beginning with "After looking through the code, I
believe I now know why..."

Here's a shell command-line session demonstrating the problem...

# Inhibit field splitting
$ IFS=''

$ a=('word1 with spaces' 'word2 with spaces')  

# This one works as expected.
$ set - ${a[@]}

$ echo $#
2

# But not this one, which splits the original elements on the embedded spaces!!!
$ set - ${a[@]/word/element}

$ echo $#
6

*** Issue #2 ***
When IFS is null, pathname expansion is inhibited for the results of an array
expansion (e.g., ${array[@]}), which is not within double quotes. For details,
see the post referenced above, beginning with "For constructs for which
string_list_dollar_at is called (e.g., ${parameter[@]}), there is the opposite
problem..."

Here's a shell command-line session demonstrating the problem...

$ unset IFS

$ pat=('*.vim' '*.c')

# With default IFS, pathname expansion works as expected...
$ ls ${pat[@]}
f.c  f.vim  hello.c  junk.c  lookupfile.vim  menutest.vim  myecho.vim  np.c  
sess.vim  test.c

$ IFS=

# With IFS set to null, pathname expansion does not occur!!!
$ ls ${pat[@]}
ls: cannot access *.vim: No such file or directory
ls: cannot access *.c: No such file or directory

I'm hoping that someone familiar with the bash implementation can either
verify that these are indeed bugs, or let me know why not. If more information
is needed, please let me know...

Thanks,
Brett Stahlman