Make rmdir: recursive

[danielbayley]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

Following on from Homebrew/homebrew-cask#67806, and Homebrew/homebrew-cask#73867 (comment) …

[danielbayley]

Is there a way to run the brew tests just for uninstall_spec and zap_spec? Maybe I'm doing something wrong… but brew tests --only doesn't seem to work.

[vitorgalvao]

Why are we calling /bin/rmdir instead of using FileUtils.rmdir?

[reitermarkus]

It's because we're calling it with sudo.

[danielbayley]

It's because we're calling it with sudo.

I did wonder about this in the past… Is there no way of doing sudo with the native Ruby methods?

[danielbayley]

Also, do we still need print_stderr: false here, since we now have the unless clause prior?

[reitermarkus]

I think there needs to be a separate function for the recursion, otherwise

ohai "Removing directories if empty:"

will be called multiple times.

[danielbayley]

Ok, pretty sure I've got it now @reitermarkus 👍

Is there a way to run the brew tests just for uninstall_spec and zap_spec? Maybe I'm doing something wrong… but brew tests --only doesn't seem to work.

I still would like to know this…

[danielbayley]

Sorry, I don't quite follow… Does all? not need to operate on an array of already resolved_paths (therefore inside this method call)? Also, the second directories argument can be a [glob pattern] string…

@reitermarkus ?

[reitermarkus]

Instead of next false, create a success = true before the each_resolved_path and set that to false and at the end return success.

[vitorgalvao]

Leaving a note that we’ll need to update the documentation as well.

[danielbayley]

Leaving a note that we’ll need to update the documentation as well.

@vitorgalvao Do you mean in this PR?

[vitorgalvao]

@vitorgalvao Do you mean in this PR?

No, in the cask repo.

[reitermarkus]

Thanks, @danielbayley!