Exposing Ghidra's `help` via the bridge about ghidra_bridge

[fmagin]

So, this is implemented in ./Ghidra/Features/Python/data/python-src/ghidradoc.py. Bridging the Helper class will probably not work because it might just end up printing on the wrong side of the bridge.

Given that the information is just loaded from a zipfile (GhidraAPI_javadoc.zip) I see two options:

• Some way to request the information over the bridge
• Just getting the path and checking if the file exists on the client side too and using that

To avoid confusion I would suggest adding a bridge specific help function to get the doc for a bridged object that works in a similar way as the builtin. So help(currentProgram) still gives the doc for the BridgedObject class but b.help(currentProgram) returns the doc for the ProgramDB class gathered from the ghidra docs.

This still leaves the issue of controlling the IPython magic for currentProgram?, but the Attribute Errors in the bridge server indicate that a few things are being checked, one of them being getdoc which might be something that can be implemented properly.

[justfoxing]

I've got a pretty smooth implementation that hooks print on the ghidra side to capture the output from the Helper class as a string and return that (much easier than trying to re-implement their code and finding the right file to run it against).

BridgedObjects are meant to be as transparent as possible, so I'm not keen on them having their own help, especially at the cost of being harder to get help for the Ghidra objects that people will actually care about. So, my implementation just straight up replaces help() and punts help for bridged objects across the bridge. Check out feature-ghidra-help for a sneak preview - I still want to come up with some tests before I merge that.

Not sure about the ipython magic, but I'll take a look at those errors.

[fmagin]

Nice this does seem like a good start. One thing I am missing is that the output is not paged, which is fairly annoying for long output. The only change necessary would probably be print(help_output) to whatever makes the output paged.

I might be able to look into the IPython ? magic today.

In general I think that the approach of working with the JSON instead of the parsed and pretty printed output could be better though, if we can use it to populate whatever variables the inspect modules checks this could allow for more powerful introspection in IPython e.g. suggestion of (optional) parameters. I will play around with this and see if I can make it work.

Your approach bridging help is entirely sufficient though for the typical use, so I am in favor of merging that and not waiting for all the IPython specific stuff.

[fmagin]

For paged output you can use pydoc.pager(help_output)

[fmagin]

Fixed by 9c1c7a0