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 [EMAIL PROTECTED]/pattern/string} construct is
expanded
outside of double quotes. (Same problem occurs for [EMAIL PROTECTED],
[EMAIL PROTECTED], and perhaps others...) Moreover, if the aforementioned
expansion occurs within a word containing other, non-dollar-at expansions
(e.g., [EMAIL PROTECTED]/pattern/string}), the other expansions are affected
as well. For details on the problem, see previous post:
"Re: Unexpected behavior observed when using [EMAIL PROTECTED]/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 - [EMAIL PROTECTED]
$ echo $#
2
# But not this one, which splits the original elements on the embedded spaces!!!
$ set - [EMAIL PROTECTED]/word/element}
$ echo $#
6
*** Issue #2 ***
When IFS is null, pathname expansion is inhibited for the results of an array
expansion (e.g., [EMAIL PROTECTED]), 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., [EMAIL PROTECTED]), 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
