.gdbtkinit and the -cd option

[John Fine <johnsfine at verizon dot net>]

.gdbtkinit and the -cd option interact badly.  (See details below)

I frequently would want to run insight with a different .gdbtkinit file 
than the one in $HOME.  Support for that is provided.  Simply start 
insight in a directory that contains .gdbtkinit and insight will read 
that one instead of the one in $HOME.

But I think insight should do a better job of remembering where it read 
that from.  It remembers if it read it from the current directory rather 
than from $HOME, but it doesn't remember the current directory.

I also frequently would want to run the program to be debugged with a 
different initial current directory than the one in which I started 
insight.  That is (sort of) supported with the -cd option on the command 
line.

It would have been more robust if there were a way to specify an initial 
working directory for the program you are about to run without changing 
insight's own working directory.

When you combine the above two features, the problem is the directory to 
which insight WRITES BACK the modified .gdbtkinit file.

Insight reads the .gdbtkinit file from the directory that was current 
before it processes the "-cd".  It reads the -cd option before reading 
the .gdbtkinit file, but (for fairly good reasons) defers processing the 
"-cd" until after it has read the .gdbtkinit file.

When Insight writes the .gdbtkinit file, it uses the remembered filename 
string, so that if .gdbtkinit was read from $HOME it will be written 
there, but if .gdbtkinit was read from whatever directory was current 
when it was read, it will be written to whatever directory is current 
when it is written.

I think it would be much less confusing to get the value of current 
directory as a string before reading .gdbtkinit, then if it is able to 
open .gdbtkinit appended to that string for reading, remember that whole 
string for use when writing it back.

At the moment I'm trying to use insight to debug insight and I'd like 
each copy to read and write its own .gdbtkinit file.  I ran into some 
problems earlier due to sharing that file.

I'm gradually tweaking the command I use to start debugging as I 
understand and resolve problems.  Currently I have

insight -ex 'set env DISPLAY = :2' -cd ~/testv64 --args insight --args 
my_program and its args

The -cd causes the second insight to run in a different directory than 
the first and read a different .gdbtkinit file.
But if I start the whole thing in a directory that contains a .gdbtkinit 
file, the first insight will write its changes back to the second 
.gdbtkinit file.
So I need to start it all in a directory that doesn't contain 
.gdbtkinit, so the first insight will use $HOME/.gdbtkinit.
I placed an initial .gdbtkinit file in ~/testv64/ so that the second 
insight wouldn't use $HOME/.gdbtkinit.

Earlier, I also ran into a problem, I still don't quite understand, that 
caused the mouse to malfunction as if the second insight (which had just 
seg faulted) still owned the mouse.  I had to kill the whole vncserver 
desktop to get out of it.  So I added that -ex 'set env DISPLAY = :2' to 
run the second insight in a different vncserver than the first and that 
problem seems to be solved.  I'm actually running on a Windows computer 
with three displays, trying to debug programs on a Linux computer 
elsewhere in the LAN.  So I run putty to the Linux machine in one 
Windows monitor. I use that to launch two vncservers, then access each 
of those with TightVNC Viewer using the other two Windows monitors.