FWIW BleachBit in many repos is more complete than this. One can go further and mount some of the directories mentioned in the script as tmpfs. It may also be worth noting that recursively removing everything in /tmp while a desktop is running can cause some glitches in some desktop window managers and/or Xorg depending on many conditions.
Reminder that shred(1) doesn't work on journaled filesystems.[0][1][2]
CAUTION: shred assumes the file system and hardware overwrite data
in place. Although this is common, many platforms operate
otherwise. Also, backups and mirrors may contain unremovable
copies that will let a shredded file be recovered later. See the
GNU coreutils manual for details.
Thank you for your detailed assessment. I have updated the script to fill the directories with random data (to match original size) at the end to help prevent recovery further.
Literally 8-9 lines of rm/shred commands (depending on how you count), asking you to run it as root (so it will clean the home of root instead of the user, without even checking what's going on -.-) or with sudo.
Come on, this is not even low effort. I'm sure you can do better than this.
If I, as a sysadmin give root rights to my user, and that user deletes my (real root) files, even from the Trash or anywhere else, then the next step includes such a level of violence that's not compatible with any kind of Code of Conduct.
If you give a user wheel/sudo/root privileges, then they will be able to delete the root user's files regardless of using this script. I will consider removing this line and thus the required superuser privileges in the next release.