Sourceware Bugzilla – Bug 866
glob should match dangling symlinks
Last modified: 2012-09-27 04:43:17 UTC
The 1.53 revision to sysdeps/generic/glob.c added a check for dangling symlinks.
While necessary for directory globs, it still seems desirable to match dangling
symlinks in filename globs, as bash and tcsh's built-in globbers do. This
program demonstrates the problem:
% cat globtest.c
glob("foo", 0, 0, &pglob);
for (i = 0; i < pglob.gl_pathc; i++)
printf("pglob.gl_pathv[%d] = \"%s\"\n", i, pglob.gl_pathv[i]);
% gcc -o globtest globtest.c
pglob.gl_pathv = "foo2"
Same thing in bash (tcsh behaves identically):
bash-2.05b$ cd /tmp
bash-2.05b$ ln -s /nope foo1
bash-2.05b$ ln -s /usr foo2
bash-2.05b$ echo foo
bash-2.05b$ rm foo1 foo2
I'm attaching a patch to glob.c that makes glob()'s behavior mimic bash and
tcsh's. The resulting glob() still passes globtest.sh, so it seems correct.
Created attachment 461 [details]
fix globbing of dangling symlinks in sysdeps/generic/glob.c
Adding another argument to glob_in_dir() was the easiest route, but perhaps one
of its existing arguments could be (ab)used instead.
This behavior is correct. There won't be any change.
Any chance of reconsidering this?
If you believe a bug was inappropriately closed, you need to reopen it, or
open a new bug for the same issue, preferably with detailed references to
the appropriate standards or other reasons you think the closure was
inappropriate. Comments on closed bugs don't make the bugs appear to
anyone subsequently doing bug triage.
This seems like yet another unexplained/unreasonable bug closure by Drepper. Can we please get a serious review of it. I think the fact that glob() is behaving differently from bash, and the fact that one expects "rm *" to remove everything including dangling symlinks, speaks for itself; POSIX does not have any special language about symlinks in the specification for glob, so by default I think it requires them to be included in the results.
Created attachment 6655 [details]
866-v2: updated patch that applies cleanly against master
Here's an updated version of Steven's patch that applies cleanly against the current master branch in case anybody wants to play with it.
Seems to work well, but I'm new here -- not sure what the policy is wrt tests?