windows: tester.tcl question
There's a transpiler-produced port of SQLite for Go - as some of you may have
already noticed. The maintainer of the Windows target posted at the issue tracker a proposed fix for
proc get_pwd, which seems to work for him.
I'm no Tcl expert. Can someone more familiar with the tester.tcl code please take a look and provide some insight? In particular it would be good to know if we're doing something wrong or if it might be an upstream bug.
Thanks in advance.
I did look into this. But I didn't understand the problem. tester.tcl seems to work fine on every machine we run it on here. I don't know why it is not working on the Go port. And the description did not help me to understand, sadly.
tester.tcl works fine on all *nix targets for us. The problem manifests only on Windows.
tester.tcl seems to work fine on every machine we run it on here.
No disrespect intended, but may I ask if there are also Windows machines in "every machine"?
I presume they are and that would imply there's something to fix on Go side. I'm just trying to clarify this so we know which area to look into before digging into it more.
Thank you for your kind cooperation!
The Windows port maintainer did a test with Tcl binary on Windows and reported the observations:
% string trim [exec -- $::env(ComSpec) /c %CD% ] '"%"CD"%"' is not recognized as an internal or external command, operable program or batch file. %
It seems to me like a bug in Tcl per se.
We fixed out local copy of
tester.tcl here and it appears to work for us.
I'm aware of at least two places in SQLite repository that use the same
[exec -- $::env(ComSpec) /c %CD% ] approach on Windows that may need updating and retesting.
(5.1) By Larry Brasfield (LarryBrasfield) on 2021-01-18 20:28:57 edited from 5.0 in reply to 4 [link] [source]Deleted
I have sadly missed your reply and it seems to have been meanwhile deleted.
I'd still like to know what's the proper resolution of the issue. In particular, if the bug is in SQLite's
tester.tcl, Tcl per se, or it is actually us doing something wrong. In the last case we have to fix it.
Thanks in advance for your kind cooperation.
(7) By Larry Brasfield (LarryBrasfield) on 2021-01-21 14:24:21 in reply to 6 [link] [source]
I had suggested just using the shell command, 'pwd', without realizing that it is not a built-in and only works for me because a pwd.exe is locally available.
However, I believe a fine resolution is to replace the offending line with:
string trim [exec -- $::env(ComSpec) /c CD ]
, which works because the shell normally referred to by the ComSpec environment variable interprets a bare 'CD' command by outputting the current working directory. (IOW: delete the two '%' characters.)
Thanks for the suggestion. It's what we tried to do and it seems to work for us.