Subject: Re: bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other

From: Assaf Gordon <[email-masked]>
Date: Tue, 18 Oct 2016 20:14:27 -0400

Hello,

> On Oct 18, 2016, at 17:35, Linda Walsh <[email-masked]> wrote:
> 
> Assaf Gordon wrote:
>>> rmdir -p ./a/b/c   # get error msg, but a,b,c removed.
> 	I see... so in ".a/b/c", a,b,c are removed, but the error
> comes in "."?

Yes.

> 	Ok, but is "-p" a posix switch in mkdir or rmdir?

Yes, it is defined in posix for both mkdir(1) and rmdir(1):

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rmdir.html
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

>> However, by definition, when 'rmdir' traverses the directories on the given path,
>> the directory 'a/..' is not empty (it contains 'a') - so this must fail.
> ----
> 	with "-p"?  Am talking about the case where you create a dir with "mkdir -p "$dirname"
> and later, rmdir -p "$dirname" (where dirname is passed as a parameter, but
> is not user-input).

Yes. By posix definition, For "rmdir -p DIR" where DIR contains multiple path components,
rmdir should behave as if run with "rmdir -p $(dirname DIR)".

And for example:
      $ dirname "a/../b"
      a/..

And trying to call rmdir(2) on "a/.." will fail (definitely fails  on Linux kernel, though I suspect on other systems as well).

> 	Right, but am trying to get rmdir to be a useful
> "opposite" to a "mkdir" -- at least w/r/t "-p"...

"useful" is somewhat subjective.
For the more common case of directories without ".." or "." - this works quite well,
and that is very likely the intended goal:

     mkdir -p a/b/c
     rmdir -p a/b/c

As the current behavior is mandated by POSIX, If you want to suggest a different behavior,
the best place to suggest this is to the posix group ( https://www.opengroup.org/austin/ ).
If the standard for 'rmdir(1)' is modified or adjusted, GNU coreutils will surely follow suit.

> But is -p's behavior in mkdir and rmdir mandated by POSIX?

Yes, see above links.

regards,
 - assaf