??
It does not clean firefox. The $HOME cache clean explicitly skips the .mozilla folder.
Oh, I’m confused now - I saw this:
These runtimes in installation 'system' are pinned and won't be removed; see flatpak-pin(1):
runtime/org.freedesktop.Platform.openh264/x86_64/19.08
Nothing unused to uninstall
Delete data for org.mozilla.firefox? [y/n]:
From the flatpak… old and unused ref… though I don’t remember having Firefox flatpak installed.
Talk about cobwebs…
Oh gotchya … yes, I cannot control some of the defaults that the cleaners themselves use.
In the case of the pacman cache MY prompt is y/N … but if you accept that then the pacman cleaning prompts are Y/n
I suppose it does mean a little bit of inconsistency is possible.
But it still does not dissuade me from opting to use the cleaning functions of the apps themselves if they are in use. (if not in use then its a regular old rm job)
This is a point where the emphasis on ‘safe’ comes in - I dont want to clobber anything if a function already exists for sane cleaning. (journalctl vaccuum, npm cache clean, etc)
But while we are here … I keep finding leftovers from snap, flatpak, and friends … so updates are inbound 
EDIT.
Updoots.
- Found extra folders for SNAP, Flatpak, and PackageKit (in places like /var/lib).
- Updated table (include extra paths, words)
- Most noticeable is probably that I changed
paccache -rvuk0topacman -Sc. This will still cover all uninstalled packages cache, plus now also check for unused repositories. Due to this change it has also become a hard prompt (it will always ask), instead of checking if you have an uninstalled cache to remove before prompting.
If you see the table you will notice it does a decent amount of checks now, with all but 4 checking something or other before triggering a prompt for cleaning.
I am happy to report this has not had a significant impact on the overall speed of the script;
$ time yes n | ./maclean
Clean thumbnail cache of files not accessed for 2 weeks (y/N)? Skipped
Clean $HOME cache of files not accessed for 2 weeks (y/N)? Skipped
Clean AUR Helper cache of all build files (y/N)? Skipped
Clean all unused repositories and uninstalled packages from cache (y/N)? Skipped
real 0m0.321s
user 0m0.256s
sys 0m0.078s
And a note: The orphans check fires after cleaning the package cache. This means that if you run the script once while answering yes to all queries including orphan removal, then run it again there will be more package cache to remove. This is intentional. In the scenario someone removed orphan packages they actually need those packages will still be in the cache until next cleaning.
A little early because I havent updated the table to reflect all changes yet, but
- better aur helper checking
- more (flatpak and pamac) leftovers found and wrangled
- add yarn support (as with others, .cache removal skipped, prompt to clean or remove)
Until next time. 
3 Likes
Another bit of updoots.
- Table updated.
- Overall speed improved. A full cleaning is now 2x-3x faster!
- Added
midoriandfalkonto omitted caches. - yarn support improved. (surely target ~/.yarn cache with
--mirror) - snap support improved. (
sudowas required forsnap remove) - Moved a check for pacman before cache, repository, and AUR helpers.
( in total this brings down our ‘hard prompts’ to exactly 2 - the thumbnail and larger cache prompt. These changes make the script more accurate and even more portable. It should be functional on most any distro, though it will continue to be most useful on Arch/Manjaro )
Cheerios. 
Speed Details
I had erroneously left the list of paths for find to omit in reverse alphabetical.
Before the change (z-a):
$ time ./maclean -a
Performing all cleanings automatically.
This is the final warning.
[...]
real 0m10.843s
user 0m7.132s
sys 0m0.764s
After the change (a-z):
$ time ./maclean -a
Performing all cleanings automatically.
This is the final warning.
[...]
real 0m5.081s
user 0m2.196s
sys 0m0.756s
3 Likes
forgotten any link:
cd ~/.local/bin
curl -O https://gitlab.com/cscs/maclean/-/raw/main/maclean
chmod +x maclean
1 Like
Its at the top of the page
Though I had yet to tell folks to put it in (the?) bin. 
By golly jeez theres been a lot of changes.
Improved;
- go
- yarn
- snap
- flatpak
- orphans
Added;
- rust
- ruby
- go
- java
- groups of functions and associated options.
This last point will be obvious from the new HELP, which I will copy here:
maclean
A script to automate some relatively safe cleaning activities
Usage: maclean [option]
Extra Options:
-h Print this Help
-j Clean only the junk directories
-d Clean only the developer directories
-c Clean only the container directories
-b Clean only the few basic directories
-a Automatically affirm all Cleanings
That means if you just want to define your own folders as ‘junk’ and use the script with the -j flag you can. Same goes for the other groupings. The -b ‘basic’ flag will largely reflect the original state of the script and focus on home cache, journal, and pacman/package operations, avoiding the (growing!) assortment of ‘developer’ directories otherwise found under the -d flag or the regular ‘full’ run.
As always you can get the ‘update’ by re-downloading from the gitlab source.
And let me know your thoughts. 
4 Likes
If i may offer some additions for the next version:
- Clean tmp bash history files. Those a created for every terminal window the user opens simultaneously and in theory they have to be merged to history, but i found dozens of them in my home, so the theory is not always functioning, at least on xfce.
rm -f ~/.bash_history-*.tmp - There is one more flatpak cache place you missed
sudo rm -rfv /var/tmp/flatpak-cache-* - I did not see anything about coredumps. And that could be a huge space eater
sudo rm -f /var/lib/systemd/coredump/*
1 Like
That is strange. I don’t have any of those on my system, and I am using bash as my shell. 
I’m thinking it’s a configuration setting somewhere. No, I don’t know or have an idea what, where, but that’s what I think.
Has to do with the history size i think the larger it is, the more probable to have temp files left behind. Sometimes there are none, some people report empty files, mine are not empty. But the point is, if writing to the tmp breaks for some reason, the next launch of the terminal it starts new tmp and do not parse the old one and it is left there forever. The probability also increases if you use several different terminal windows at the same time. I guess every terminal creates tmp and they “compete” who can write to the final .bash_history at close and only one succeeds, the rest of the tmp is left behind.
Anyhow, it is not important, but annoyance.
Some examples here here here.
I not use bash
ll ~/.local/share/fish/fish_history
-rw-r--r-- 1 patrick users 1,7M 1 avril 17:42 /home/patrick/.local/share/fish/fish_history