It sorts the .ash_history file, a function that is not built into the command line options of BusyBox. It also keeps the .ash_history file in jffs so it survives a reboot. Running it at boot ensures you have a sorted file when next logging in with ssh.
Adding the last diversion commands to the top is a feature that Diversion users might find handy.
Keeping the ash history and sorting it has been added way back in earlier AB-Solution releases.
If your history is too long, just runs sh in Diversion, this resets the file. It can be found in the expanded menu o.
I missed this line:
Code:
ln -sf /jffs/.ash_history /home/root/
That is indeed a nice feature to have, I just have 3 comments/concerns/suggestions:
1) It is possible - especially since we are preserving history that this file could grow very large. Therefore the sort feature could indeed peg CPU while it operates on a large file. How large this file has to be and how many CPU cycles it could take up are unknown to me, but this is what could be happening to some?
2) It would be nice if the preservation of the file wasn't linked to the sorting. Some people might like to have the file retained, but don't want it sorted for a couple of reasons:
- they have a large file and don't want the CPU cycles associated with it. (if indeed that is the cause of the observed issues some have).
- they want their history preserved as-is and don't want recent commands to just be put in randomly (based on sort order).
- possible concerns about excess write activity to jffs/flash memory.
(I don't really know the true impact of this, but I know some users thing it is a big deal).
I know you state you can just reset/delete your history, but a user shouldn't have to choose between deleting their history or retaining a large one and dealing with large CPU cycles from the Diversion sort process.
3) Continuing on #2...
Please don't take this in the wrong way since all your efforts are appreciated and I'm just stating a personal preference/design choice. I've been seeing a lot of "feature creep" in ab-solution/Diversion's history. Lots of things that really have nothing (or very little) to do with the function of as-blocking seem to be integrated into the script.
Normally, I wouldn't have a problem with this. In fact, I have been guilty myself in previous projects I coded of adding in all sorts of little features as "nice to have" either because they were requested or because they were just something I wanted/used so I added them in even if they were not really related. In the end though I learned this leads to bloat, and more maintenance, and ultimately more work in documentation, support, and confusion.
Additionally, while I have no issue with a feature like this being in Diversion, I am a little concerned that unless you are actually reviewing the source code (or at least reviewing the finished contents of all the jffs scripts) you would never know that this feature is happening. If a user didn't want their history retained (or sorted), or had something similar setup this feature could disturb their setup. It would be great that this feature, and any like it (in terms of system/user impact not directly related to Diversion functionality) was at the *very least* documented and presented to the user in a post-install "readme" that displays to the screen. This way the user is aware of changes to their system.
Ideally, the user would be able to opt in/out of these features without having to just go do post-install cleanup.
Obviously this would mean some more choices/lines in the installation code.
To be honest, a feature like this I think has much better place in amtm then in Diversion.
I would almost rather see you ship amtm with Diversion and install it automatically.
You could then remove/move all non-diversion specific (i.e. ad blocking) into amtm.
amtm could then be added as a sub menu item in Diversion, so the end effect is all these things could be maintained within diversion, but are part of the amtm code base. Additionally/preferably all these things in amtm are opt-in (which is currently the case with the available amtm options afaik).
Anyway, again these are just some observations from an interested outsider (with some coding/project management experience) new to the solution.
I might question some of the choices made, but I'll still remain grateful to whatever work is done!
Thanks.