If you want to delete an entire tree of directories in the file system, you want to use rmtree from the File::Path module (it's part of the standard distribution, you already have it on your system).

It takes a reference to a list of directory starting points, so it looks like this:

   use File::Path 'rmtree';

   rmtree([ "$rootpath/$username" ]);
[download]

You don't actually have to specify the 'rmtree' function in the use statement, as it gets exported (made available) by default, but I like to do so anyway, so that subsequent maintainers can see quickly where a function came from. This is especially important when you have half a dozen modules bringing in bits and pieces.

If you had an array of user directories you wanted to remove, you could fill the list via a map:

   rmtree([ map {"$rootpath/$_"} @user ]);
[download]

The reason it uses this slightly odd approach is because there are two little-known, rarely-used positional control parameters you can tack on the end:

   rmtree([ map {"$rootpath/$_"} @user ], 1);
[download]

The above call will behave "verbosely", printing out what it's doing as it goes about its job.

There's a second parameter that you can also set to a true (non-zero, 1 by convention) value, that will instruct rmtree to skip the attempt at deleting something for which the process lacks the necessary delete or write privileges (on platforms like VMS where that makes sense).

I've never really understood the purpose of this, since whether you ask the function to skip the files, or let it attempt to do so anyway, and fail, the result is the same: there will be some files that will not be deleted. But it usually works out as it should. If the rmtree fails, an equivalent rm -rf would as well.

The uselessness of the second parameter notwithstanding, it should be pointed out that this sort of interface is positively archaic, and not to be emulated if you're just starting out. The reason being is that if you want to change the default skipping behaviour by setting the second control parameter, you are forced into a decision about what to set the first control parameter: 0 or 1. What does it do again? Which one sets the print behaviour, the first or the second?

There are better interfaces available: either using objects with chained methods to change the behaviour, or just simply a series of public routines like rmtree, rmtree_print and so on.