SQLite Forum

windows: tester.tcl question
Login

windows: tester.tcl question

(1) By 0xjnml on 2021-01-16 16:31:43 [link] [source]

Hi there.

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.

-j

(2) By Richard Hipp (drh) on 2021-01-16 17:56:45 in reply to 1 [link] [source]

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.

(3) By 0xjnml on 2021-01-16 18:53:17 in reply to 2 [link] [source]

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!

(4) By 0xjnml on 2021-01-18 13:56:43 in reply to 2 [link] [source]

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.

  • A recent patch, fixing danp128's report of a different issue the Go port ran into.

  • Here it seems to be used in tester.tcl at tip.

(5.1) By Larry Brasfield (LarryBrasfield) on 2021-01-18 20:28:57 edited from 5.0 in reply to 4 [source]

Deleted

(6) By 0xjnml on 2021-01-21 10:48:41 in reply to 5.1 [link] [source]

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.

-j

(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.)

(9) By 0xjnml on 2021-01-21 14:43:17 in reply to 7 [link] [source]

Thanks for the suggestion. It's what we tried to do and it seems to work for us.

-j

(8) By Richard Hipp (drh) on 2021-01-21 14:31:21 in reply to 1 [link] [source]

Please try SQLite check-in fe1979552f43e052 or later (2021-01-18) and let us know whether or not the changes Joe implemented resolve your issue.

(10) By 0xjnml on 2021-01-21 14:46:28 in reply to 8 [link] [source]

Thank you very much!

I'll report back the outcome here in a few days. The Windows port maintainer is located in a different time zone, our communications are slowed down a bit because of that.

-j