On 6/9/14, 3:42 PM, Ian Kelling wrote: > > Running this script with your own bash path demonstrates the bug. > > #!/home/ian/opt/bash/bash --norc > shopt -s extglob > shopt -s dotglob > cd $(mktemp -d) > mkdir a > touch a/.b > touch a/c > echo a/!(.b) > > output: > a/. a/.. a/c > > this happens with all bash versions 4.3+ (latest is patch 18).
Yes, it's an interesting question: what exactly does pattern negation include? You can match all filenames beginning with a `.' by using `.' as the first character of the pattern, so should a negated pattern beginning with a `.' match all filenames beginning with a `.' that don't match that particular pattern? The bash-4.3 implementation says yes. (FWIW, ksh93 disagrees.) > before that, the output is: > > a/c Yes, bash-4.2 had real problems with pattern negation (all extglob patterns, really) and files beginning with `.'. So much so that it failed to generate any matches for *(.*), which is just totally wrong. > Another related bug. man bash states: > > The file names ``.'' and ``..'' are always ignored > when GLOBIGNORE is set and not null. > > Which clearly implies that . and .. should not be ignored in some other > case. Sure. One is that they're not ignored when the pattern begins with a `.'. For instance, using .* as the pattern with the above directory contents expands to ". .. .b c". > Well, that was not true before 4.3 Absolutely it was true before bash-4.3. , but I'm guess this new > behavior is a bug, and the doc is a bug, since the doc hasn't changed, > and setting GLOBIGNORE doesn't actually make . and .. be ignored. Of course it does. When GLOBIGNORE is set to something that's not a null value (say, GLOBIGNORE=a) , echo .* in a directory with the contents as above expands to ".b c", echo !(.*) expands to "c", and echo *(.*) expands to ".b". Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/