On Mon, 2 Aug 2021 17:35:09 -0500 Dirk Eddelbuettel via ESS-help <ess-help@r-project.org> wrote:
> On 2 August 2021 at 17:20, Dirk Eddelbuettel via ESS-help wrote: > | > | On 2 August 2021 at 23:56, Stephen Berman wrote: > | | Did you also try the more direct alternative of grepping simply for > | | "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function updates these > | | files has to refer to them, either directly by name or indirectly by a > | | variable or function that in turn refers to them directly or indirectly. > | | So it should be possible to find the update function by inspecting all > | | code that uses these file names (directly or indirectly). > | > | They are only written by a tool named gtags which is a binary that comes > with > | GNU global. I even tried to be craft and 'shadow' /usr/bin/gtags with a > | (name-name) shell script leaving a timestamp in /tmp before calling > | /usr/bin/gtags but that left no traces either. > | > | But in one of the instrumented repos, as soon as I updated files src/ the > | files GTAGS and GRTAGS. It works so magically I feel tempted to use the > | trick for other purposes but I no longer know the trick <man_face_palming>. > > Sorry, missed one part of your question here: so yes, no trace of either > gtags or GPATH or GTAGS or GRTAGS in any of the few .el files in my ~ (and as > an elisp noob I would not write anywhere else). So still a puzzle. Maybe you could use gdb with a breakpoint on a suitable function (or just main()) in gtags.c (assuming you have the source) and try stepping through the call chain. Steve Berman ______________________________________________ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help