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]
