WAD Odd behaviour with command-line arguments on TCMD.

[mfarah]

There's an odd behaviour about the command-line arguments that are passed to some external programs.

1- Start a TCC window by itself. Invoke the TSEPro text editor to edit three files (a.txt, b.txt, c.txt). TSEPro will start and it will load the three files.
2- Start TCMD, with a TCC window inside it. Invoke the TSEPro editor to edit three files (a.txt, b.txt, c.txt). It will start and will attempt to load a single file, called "a.txt b.txt c.txt".
3- Detach the TCC window from TCMD. Repeat the command above. It will work as in step 1.
4- Reattach either TCC window back to TCMD. Repeat the command above. It will work as in step 2.

Yes, I took out all plugins, aliases, TCMD.INI, etcetera.

I've just tested this with TCMD 20.10.30 and even by attaching a TCC 20.11.37 window to it. Yesterday night, I tried this on TCMD 19 as well (but not as thoroughly as right now) and got the same results.

This issue also applies to redirection. "dir | g32" in an independent TCC window works as expected; but in an attached one doesn't.

Replace the editor (TSEPro) with Notepad++... and the problem disappears. Everything works as expected. View, less, more, and several other commands don't have any problems, either.

I think there's a combination of issues here, where part of the problem may be that TSEPro is expecting the command-line parameters in an "old way", so to speak, but I find it really odd that the behaviour differs on whether TCC is inside TCMD or not.

Just for kicks, I just tried this with CMD instead of TCC. CMD attached to TCMD exhibits the same issue.


Some environment data, just in case:

TCC 20.10.30 x64 Windows 10 [Version 6.3.14393]
TCC Build 30 Windows 10 Build 14393

TCC 20.11.37 x64 Windows 10 [Version 6.3.14393]
TCC Build 37 Windows 10 Build 14393

 

[vefatica]

My first thought is "that's impossible", since in both cases, it's TCC invoking the editor.

How do you invoke the editor? ... by name? ... "TSEPro a.txt b.txt c.txt"?

Use TaskMgr to look at TSEPro's command line. Is it different in the two cases?

 

[mfarah]

TaskMgr was no help, but Process Explorer let me see the command line as it was passed. In both cases it's:

CMDLINE C:\LDC\TSEPro\g32.exe everything_license.txt license.txt readme.txt

Call g32.exe within TCMD, and end up editing a single file called "everything_license.txt license.txt readme.txt".

 

[vefatica]

So TSEPro acts in two ways with the same command line? Quite odd! In the two scenarios, is the command given at a TCC prompt ... alias ... TCMD button ... TCMD run ... ?

 

[mfarah]

So TSEPro acts in two ways with the same command line? Quite odd! In the two scenarios, is the command given at a TCC prompt ... alias ... TCMD button ... TCMD run ... ?

I made sure to get rid of all plugins, customizations, et cetera. I executed the command from the command line itself. The oddest thing is that the same problem affects CMD if it's running attached to TCMD - this is what makes me suspect that the problem lies somewhere in TCMD's handling of the arguments.

 

[vefatica]

If you're giving the command to TCC (likewise CMD), TCMD should have nothing to do with it, regardless of whether or not it's in a tab. I don't believe TCMD is "handling the arguments". Try again to see the command lines with TaskMgr. You'll have to add the command line column to TaskMgr.

 

[mfarah]

I looked at it again with TaskMgr. Both command lines look exactly the same (I started TCMD, executed my command, got the "improper behaviour", detached the TCC window, pressed Up-Arrow, Enter to repeat the command, got the proper behaviour).

It DOES call my attention that in both cases, the executable is not quoted (compare to the third instance of g32.exe, which was started by clicking its icon on the desktop bar). I wonder if that's got to do anything with it.

 

[rconn]

It's not a TCC bug. External apps are always started exactly the same way, whether from a console session or a TCC tab.

IIRC, this was reported several years ago (also with TSE). It turned out that TSE behaved differently depending on whether it thought it was being started from the command line or from a GUI app. You might want to check with the TSE developers.