WAD TABCOMPLETE broken?

[charles_perrin]

The TCC docs state that a TABCOMPLETE script receives 4 parameters. A one-line Lua script that simply print its arguments (ie table arg) shows that this is wrong if the command line to be expanded has one or more quoted arguments with spaces in them. In that case arg[4], arg[5], ... contain the various bits and pieces of the broken command line.

Additionally, it seems impossible to set an environment variable from within the included Lua dll. This either requires additional helper DLLs or recompilation of Lua53.dll in order to add code to set environment variables. Seems a bit short-sighted.

Win7 x64, TCC 19, build 43

 

[rconn]

That is not correct.

The first three arguments passed to TABCOMPLETE cannot have unquoted whitespace. The fourth argument (the command line itself) is definitely double quoted (whether it has whitespace or not). However, it's possible that what you're passing it to doesn't recognize the enclosing double quotes and is simply trying to match the next quote it finds on the command line.

 

[charles_perrin]

If that's a WAD then the design is broken.

However, it's possible that what you're passing it to doesn't recognize the enclosing double quotes and is simply trying to match the next quote it finds on the command line.

Control is passed to a Lua script that in turn is executed by the internal Lua dll. The flow of control, until the arguments arrive, never leaves TCC and so there's nothing I can do to influence what is happening.
If you load this simple script into TABCOMPLETE...

• for i,a in pairs(arg) do print(">",i,a) end

and then tab-complete this command line...

• dir "this a b c" test

this is the output:
> 1 dir
> 2 test
> 3 17
> 4 dir "test
> 5 a
> 6 b
> 7 c" test
> 0 D:\DOS\TCC\Complete\complete.lua
> -1 Lua

So something is clearly broken and as the only thing I am doing here is executing this Lua one-liner I can't for the life of me see what I could do differently.

BTW, TABCOMPLETE is broken in other ways. If you forget /l when loading a script, there's no error message though the script is not loaded. If you try to unload a script in a subdirectory of the current directory (ie tabcomplete /u Complete\complete.lua) but don't use a full path name, then the script can't be found.

 

[vefatica]

I can duplicate the first two gripes (trouble with quoted args and no error message when no option is specified). About the very last comment, this is how I see it. TCC seems to identify the script by (exactly) what was typed when it was loaded. So, for example, if you say

tabcomplete /l foo\bar.lua

then
1. The completion will only work when the current directory contains foo\bar.lua (otherwise the script won't be found).
2. It can only be unloaded by specifying exactly the same string, "foo\bar.lua", and that can be done from anywhere.

 

[charles_perrin]

1. The completion will only work when the current directory contains foo\bar.lua (otherwise the script won't be found).
2. It can only be unloaded by specifying exactly the same string, "foo\bar.lua", and that can be done from anywhere.

It seems you're right. That means, among other things, that a completion script loaded automatically (ie those in <tccdir>\Complete) can't be unloaded by a sequence of CDing into <tccdir>\Complete and then unloading them by just giving their filename. Not exactly intuitive... especially since the error message given is "TCC: (Sys) The system cannot find the file specified." when the file clearly exists. So perhaps there should be a hint in the docs as to this slightly weird behaviour.

A better design might be to construct an absolute pathname when loading a script and then, when unloading it, attempt to build a full pathname again and try to unload that. Whatever, as long as it's consistent I don't care much.

Whereas the original problem is a show stopper. It's possible to more or less work around that but that is less than ideal. Well...