What about remove instead of delete? I think that would fit better. rmdir means remove directory and there are also still some comments and specs left that say something like:

# Removes the directory at the given path.

or

  it "tests delete with a path that cannot be removed" do

there "Removes" should be better "Deletes" and "removed" should be "deleted" I think.

Or just change delete to remove.

I will change everything to delete because under the ground Crystal::System::Dir.delete is callled and there is also File.delete.
The word delete better fit in this case than remove because the directory isn't recoverable after deletion (https://english.stackexchange.com/questions/52508/difference-between-delete-and-remove/52509#52509)

We should be moving everything to Path soon anyway so might as well save all the refactors for that?

@RX14 As far I've seen in #5635 , the PR is mostly about adding the Path. I haven't seen modifications about FileUtils(yet?) - how it will be incorporated?. I have thought it was preferable to do this such small changes in a separate PR.

Adding Path type is one thing. Restructuring the APIs of File, Dir and FileUtils is another issue. This should be discussed on a higher level, with everything in sight. Not a PR about single methods.

For me mkdir and rmdir looks weird on Dir (and Path?), but everyone has its own tastes.
I was just looking at improving this on the actual API, for now.

I agree with you, and I actually like this change. What i'm suggesting is to break everyone's path handing at once in one release not break it a little bit few releases in a row. If we're going to make a massive breaking change on the horizon anyway we might as well bundle this up with that.

Now just make sure we don't forget this when the time comes :)

Finally I quite agree with you. Ok to keep rmdir and mkdir at the moment.
What about only merging Dir.mkdir_p to FileUtils.mkdir_p? It maybe be a breaking change, sure, not that big because it only removes an alias.

@RX14 Are you OK with this change - WDYT?

It doesn't make any sense to separate mkdir and mkdir_p in different namespaces. They're actually the same thing, just with slightly different behaviour. The CLI tool has -p as a parameter, they're not two different tools.

Subsequently, I'd leave mkdir_p in Dir. Yes, maybe even name it mkdir and make parents mode default. This is typically much more commonly used than mkdir without parents. The latter could be achieved with Dir.mkdir("foo", parents: false).

Agree @straight-shoota , it would be even greater to have a recursive argument (or something else) in common for commands like mkdir, rm, cp