Propagating more of a user's environment to new versions of Ghidra

[gtackett]

Issue 4421 mentions the idea of saving a particular type of user customization to the Ghidra environment. That issue's particular details aside, I think it would be helpful if more of one's customizations could more easily be propagated to or preserved across installations of new versions of Ghidra.

(Aside--the installation guide should perhaps remind the user to look for at least some kinds of customizations?)

A few use cases where this kind of feature would be helpful:

1. User-provided processor manual .pdf and .idx files in processors/.../data/manuals
   It's inconvenient (and hard for me to remember) to copy into each newly installed version of ghidra, any .pdf file's that I've provided (and, possibly, new or modified .idx files) for the currently installed version.
2. Modifications to processor language files in processors/.../data/languages
3. Ghidra-specific Java command line parameters added to ghidraRun/ghidraRun.bat

At a minimum, perhaps when a new Ghidra version is first launched, it might automatically "notice" that the user had made specific kinds of customizations to an already existing installation, and remind them to propagate such into the new version. OS-specific scripts would certainly be required.

Beyond that minimum, though, any other automatic assistance gets more complicated and more risky.

• For processor documentation or language files such as those in processors/.../data/..., display the names of any files that differ from what the new version provides. A simple notion of "different" would have to be used--something not dependent on OS-provided or user-provided diff utilities, perhaps merely citing files that aren't present in the new Ghidra version, and merely comparing file sizes or checksums of files that Ghidra itself normally supplies.
  • Optional automatic copying forward the user-supplied documentation might be fairly low risk.
  • Files critical to Ghidra operation probably should not be automatically copied forward, as doing so would incur significant risk.

Tools for these capabilities may not be something the official developers would want to commit to, but perhaps the user community could approach doing so independently of the official Ghidra repository or forks thereof.

[ryanmkurtz]

I think that asking your current Ghidra what files have changed from the original installation is a reasonable thing to implement. Automatic migration would be a much tougher problem.