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

[Assaf Gordon]

Hello,

> On Oct 18, 2016, at 17:35, Linda Walsh <address@hidden> 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