Shell Programming and Scripting

Yes, and no.

Code:

file=/home/Config.*

will set file to /home/Config.* (not /home/Config.txt and not /home/Config.xml).

After setting file=/home/Config.*, [ -f "$file" ] won't match either file, but [ -f $file ] (without quotes) would be OK until /home/Config.txt.bak or /home/Config.xml.bak is created and then you'd get syntax errors from the test command when the expansion of the unquoted $file expands to two filenames. And, the common commands to create a backup file:

Code:

cp $file $file.bak

and:

Code:

cp $file "$file.bak"

would create a file named Config.*.bak; not Config.txt.bak and not Config.xml.bak. And, the more commonly used:

Code:

cp "$file" "$file.bak"

would fail with a file not found error.

True, but wouldn't the restrictions apply for the {...,...} construct, too? It explains the error the user described in post#1.
I was thinking more when the shell expands the construct, like in echo ... or ls ..., so the assignment to a variable would need a command substitution like Don Cragun did in post#6, like file=$(echo /home/config.*)

Yes, it applies to file.{xml,txt} just as much as it does to file.*, file.[tx][xm][tl], or file.???.

The diagnostic shown in post #1 in this thread could be because pathname expansion does not occur during assignments (true in all shells as far as I know) or it could be because the shell the user is using does not recognize the syntax {element[,element]...} as a construct to be processed during pathname expansion (this syntax is an extension that is not defined by the standards). Since that post did not specify what shell is being used and did not show the command using $file (and whether or not it was enclosed in double quotes), we don't have enough information to know if:

Code:

file=$(echo /home/config.{xml,txt})

would work in that user's environment. All three of the suggestions I made in post #6 will work with any POSIX-conforming shell under the conditions specified by the OP (i.e., one and only one of the two desired files is present).