Cannot load gtkwave tcl script using ghdl.gtkwave_script.gui

[elhasab]

My run.py includes the following line:
tc.set_sim_option("ghdl.gtkwave_script.gui", join(test_path, "gtkwave.tcl"))

which produces the following error message:
GTKWAVE | couldn't read file ""/home/docker/DDR3/src/test/gtkwave.tcl"": no such file or directory

Removing the extra quotes below solves the problem:

vunit/vunit/ghdl_interface.py

Line 277 in 3de8d22

cmd += ["--script", "\"{}\"".format(abspath(init_file))]

[eine]

I can confirm the issue. And I have the same fix in a local WIP branch. However, I don't know in which context are the escaped quotes required. I believe there must be some, which lead to adding them.

/cc @GlenNicholls, since blame tells that this was introduced in #459 (also, see #458).

[kraigher]

Extra quotes should not be needed when calling a subprocess direcly with an argv list. It is only necessary when invoking a subprocess through the shell where the shell will perform tokenization of the argument string into argv. We never invoke subprocesses through the shell as it is a bad practice in python. Maybe gtkwave passes the argument internally in some bash script which requires quotes but then it is a bug in gtkwave that should be reported to them and not worked around by us.

[GlenNicholls]

I had that issue before but got around it a different way:

vu.set_sim_option('ghdl.gtkwave_script.gui', 'gtkWave.tcl')

This tcl script just calls an add wave function I have elsewhere in my repository. But yes I agree with @kraigher, this should be an issue sent to the GTKWave team. They're very responsive so they might be able to get a fix quickly!

[kraigher]

It seems VUnit defines the option as a file name containing the script but gtkwave also supports writing a script inside the argument as well without having a filw on disc?

[GlenNicholls]

@kraigher I am confused about your statement. Are you asking if gtkwave allows the user to send tcl commands directly from the command line instead of sourcing a .tcl script?

[kraigher]

Yes I am asking about the behavior of gtkwave.

[GlenNicholls]

So I am not sure as I've actually never tried that. All my commands are in a file structure. I can try this when I get home tonight, though.

[eine]

Maybe gtkwave passes the argument internally in some bash script which requires quotes but then it is a bug in gtkwave that should be reported to them and not worked around by us.

On the one hand, I will remove it because i) @elhasab and me had to remove it for it to work, and ii) we should not be fixing it like this.

On the other hand, I wonder in which context where quotes required. @GlenNicholls, you said "I had that issue before but got around it a different way". Do you remember which was the context where you had that issue and you got it fixed by adding the escaped quotes?

[GlenNicholls]

@1138-4eb No, unfortunately, I do not remember as that was what I had to do for the PR. I believe I was using an older binary for gtkwave, but that is my best guess. That system is currently broken, so I don't have any way to figure out what caused the need for the escaped quotes. I tested again with the escaped quotes on a system with the newest gtkwave binary and that did not work.