Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

TCC suitability for Javascript/Typescript development

Apr
42
0
I have always enjoyed using TCC in software development when I was working mainly in C++ or matlab. There were a few hiccups, nothing I couldn't work around. But now that I need to work with Javascript/Typescript, the workarounds are harder or impossible to find.

I know that TCC's mission is not 100% CMD compatibility. Maybe TCC is targeting the IT user and, as a developer, I should be looking elsewhere?

Here is an example of the problem I ran into this week:

The big thing in SW development, particularly in open-source and especially in Node modules, which seem to update on daily basis, is automatic life-cycle management. You check-in a commit and then tests are run, files are linted, semantic versions updated, change-logs created, artifacts uploaded, and stake-holders contacted with barely a blink from the developer.

One common tool in Node development is lint-staged, a NPM module that automatically lints staged files when a git commit is run. Every week, about 1M copies of this library are downloaded. Well, it didn't work for me. After a couple of days of debugging it and libraries it depends on, I've determined that it is due to an incompatibility between TCC and CMD and I can't make a workaround for it.

This particular incompatibility is due to string-handling on the command-line. One of the unit-tests of a down-stream libraries checks that it is escaping command-line parameters properly. Ultimately, the unittest tries to run a file whose name is ()%!^&;, .bat, which simply echos the word 'special'.

It runs this command: %comspec% /d /s /c "D:\Projects\mfd\node-cross-spawn\test\fixtures\^(^)^%^!^^^&^;^,^ ". In CMD, the output is special. In TCC, it's
Unknown command "D:\Projects\mfd\node-cross-spawn\test\fixtures\^(^)^%^!^^^&^;^,^"

More importantly, not just in this library but also in NodeJS itself, the code to shell a command to comspec is /d /s /c <command>. TCC redefines the /s parameter to disable the Ctrl-C handler.


I LOVE TCC/TCMD. But as a JS/TS developer, TCC does not love me.
 
I'm not sure exactly sure what you are asking. I have not explicitly set the %comspec% variable. Was that the question?

JS/TS development tools is almost all batch files. If a run a command from the TCC command line, TCC will handle it.
 
I suppose you could temporarily change the value of COMSPEC before calling the problematic batch file. Say, if there's a FOO.CMD that does this kind of thing, you could create a FOO.BTM in the same directory:
Code:
@echo off
setlocal
set comspec=%@search[cmd.exe]
call foo.cmd
endlocal

It's also possible to use the PathExt directive, the PATHEXT variable, and executable extensions to hand .CMD and/or .BAT files off to CMD.EXE.
 
Thanks, Charles. Your active support in the forums is why TCC is so great to use.

I don't think the first suggestion would work well, given how NPM and node modules are structured. (It works a lot like python libraries. They're automatically downloaded from npmjs.com and adhere to a particular directory structure. Node related tools look for batch files in this directory hierarchy. It would never find my custom batch file unless I overwrote the versions that are automatically downloaded.)

I'll try your second suggestion; however, I expect it will cause me too much pain elsewhere.

Thanks, again.
 
I'll try your second suggestion; however, I expect it will cause me too much pain elsewhere.
Yeah, it looks like an issue magnet. But if it helps with your build scripts — you could set just the environment variables in TCSTART, then toggle it on and off with option //pathext=yes and option //pathext=no. (Create aliases for those if you use 'em a lot.)
 
The /S option in the CMD command line is irrelevant (and unnecessary).

TCC is checking to see if the argument is the name of an executable file (as per the CMD docs). It is not a file (it's missing the extension) so CMD should be failing. However, I've seen this undocumented behavior before - CMD secretly appends a ".*" to the name and looks for that. So TCC does that too.

The problem is that TCC is not expecting escaped characters here, so it's not unescaping the line before looking for the executable filename. I have fixed this for the next build.
 
Simple solution is to NOT assume that TCC is CMD compatible.
Don't use TCC to handle .bat or (even worse) .cmd files.
If you want TCC .btm files completed and executed in regular CMD or PS1 prompt, adjust %PATHEXT% variable and create an appropriate association. (FTYPE+ASSOC)
 
Is there a way to MAKE TCC use CMD to run a .BAT file? I tried an executable extension,
Code:
.bat=c:\windows\system32\cmd.exe /d /s /c
but TCC ran them anyway.
 
Thanks to everyone for all your suggestions. Honestly, the best thing about TCC is its active support forum.

I think your suggestions would work if I were trying to run a batch file from the command-line. But, in the particular case I mentioned above, I'm running an executable. Eventually, the executable - either directly or through a batch file - spawns a process to COMSPEC, using the standard cmd options of /d /s /c.

So, in this case, anything using PATHEXT or file associations will not work.

So, there are only two possible solutions:
  1. Explicitly set COMSPEC
  2. Do not use TCC

As I said in the beginning, I LOVE TCC/TCMD. I do NOT expect it be CMD compatible. I DO wish it adhered closer to CMD's quote/string handling of command arguments. And I DO wish it did not override the common /s parameter so that it disables the interrupt handler.

I guess I'm just hoping JPSoft will consider this in some future version of TCC.

Thanks, again, all.
 
So, in this case, anything using PATHEXT or file associations will not work.

So, there are only two possible solutions:
  1. Explicitly set COMSPEC
  2. Do not use TCC

In that case, I'd vote for option #1. Use an alias to intercept the command; point COMSPEC at CMD.EXE, run the executable, and reset COMSPEC when it exits.
 
Is there a way to MAKE TCC use CMD to run a .BAT file? I tried an executable extension,
Code:
.bat=c:\windows\system32\cmd.exe /d /s /c
but TCC ran them anyway.

You need to use PATHEXT for this approach to work.

(Note that you not only need to remove .BAT and/or .CMD from PATHEXT, but also to add .BTM to it. The PATHEXT variable that TCC inherits from Windows does not include .BTM.)
 
The problem is that TCC is not expecting escaped characters here, so it's not unescaping the line before looking for the executable filename. I have fixed this for the next build.

@rconn, I did not see your reply until after I posted my last message. Sorry. I look forward to the new release. Thanks! After the new release, if I re-run that JS library's unittests under TCC, I hope it's okay if it post again with any significant issues.
Just know that the /s may still be a problem if all child processes spawned by in NodeJS code use it.

Thanks again.
 
You need to use PATHEXT for this approach to work.

(Note that you not only need to remove .BAT and/or .CMD from PATHEXT, but also to add .BTM to it. The PATHEXT variable that TCC inherits from Windows does not include .BTM.)
That doesn't help. AFAICT, if you put "name.bat" on TCC's command line and name.bat exists, TCC will run it.
Code:
v:\> set pathext
.BTM;.COM;.EXE;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.py;.pyw

v:\> set .bat
c:\windows\system32\cmd.exe /d /s /c

v:\> type myver.bat
ver

v:\> myver.bat

TCC  24.02.42   Windows 7 [Version 6.1.7601]
 
That doesn't help. AFAICT, if you put "name.bat" on TCC's command line and name.bat exists, TCC will run it.
Code:
v:\> set pathext
.BTM;.COM;.EXE;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.py;.pyw

v:\> set .bat
c:\windows\system32\cmd.exe /d /s /c

v:\> type myver.bat
ver

v:\> myver.bat

TCC  24.02.42   Windows 7 [Version 6.1.7601]

You also need to
Code:
option //pathext=yes
Otherwise, TCC ignores that variable.
 
You also need to
Code:
option //pathext=yes
Otherwise, TCC ignores that variable.
Got that already.
Code:
v:\> set pathext
.BTM;.COM;.EXE;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.py;.pyw

v:\> set .bat
c:\windows\system32\cmd.exe /d /s /c

v:\> option pathext
pathext=Yes

v:\> type myver.bat
@echo off
ver
pause

v:\> myver.bat

TCC  24.02.42   Windows 7 [Version 6.1.7601]
Press any key when ready...

But if I don't include the extension ...
Code:
v:\> myver

Microsoft Windows [Version 6.1.7601]
Press any key to continue . . .
 
Perhaps that (my recent posts) might help Mel Davis ... because in his original example, the BATfile was invoked without an extension . With .BAT missing from PATHEXT, an executable extension for .BAT (using CMD), option //pathext=Yes, and the extension missing from the BATfile's invocation, CMD will run it.

Code:
v:\> set pathext
.BTM;.COM;.EXE;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.py;.pyw

v:\> set .bat
c:\windows\system32\cmd.exe /d /s /c

v:\> type myver.bat
@echo off
ver
pause

v:\> set comspec
G:\tc24\TCC.EXE

v:\> %comspec /d /s /c myver

Microsoft Windows [Version 6.1.7601]
Press any key to continue . . .
 
If you have the CMDBatch directive enabled in TCMD.INI, TCC will pass all .BAT and .CMD files to CMD for execution.

Typical. I spend an hour putzing around with the complicated way, and completely overlook the simple way!
 

Similar threads

Back
Top