> > On a related note, why don't rm and rmdir have a --strip-trailing-slashes > > option? > > Because as far as I know, there is no need. > Do you know of a system where `rmdir symlink/' > removes only the referent of the symlink?
Yes, cygwin (but again, that goes back to the rmdir(2) bug in cygwin that I have just reported to the cygwin maintainers): $ mkdir a $ ln -s a b $ rmdir b/ $ ls -F a b ls: a: No such file or directory b@ Whereas on sane systems (for example, Solaris 8): $ mkdir a $ ln -s a b $ rmdir b/ rmdir: directory "b/": Path component not a directory $ rmdir b/. rmdir: directory "b/.": Can't remove current directory or .. By Paul's argument, both uses should have failed with EINVAL, since POSIX requires resolving "symlink/" as "symlink/.", and requires rmdir("symlink/." to fail with EINVAL. Solaris 8 returned ENOTDIR in the first case, so it appears they stripped the trailing slash (and their error message leaves something to be desired in accuracy in the second case). But at least it reliably failed instead of removing a. I don't have access to other systems to see what other behaviors might exist. > > Is it worth patching coreutils rm and rmdir to work around buggy > > systems that don't follow this POSIX restriction on rmdir()? (Meanwhile, > > I will try to get cygwin fixed.) Should we update the coreutils testsuite? > > It depends a whole lot on how invasive or complicated the patch is. > Ideally, it wouldn't change anything in src/*.c at all. If cygwin doesn't get patched, it sounds like a gnulib module to replace rmdir() is all that would be needed. Something like this untested snippet (it would need to be cleaned up for corner cases like "", "/", ".", but you get the picture): int rpl_rmdir(const char* name) { int len = strlen (name); if (name[len - 1] == '/' || (name[len - 1] == '.' && (name[len - 2] == '/' || (name[len - 2] == '.' && name[len - 3] == '/')))) { errno = EINVAL; return -1; } return rmdir (name); } -- Eric Blake _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils