tcc /c "[...]" fails when run from third party terminal

[thorsten]

Hi,

I normally run TCC from ConEmu/FAR Manager[1]. FAR has a command prompt. FAR passes the commands to ComSpec via '%ComSpec% /c "command"'.

So when I execute "alias where" in FAR, FAR runs TCC and I see the result in FAR's terminal. This also works when I run FAR in conjunction with Console Emulator.

Console Emulator has a FAR plugin which enables tighter integration between FAR and Console Emulator[2]. When I load the plugin, commands like "alias where" start failing in FAR:

> alias where
TCC: Unknown command "alias where"

I reported this as a bug to the developer of Console Emulator. He replied that this is not a bug in the Console Emulator plugin ("Where is a bug?") but in TCC(!) because when I run ("from Windows")

[Win+R] tcc.exe /C "alias where" & cmd

it also fails with "TCC: Unknown command "alias where"".

I replied "Whatever the plugin does, it makes the commands fail that work without the plugin. This is obviously a bug."

Can anyone offer some insight into this issue?

Thorsten
[1] http://jpsoft.com/blogs/2012/04/windows-console-replacements-part-6-take-command-and-conemu/
[2] https://code.google.com/p/conemu-maximus5/wiki/ConEmuFarPlugin#ConEmu

 

[samintz]

I'm running TCC v15.01.52 and I get expected behavior.

TCC: Not an alias "where"

Try running your command without the quotes:

tcc /c alias where

It's possible that the version of TCC you are running is trying to run "alias where" as opposed to ALIAS with an argument of "where".
-Scott

 

[Steve Fabian]

Scott, I think you found the issue. TCC does not expect the whole command line to be quoted, which is the reason the failing command is shown as "alias where". The author of the FAR plugin did not test a valid invocation of TCC with Win+R:
tcc /c alias where
does not fail! FAR should give the user the option whether or not to quote the command line to be passed, so the TCC command it passes should look like:
%ComSpec% /c alias where

Of course, starting and stopping TCC (and all its DLLs) for each command you want to execute is not only very inefficient, but prevents you from using the start-up options you find in TCMD Help / TCC / Starting TCC / TCC Startup Options; some of them you can emulate in the default TCMD.INI, some others in TCSTART.BTM. Furthermore, since each invocation starts with the same bare environment passed by Windows or by ConEmu, results of a command are not available in subsequent commands.

 

[Charles Dye]

CMD.EXE has a fairly whimsical set of rules for deciding whether to strip or retain leading/trailing quote marks on its startup command line. Type CMD /?, hit Enter and then press the spacebar once to see the executive summary.

Should TCC.EXE emulate this Rube Goldberg behavior?

 

[Steve Fabian]

CMD.EXE has a fairly whimsical set of rules for deciding whether to strip or retain leading/trailing quote marks on its startup command line. ... Should TCC.EXE emulate this Rube Goldberg behavior?

Absolutely NOT as default, though when Duplicate CMD bugs is selected, some may find it useful. While the CMD rules you referenced are not totally nonsensical (they seemed designed to retain quotation marks around one single LFN containing white space but without parentheses or other special characters in the filename, and no additional quoted strings in the command line), they are still incapable of passing many other potential strings to the TCC command specified. If in fact the OP wanted TCC to execute a batch file whose name contains white space, with a parameter string, the command format would be (e.g. to invoke TCC from a RUN box) %ComSpec% /c "lfn with space" parameter

 

[rconn]

CMD.EXE has a fairly whimsical set of rules for deciding whether to strip or retain leading/trailing quote marks on its startup command line. Type CMD /?, hit Enter and then press the spacebar once to see the executive summary.

Should TCC.EXE emulate this Rube Goldberg behavior?

Actually, TCC does emulate most of the (bizarro) CMD behavior with multiple quotes (mostly in the wrong places) on the startup command line. This one particularly twisted syntax of quoting part of the command line and arguments (for no reason; it works fine without the quotes) is not supported. This is WAD; I decided long ago that this particular unnecessary syntax would create problems with supporting otherwise valid command lines.

 

[thorsten]

I'm running TCC v15.01.52 and I get expected behavior.

TCC: Not an alias "where"

Try running your command without the quotes:

tcc /c alias where

It's possible that the version of TCC you are running is trying to run "alias where" as opposed to ALIAS with an argument of "where".
-Scott

I don't run the command in quotes. That's FAR functionality. And it works without the plugin.

 

[thorsten]

Actually, TCC does emulate most of the (bizarro) CMD behavior with multiple quotes (mostly in the wrong places) on the startup command line. This one particularly twisted syntax of quoting part of the command line and arguments (for no reason; it works fine without the quotes) is not supported. This is WAD; I decided long ago that this particular unnecessary syntax would create problems with supporting otherwise valid command lines.

Is there any particular reason, why 'tcc /c "alias whatever"' works from a Take Command terminal but not when run via the Windows run dialogue? It also baffles me that 'tcc /k "alias whatever"' works (but not /c).

 

[vefatica]

Is there any particular reason, why 'tcc /c "alias whatever"' works from a Take Command terminal but not when run via the Windows run dialogue? It also baffles me that 'tcc /k "alias whatever"' works (but not /c).

That would depend on how and when you load your aliases. If they're always loaded (SHRALIAS is running and you use global aliases) or you *always* load them in TCSTART.BTM, both should work. If you exit TCSTART.BTM before loading aliases in transient (/C) instances then I'd expect the behavior you mention.

 

[Steve Fabian]

Loading of aliases ought not to be relevant. As Scott showed, if the TCC command alias is executed at all, it would display either the Not an alias "where" error message, or expand the alias, instead of the actual error report indicating the quote marks having caused a syntax error: the whole command line being considered to be the command itself. I would think that this would cause havoc with externals (other executables) expecting parameters. Without having either ConEmu or the FAR plugin I cannot perform meaningful tests...

 

[vefatica]

I misunderstood his question. I do not see a difference. From the run dialog, both

TCC /K "alias whatever"

and

TCC /C "alias whatever"

result in

TCC: Not an alias "whatever"

Occasionally, in the second case, the console disappears so quickly that I don't see the output. It's easier to see if I

TCC /C "alias whatever" & pause

 

[Charles Dye]

It might be useful to add a Debug=3 to the .INI file to see exactly what the command tail passed to TCC is.