Welcome!

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

SignUp Now!

Problem with comspec in TC 10.00.76

Hi,

Two days ago I upgraded from TC 10.00.52 (I think) to 10.00.76. Since this upgrade I'm having the problem that the compspec variable is not parsed correctly if it contains spaces. The actual problem occurs by calling system() from my own C++ app but it can be simulated by typing the following from a TCC command line:

%comspec% dir

This fails with the error

TCC: Unknown command "D:\Program"

The error caused by the call to system() in the C++ app is actually different:

TCC: Unknown command "Files\JPSoft\TCMD10\TCC.EXE"

which I suppose has something to do with the number of arguments or something.

Of course in a command prompt or batch file I can simply put quotes around it like this:

"%comspec%" dir

and it will work fine but in my C++ program I'm simply calling it like this

system("dir");

hence I have no control over the way the comspec variable is passed to and parsed by TCC.

All this worked fine with TCC 10.00.52 so I assume something has changed since then.

I tried changing the definition for compspec from the default

D:\Program Files\JPSoft\TCMD10\TCC.EXE

to

"D:\Program Files\JPSoft\TCMD10\TCC.EXE"

but it does not make any difference, the quotes I added seem to get parsed out by TCC if you use it on the command prompt. The SET command does confirm that it is stored with quotes after this change.

Is this something that could be fixed with the next update? Or is there some other workaround?

Thanks,
Arjan
 
IMHO this is the often encountered square peg in a round hole problem.
It is an attempt to use a file-system or operating-system related call via
an ISO standard C or C++ library on a MS Windows platform, and expecting to
be able to access files whose names do not conform to the libraries' rules.
The "system" call is intended for the POSIX environment only, and is just
one of the multitude of such calls that may fail when the value of
environment variable COMPSPEC contains spaces or any of a number of other
characters available in NTFS but not in a POSIX file system.
Simple solution: install all programs that may be called by other
programs (in this instance, TCC.EXE) so their pathnames are POSIX
compatible. Or you can just use TCC to create a junction to its installation
directory with a POSIX-compatible name, and use that name.
--
HTH, Steve
 
On Tue, 13 Oct 2009 07:53:50 -0500, Arjan van Gog <> wrote:

|The error caused by the call to system() in the C++ app is actually different:
|
|*TCC: Unknown command "Files\JPSoft\TCMD10\TCC.EXE"*

Steve, Rex, do you know what's happening here? Apparently TCC **is** started,
so I imagine system() gets the program name right. But, it would seem it's
started with a command line like

"c:\program files\jpsoft\tcmd10\tcc.exe" files\jpsoft\tcmd10\tcc.exe /c ...

which seems rather dumb on the part of the runtime library.
--
- Vince
 
Two days ago I upgraded from TC 10.00.52 (I think) to 10.00.76. Since this upgrade I'm having the problem that the compspec variable is not parsed correctly if it contains spaces. The actual problem occurs by calling system() from my own C++ app but it can be simulated by typing the following from a TCC command line:

I suggest adding a line to your TCSTART.BTM file:

Code:
set comspec=%@sfn[%_cmdspec]

Next time, if it's not inconvenient, consider installing in a path without spaces....
 
vefatica wrote:
|Arjan van Gog wrote:
||
|| The error caused by the call to system() in the C++ app is actually
|| different:
||
|| *TCC: Unknown command "Files\JPSoft\TCMD10\TCC.EXE"*
|
| Steve, Rex, do you know what's happening here? Apparently TCC
| **is** started, so I imagine system() gets the program name right.
| But, it would seem it's started with a command line like
|
| "c:\program files\jpsoft\tcmd10\tcc.exe" files\jpsoft\tcmd10\tcc.exe
| /c ...
|
| which seems rather dumb on the part of the runtime library.

I am not so certain the new instance of TCC was actually started (with an
incorrect command line), or that it was getting back into the parent-TCC.
One would need to know the RTL linked into the OP's .EXE which makes the
actual call to "system". It's plainly a mismatch between the "system"
function in the RTL and the file system.

Arjan, which compiler and linker created your application?
--
Steve
 
I suggest adding a line to your TCSTART.BTM file:

Code:
set comspec=%@sfn[%_cmdspec]

Thanks, I may use that as a workaround.

Next time, if it's not inconvenient, consider installing in a path without spaces....
I suppose I could do that but keep in mind that "Program Files' is the default root installation folder for programs on US Windows versions and is correctly used as such by TC Setup. I did not put that space in there :)
 
Arjan van Gog wrote:
| ---Quote (Originally by Charles Dye)---
|| Next time, if it's not inconvenient, consider installing in a path
|| without spaces....
|---End Quote---
| I suppose I could do that but keep in mind that "Program Files' is
| the default root installation folder for programs on US Windows
| versions and is correctly used as such by TC Setup. I did not put
| that space in there :)

As I wrote in my other post, the issue is a mismatch between your
application and the OS. Until all programs and libraries are built around
the DWIM parsers Rex always writes about, you need to work around such
mismatches. Unfortunately when a giant forces vendors such as JP Software to
choose either the "windows certified" endorsement or a default installation
path which allows ease of use of their prodcts with other,
standard-compliant (but likely not MS certified) products, the customer
ultimately looses. As long as we have the choice where to install, it is
only a minor inconvenience during the first installation of a new version,
if you always use the built-in updater. Before there was a "standard
location",we always had to specify where we want the software, didn't we?
--
Steve
 
vefatica wrote:
I am not so certain the new instance of TCC was actually started (with an
incorrect command line), or that it was getting back into the parent-TCC.
One would need to know the RTL linked into the OP's .EXE which makes the
actual call to "system". It's plainly a mismatch between the "system"
function in the RTL and the file system.

Arjan, which compiler and linker created your application?
--
Steve

Visual Studio 2008. I traced the call to
Code:
system("copy /b "setup.exe" tempfile.dat");
through the CRT upto the point in dospawn.c where it calls the actual Win32 API:
Code:
        CreateProcessStatus = CreateProcess("D:\Program Files\JPSoft\TCMD10\TCC.EXE",
                                             "D:\Program Files\JPSoft\TCMD10\TCC.EXE /c copy /b \"setup.exe\" tempfile.dat",
                                             NULL,
                                             NULL,
                                             TRUE,
                                             fdwCreate,
                                             envblk,
                                             NULL,
                                             &StartupInfo,
                                             &ProcessInformation
                                           );
The \" of course indicates that there is an actual " character in the string passed as an argument, there's no backslash + quote :)

It appears that TCC used to contain some clever code that was able to compare the argv[] values to its own filename and was able to figure out that it had to start at, in this case, argv[2] because argv[0] and argv[1] contain its own name in two parts. Or perhaps it used or uses GetCommandLine() and does its own parsing.

Incidentally I just verified by re-installing 10.0.52 that if I include quotes in the actual definition of comspec itself in 10.0.52 I can write
Code:
%comspec% dir
and it would work. The new version 10.0.76 parses away those quotes and the same command fails (if there is a space in the comspec).

Also with version 10.0.52 my C++ application works fine again.

Sure would be nice if this could work the way it did in 10.0.52.
 
If you run Process Explorer while running your app, you should be able to
see the actual command line being passed.

-Scott

vefatica <> wrote on 10/13/2009 10:01:26 AM:


> On Tue, 13 Oct 2009 07:53:50 -0500, Arjan van Gog <> wrote:
>
> |The error caused by the call to system() in the C++ app is
actuallydifferent:

> |
> |*TCC: Unknown command "Files\JPSoft\TCMD10\TCC.EXE"*
>
> Steve, Rex, do you know what's happening here? Apparently TCC **is**
started,

> so I imagine system() gets the program name right. But, it would seem
it's

> started with a command line like
>
> "c:\program files\jpsoft\tcmd10\tcc.exe" files\jpsoft\tcmd10\tcc.exe /c
...

>
> which seems rather dumb on the part of the runtime library.
> --
> - Vince
>
>
 

Similar threads

Back
Top