Fix gdb scripts

[jyapayne]

@krux02 I think I've addressed your issues, except for the function call. Let me know if it works for you and if there are any other changes you want.

[jyapayne]

This function is needed because a variable can't be called in the below:

NIM_SYSROOT=$(dirname $(dirname $(nreadlink -e $(which nim))))

If nreadlink is instead a variable, the command will fail to run.

[krux02]

I am not much a fan of the file name change. The file is in my path and therefore the name truly matters. And the only reason the change happend was because of a bug in VSCode, am I right? Can't you do it the other way around, keep the original name without ending, but you put an additional symbolic link with the name nim-gdb.bash into the project? I would be much happier with that.

[jyapayne]

@krux02 Sure, that works too. Done.

[Araq]

Once again the shell scripts are turned into edit wars. Lesson learned, no shell script will ever be accepted again.

[krux02]

@Araq As a short recap. You merge a PR for a file where you know very well that I am responsible for without any review process and without giving me time or opportunity to comment on it. Then when problems bubble up you use the so called "edit wars" as pretext to ban shell scripts all together. Ok then, go for it.

[Araq]

Without my merge the facts remain identical: Shell scripts never suit everybody and cause lots of maintainance overhead.

[krux02]

Well then, the same can be said about nim source code. Do you want to ban nim code as well?

[Araq]

The same cannot be said about Nim code as Nim code is much more portable than Shell code. But yeah, we also actually we try to have fewer lines of code written in Nim, see how @timotheecour and others must fight to get something into the stdlib or the compiler.

[timotheecour]

@krux02 Am I missing something or everything in bin/nim-gdb and bin/nim-gdb.bat could be turned into tools/nimgdb.nim that would achieve the exact same but cross platform / more portable? (say with osproc.startProcess)
IMO the only shell script need in Nim repo is what's needed to bootstrap (build_all.sh/build_all.bat); once nim is bootstrapped, everything should use nim, and would result in simpler & smaller code.
Including things like

tests/dll/test_nimhcr_integration.sh (not portable! linux but not OSX nor windows)

shell scripts are bad at code reuse, portability, etc

[krux02]

First of all, it should be said, I am not a fan of nim-gdb to exist in the first place. I tried my best to make running gdb just work. But the mechanisms in gdb to automatically load pretty printers don't work for programming languages, they only work for libraries. So I did the best I could do. And I tried to keep it as minimal as possible. But one requirement for nim-gdb was that it would actually become a real gdb process, not some shell process or nim process that just runs gdb. This ensures that signals sent to nim-gdb actually reach the gdb process and therefore the signal handler of gdb. So the exec in the last is very important.

Am I missing something or everything in bin/nim-gdb and bin/nim-gdb.bat could be turned into tools/nimgdb.nim that would achieve the exact same but cross platform / more portable? (say with osproc.startProcess)

Yes you are missing something. startProcess or execProcess both start new subprocesses, wich is not wanted (like I just explained above). exec is what is required. This does exist in Nim here, but this is platform specific again. So eventually I went with shell scripts in favor of Nim.