Bug#428444: rmdir -p ./foo literally tries to rmdir .
Joey Hess [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~mkdir foo [EMAIL PROTECTED]:~rmdir -p ./foo rmdir: .: Invalid argument zsh: exit 1 rmdir -p ./foo Since . is never a valid argument to rmdir(), why does rmdir try to do that? Because there is an implicit user request to do so. Similar to why rmdir . always fails. Consider a script that gets input from the user about what directory to act on, and wants to rmdir it at the end. The current behavior of rmdir forces each such script to check the user's input to avoid calling rmdir with a path name starting with ./. I think it would be better for rmdir -p to simply ignore the ./ and not try to literally rmdir(.) in this case. Thanks for the suggestion. As you probably know, even the latest rmdir (in coreutils-6.9 and in version control) acts the same way. However, it's not clear to me that (and if so, how) this should change. Making rmdir -p ignore just a leading ./ is seductive, but what about other . components? For example, should all of these continue to fail? rmdir -p a/./b rmdir -p a/./ rmdir -p . And what if there is more than one leading ./? rmdir -p ././foo And what if there are _only_ ./ components? rmdir -p ./././ If mkdir -p treats ./ specially, then should it do the same for a leading ../ component? Probably not, but you can make the same argument, since rmdir(..) must always fail. Also, POSIX requires the current behavior. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428444: rmdir -p ./foo literally tries to rmdir .
Jim Meyering wrote: Also, POSIX requires the current behavior. Yes, sadly from my reading of susv3 and posix, it does. Which kinda squelches the whole idea. Anyway, posix does not specify the error message to use when encountering './', and IMHO this is a fairly startling error message to see unless one has read rmdir(2). Especially since the command has actually probably removed all the directories you expected it to before failing like this: rmdir: .: Invalid argument A message like this would be much clearer: rmdir: Not removing directory . (Invalid argument) -- see shy jo signature.asc Description: Digital signature
Bug#428444: rmdir -p ./foo literally tries to rmdir .
Package: coreutils Version: 5.97-5.3 Severity: normal File: /bin/rmdir [EMAIL PROTECTED]:~mkdir foo [EMAIL PROTECTED]:~rmdir -p ./foo rmdir: .: Invalid argument zsh: exit 1 rmdir -p ./foo Since . is never a valid argument to rmdir(), why does rmdir try to do that? Consider a script that gets input from the user about what directory to act on, and wants to rmdir it at the end. The current behavior of rmdir forces each such script to check the user's input to avoid calling rmdir with a path name starting with ./. I think it would be better for rmdir -p to simply ignore the ./ and not try to literally rmdir(.) in this case. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages coreutils depends on: ii libacl1 2.2.42-1 Access control list shared library ii libc6 2.5-10 GNU C Library: Shared libraries ii libselinux1 2.0.15-2 SELinux shared libraries coreutils recommends no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
