- Aug
- 1
- 0
I’m trying to fix a vendor’s program that has CMD.EXE hard-coded as the command processor by writing a simple C shell program that merely passes command line parameters to whatever command processor is specified in the Windows COMSPEC environment variable. As a test, I wrote a simple program that uses getenv() to get COMSPEC and printf() to display it. Running it at a CMD.EXE prompt I get C:\Windows\system32\cmd.exe as expected. Running it at a TCC.EXE prompt I get the name of my own program rather than the path of the TCC executable. This happens under both the full version Take Command 14 and TCC/LE 13.
At the TCC command prompt, executing a SET command displays the correct value for COMSPEC.
I have compiled the program in both Watcom Open C/C++ and Borland C/C++ and get the same results with both of them so I can’t see this being a compiler bug. I could see it being a Windows bug or some setting that I need to change. I suppose it could even be a programming error on my part although the program is ridiculously simple (that’s often when I make mistakes <sigh>).
Anyone know why this might be happening?
At the TCC command prompt, executing a SET command displays the correct value for COMSPEC.
Code:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *comspec;
comspec = getenv("COMSPEC");
printf("COMSPEC = %s\n",comspec);
return 0;
}
I have compiled the program in both Watcom Open C/C++ and Borland C/C++ and get the same results with both of them so I can’t see this being a compiler bug. I could see it being a Windows bug or some setting that I need to change. I suppose it could even be a programming error on my part although the program is ridiculously simple (that’s often when I make mistakes <sigh>).
Anyone know why this might be happening?