AutoHotkey Community

[jballi]

This script was created from an obscure and infrequent requirement that I have. Every once in a while I have a project where I end up with a bunch of extraneous (and usually) empty directories. It makes it much easier to go through all of the directories and subdirectories if I can find and delete the empty folders.

A couple of notes...

1. This script was designed to run from the command line in the directory where you want the search for empty directories to begin. You can't just double-click on the script and expect it to work the way you want it to. The script could easily be modified to request the starting folder. Since I use this routine infrequently, this enhancement would just slow me down, so... I didn't add it.

2. This routine will not delete an empty directory if a program or process has a hold on it. Windows Explorer does this every once in a while.

3. Directories that only contain empty directories are also deleted.

4. Not all empty directories are evil. Some are required. Please, I'm begging you, please use this script with care.

5. This script contains a bunch of code to display splash messages. Feel free to delete it. You don't really need it. I kept it in because it's a nice-to-have when dealing with large folder structures.

Here's the code. I hope you find it useful:

[Laszlo]

Decarlo110 also posted a very long script for this. Yours is much shorter and very nicely laid out. However, we can make it even shorter

[jballi]

Neat trick. I'll just add a counter and it'll be a done deal. Thanks for the feedback.

One other thing I might add will be a check for hidden or system folders. May not want to delete them even if they are empty.

I did a search on this topic b/4 I posted. I'm surprised I didn't find the DeCarlo111 post. Obviously, didn't look hard enough.

Thanks.

[evl]

I noticed that this function also deletes the main folder itself if empty, as well as sub-directories. To keep the main folder passed to the function, I made the following change:

[Laszlo]

...or you could just re-create the starting directory. FileCreateDir does nothing if the directory has not been deleted.

[evl]

Yes I had debated about just re-creating the directory afterwards, but this way seemed a bit neater to me and less of a "fix".

I can't think of any real difference in the outcome of doing it either way, other than that this way it's all contained quite neatly in the function. I doubt there's any big speed difference as the hard disk operations would be the limiting factor in speed I would have thought.

[jballi]

...or you call the function only after you begin to loop through the root folder. That way, the root folder is not deleted. Something like this:

[evl]

Actually I realised an even simpler solution to not deleting the starting directory, which is to change the FileRemoveDir path to %A_LoopFileFullPath%.

However, for the life of me, I can't figure out exactly how "%dir%" ends up containing the currently looped directory, or is this just some feature of "Loop" that I've overlooked?

[Laszlo]

%dir% references the function parameter, which does not need the % signs around it when it is in the parameter list or in expressions, but it needs the % signs if it represents a variable.

The starting directory is not deleted with A_LoopFileFullPath or A_LoopFileLongPath, because these loop variables become empty outside of the loop. In deeper recursion levels (not in a loop) they look like global variables (no local value is assigned to them), so they inherit the value of the variable in the calling function. It happens to be the same as dir, the function argument, except at the topmost level. There it refers to a global variable, which normally does not exist.

This is how it should work, which shows how good a job Chris did. However, there is a danger: if there is a global variable A_LoopFileFullPath or A_LoopFileLongPath, the corresponding (empty) directories will be deleted. It happens if you call the DelEmpty function from a loop. The other two proposals don't have this problem.

[evl]

Laszlo,

Yes I did understand that already about referencing variables with %, etc - the specific part that I couldn't really see, was how that variable is given a new value in this function, since it isn't assigned one directly. (I understand why A_LoopFileFullPath, etc get new values because of the way they are linked to the Loop command, but I can't see how this is the case with "dir")

I followed your explanation about my last suggestion - I guess it's probably best not to do it that way really then. I've been noticing how AutoHotKey likes to "misbehave" in other situations when it doesn't get valid paths, etc, such as traversing through a whole drive instead of aborting (kind of worrying, depending on what file operations you're doing!)

"if there is a global variable A_LoopFileFullPath or A_LoopFileLongPath" - I thought that those variables were only valid inside of loops and couldn't be defined as global anyhow?

[Laszlo]

Inside the function the parameter, whatever it was at the call, gets a new name: dir, in our case. It is an implicit assignment, like

(local copy of) dir := parameter (at the function call)

You are right, A_LoopFileFullPath or A_LoopFileLongPath are not allowed to be changed or assigned a value. But they are defined in file loops, when they would look as normal variable. If inside that loop you call a function, it sees them as normal global variables.

[evl]

Thanks for your explanation, think that cleared things up for me (especially the implicit assignment bit, surprised that isn't mentioned in the manual - not that I could see at least).

[Decarlo110]

[Laszlo]

[Decarlo110]