Gold star (or ++ points in monk-speak :-)).
I wondered about that semicolon and the order of processing things -- my only concern (in some 'general' case, not my particular problem) about using "\n" might be portability to a platform where "\n" wasn't the line delimiter.... I should have just "tried it".

I too am minorly surprised that '/bin/sh' allows the the non-posix extensions... Definitely not something to rely on...

Another solution that I ran across was to use bash as a 'filter' of sorts:

$pat='+([^-])-+([^-]).rpm';
$a=`echo 'echo gcc-$pat'|bash -O extglob`;  #-O=capital 'O'
[download]

It sorta *bums* me that 'semicolon' isn't equivalent to '\n' in this case. There might be a bug there, somehow: if "shopt cmdhist"=on, then bash tries to store multiline commands in one history entry. Then, if "shopt lithist" is off (I think that's default), then bash will store multi-line commands separated by a semicolon (instead of the newline which would have separated the commands of the multi-line command). As you point out, this isn't equivalent to separation by a newline.

It would be a rare error case, but if one concocted a multi-line command that turned on 'extglob'bing, followed by its usage, then that multi-line command sequence would be stored with semi-colons, so on recall, it would contain the non-working semi's instead of the requisite newlines... (and people wonder how it is that I so often break things...:-) )
L