WAD The /@ and // arguments to TCMD.EXE have no decernable effect.

Apr 13, 2010
236
3
58
The Hague
#1
Caveat TCMD.exe NOT tcc.exe.

The path in second line of the help text also seems a unnescesary wacky:

Code:
"c:\program files\jpsoft\tcmd17tcmd1\tcmd.exe" @c:\tcmd\tcmd.ini
Anyhow, the host app seems to ignore any attempt to point it to a certain ini-file and/or any option values.

Regards, DJ
 
#3
They also work in combination, at a command line, when pasted into the Start\Run dialog, and when pasted into the target of a shortcut.
Code:
v:\> g:\tc18\tcmd.exe /@t:\alt.ini //tabs=bottom
 
Apr 13, 2010
236
3
58
The Hague
#4
I would say: exactly that, Vince. But I gather it works on your side, so what am I doing differently? Hmmm.
I was trying
"C:\Program Files\JPSoft\TCMD18x64\tcmd.exe" /@J:\bin\tcmd\USB.INI
I added some echoes to TCStart and it appears that TC keeps reading my INI file in the %LOCALAPPDATA\JPSoft\ location.
So, because I want TC to use another TCStart.btm, I thought I'd force it by using //TCStartPath=J:\Bat
to no avail.
That might make some sense, if the default INI file is overriding the cmdline args, but that can't be the case, can it?

Regards, DJ
 
#5
TCMD may use the alternate INI file. The TCStartPath specification is meaningless to TCMD. TCC.EXE will find its INI file by the documented means. You'll need to start TCMD with a command that starts TCC with an alternative startup configuration.

This (rather kludgy) works at a command line.
Code:
g:\tc18\tcmd.exe /c start /tab g:\tc18\tcc.exe //TCStartPath=t:\
But this does not.
Code:
g:\tc18\tcmd.exe /c start /tab g:\tc18\tcc.exe /@t:\alt.ini
TCMD itself uses the INI spec and does not pass it to the TCC command line. That may be a bug. I worked around it like this:
Code:
g:\tc18\tcmd.exe /c start /tab g:\tc18\tcc.exe ^^/@t:\alt.ini
I don't know how that would work from Start\Run or a shortcut target.
 
Apr 13, 2010
236
3
58
The Hague
#7
TCMD may use the alternate INI file. The TCStartPath specification is meaningless to TCMD. TCC.EXE will find its INI file by the documented means. You'll need to start TCMD with a command that starts TCC with an alternative startup configuration.
That, my friend, is a very insightful answer. Thank you.

I would never have thought of TCMD not passing on the ini-file to its console. The fact that it might have multiple consoles probably had something to do with that. Of course today I would propose a rule like "If no tabs defined, pass on to first default tab.", but I must confess that I'm not sure if I would still be happy with that rule next month. How about making option overrides at tcmd level global to all hosted consoles?

In my world, you have builtins, overridden by conf files, overridden by cmdline options, overridden by user interaction. I like that. A lot. Ignoring or suppressing conf-files seems at odds with that natural order of things. Or is that why that guy with the white coat is pointing a syringe at me?

Anyway, not kludgy, we have a workaround.

Regards, DJ.
 
#8
It's not TCMD's console. And TCMD can run nearly any console app. That includes versions of TCC.EXE that go way back (even the now ancient 4NT.EXE). Passing on the INI file would be a disaster. There might be less confusion if there were two INI files, one for TCMD and one for TCC.
 
Apr 13, 2010
236
3
58
The Hague
#9
Yes! So, not only can TCMD host multiple TCC consoles, it can also host older versions of TCC and other third-party consoles (e.g. cmd, powershell, bash).

I have always found it odd that the help doesn't describe how to do that. I even believe I remember seeing a picture of TCMD running bash. And yet, no how-to.

And what is the use of being able to run old versions of TCC within the latest version of TCMD if TCC and TCMD cannot be installed independently? TCC is not a single executable. If I could, I would install the latest TCMD and subsequently all the older TCC's I wanted to test my updates against. I can see it all before me. Run a batch which opens a set set of different consoles within 1 unified environment. Run another to kick-off the same tests in each of them. I would like that. But since each version of TCC inseparably comes with its own TCMD, why bother?

DJ.
 
May 20, 2009
232
1
54
ITALY
#10
Yes! So, not only can TCMD host multiple TCC consoles, it can also host older versions of TCC and other third-party consoles (e.g. cmd, powershell, bash).

I have always found it odd that the help doesn't describe how to do that. I even believe I remember seeing a picture of TCMD running bash. And yet, no how-to.

And what is the use of being able to run old versions of TCC within the latest version of TCMD if TCC and TCMD cannot be installed independently? TCC is not a single executable. If I could, I would install the latest TCMD and subsequently all the older TCC's I wanted to test my updates against. I can see it all before me. Run a batch which opens a set set of different consoles within 1 unified environment. Run another to kick-off the same tests in each of them. I would like that. But since each version of TCC inseparably comes with its own TCMD, why bother?

DJ.
I do not use TCMD, only TCC.
But, I believe that You might try this.
Install each version of the complete package in its own directory.
So, for example, TCMD&TCC version 18 in "C:\Program Files\V18", and so on for others.
Then, You do not care of others TCMD.
You use only the latest one.
And in TCMD v18 You add a tab that points to "C:\Program Files\V17\TCC.exe".
Does it work for You?


Regards

Rodolfo Giovanninetti
 
Apr 13, 2010
236
3
58
The Hague
#11
Thank you for your trouble, Rodolfo, but you misunderstood my previous posting. I know one could simply ignore all the other parts of each version and use only the tcc-part. I am sure it can be done. Although it will be more convoluted than you seem to think. E.g. if your test would rely on some feature of TPIPE you would have to make sure that each console runs *its* version of TPIPE and not accidentally one of the other versions. Think about it..

But again, this was not the problem I was trying to solve.

Vince helped me realize that TCMD.exe only acts on directives in the [TakeCommand] section of the INI-file and likewise TCC only on the directives in the [4NT] section. Moreover, overriding TCMD's standard search for an INI-file by providing it on the command line with /@D:\path\file.ini --- does not prevent TCC.exe to do its own search for any ini-files, possibly finding a completely different ini-file.

Thank you for reminding me that this forum is intended for practical support. I will perhaps move my more philosophical questions to the open forum.
Regards, DJ.