X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Date: 19 Feb 2004 08:32:41 +0200 Message-Id: From: Eli Zaretskii To: djgpp AT delorie DOT com In-reply-to: (roger.gay@shaw.ca) Subject: Re: W2K, Environment, system(), (and MAKE) References: Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Roger S Gay" > Newsgroups: comp.os.msdos.djgpp > Date: Thu, 19 Feb 2004 02:45:48 GMT > > In W2K, a MSDOS box is implemented as the program CMD.EXE. Close, but not entirely true. On the NT family of Windows (NT, W2K and Windows XP), the DOS box is implemented as NTVDM, the NT Virtual DOS Machine, which starts cmd.exe as the shell. > While running > this program one may issue "SET" which lists the environment variables and > their settings, and which shows me > > ComSpec=C:\WINDOWS\system32\cmd.exe > > however a dump of the environ variable from a running C program shows > > COMSPEC=C:\WINDOWS\SYSTEM32\COMMAND.COM > > COMSPEC is listed first with the remaining variables in two > alphabetically ordered lists, including those which should > precede it. All variable names are in uppercase, not the mixed case > shown by SET. A GETENV("ComSpec") call returns a null pointer. Correct. This is MS Big Brother deciding for you what you want. Their logic is that a DOS program that runs on Windows expects a DOS-like shell and DOS-like all-caps environment variables. So when a DOS program is invoked, Windows modifies COMSPEC to point to COMMAND.COM, upcases all the other environment variables, and stuffs all that down your program's throat. > Now, I am a very occasional user of system(...) but MAKE calls it > frequently on my behalf, and of course COMMAND.COM gets invoked. Not true: the DJGPP port of Make will only invoke the system shell, be it COMMAND.COM or CMD.EXE, only when it cannot emulate their functionality. In practice, that means the shell is invoked to run batch files and commands that are built into the shell that don't have a .exe file on PATH with the same name. For example, if you invoke DIR and you have GNU Fileutils installed which bring you dir.exe, Make will invoke dir.exe, not the shell's built-in. In general, Make refrains from calling the system shell as much as it can, precisely because of the kind of mess like the one you face. As a bonus, emulation of shell features like redirection and pipes gives us features like forward slashes in shell commands and better quoting support that the DOS/Windows shells don't have. > Under W2K COMMAND.COM is somewhat of a second class citizen. In particular > the PATH is not set from W2K's list of settings, but is set instead > from AUTOEXEC.NT. Are you sure? I just checked this on the nearest XP box, and I see different results: the value of PATH passed to DJGPP programs is the same as I see in CMD.EXE, but with names of all directories converted to their 8+3 short aliases. I don't have autoexec.nt on that machine, so perhaps if you remove or rename yours, you will get around this misfeature. Or maybe this is something they've improved on XP, I don't know. > System() is documented as being able to determine that the command given > will invoke a .BAT script. CMD.EXE prefers a .CMD suffix. Is system() > sensitive to this? `system' doesn't know about the .cmd extensions, it only knows about .bat and .btm. If you must run the batch file via cmd.exe (i.e. if you are certain that COMMAND.COM will not be able to run it), you will have to either set SHELL (or MAKESHELL, if this is for Make alone), or invoke cmd.exe explicitly, like this: cmd.exe /c foo.cmd If COMMAND.COM can run that batch file, I suggest to rename it to a .bat extension and be done. > Could it or should it be made so? It could, but given the mess whose iceberg's tip you've just described, I'm not sure it should. > Is it possible that the install instructions, particularly those on the > zip-picker page could emphasize the importance of setting up a correct path > in AUTOEXEC.NT I believe this is already mentioned somewhere. > and the desirability of setting the SHELL environment variable > if the user has specified W2K (or XP) as his OS. I'm not sure we should tell users about this. Please try the suggestions above and see if there's an easier way out.