Welcome!

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

SignUp Now!

Command grouping differs from cmd?

CaptainFlint

CaptainFlint

Jan
3
0
I'm trying to make the acquaintance of TCC/LE by using it everywhere instead of cmd.exe. However, when I tried to create Windows SDK environment by calling its setenv.cmd with needed parameters, it worked wrong. I found out that the following block of code from setenv.cmd is interpreted differently in cmd.exe and TCC/LE:
Code: 
IF "x%TARGET_CPU%x"=="xx" (
IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86"
IF /I "%PROCESSOR_ARCHITEW6432%"=="x86" SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86"
IF /I "%PROCESSOR_ARCHITECTURE%"=="AMD64" SET "TARGET_CPU=x64" & SET "CURRENT_CPU=x64"
rem ...and some more similar lines...
GOTO Parse_Args
)

When I turned on printing of commands I saw that TCC/LE combined all of the lines within the command group in parentheses with the "&" operator, so that it looked like follows:
Code: 
IF "x%TARGET_CPU%x"=="xx" (
IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86" &
IF /I "%PROCESSOR_ARCHITEW6432%"=="x86" SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86" &
IF /I "%PROCESSOR_ARCHITECTURE%"=="AMD64" SET "TARGET_CPU=x64" & SET "CURRENT_CPU=x64" &
...
Of course, this code becomes absolutely wrong! As a consequence, the variables are not set correctly, and the environment becomes inconsistent, making it impossible to build aplications.

Could anybody please tell me what's wrong here? Did I miss some option? ("Duplicate CMD.EXE bugs" is turned on.) Or is it a bug of TCC/LE?
 
Assuming that TCC/LE has the "Iff" command (I don't have TCC/LE so I don't know), replace the first IF by:

IFF "x%TARGET_CPU%x"=="xx" Then

and put either an 'EndIff" or an "Else" (or even "ElseIff", I don't have the full script here, of course) at the bottom of code that should be executed should the TARGET_CPU be null.

And it's only a "bug" if you consider an incompatibility between TCC and CMD.exe to be a "bug". However, Rex invented his syntax for a multiline "True" or "False" clause long before CMD.exe had any such thing and he did it differently than CMD.exe ultimately did, and I would imagine that trying to change it now would be virtually impossible because it would break thousands of scripts that people have already written.
 
Thank you for the reply. I understand that there are different ways I could change the batch file so that it worked correctly with TCC, but that's not the point. What I'm trying to do eventually, is to replace COMSPEC with TCC/LE (and later, maybe, with TCC). However, with the problem I described, such replacement became totally impossible. You cannot expect users to manually check and adapt each and every batch file whenever they install (or update) a new third-party application which contains some BAT/CMD-files. I want to use the improvements TCC gives me over CMD, but at the same time I don't want to lose confidence in operability of existing tools. For instance, I spent about 4 hours debugging this specific situation: I was trying to build the newly released Qt5 from sources, and each time got very strange compilation errors, until it struck me to check in plain cmd.exe, and all the errors immediately went away, because (as I found later) the environment setting batch worked differently in TCC/LE and CMD. Of course, now I will know about it and won't lose time before trying CMD, but each time any problem occurs I'll wonder whether it's a real problem or just another TCC-CMD incompatibility. It would be simpler to abandon TCC despite of all its advantages… :(

I respect the Rex'es priority in specific syntax implementation, but in real life CMD files are mostly written for CMD interpreter. It would be nice if TCC had some compatibility mode to emulate CMD behavior as exactly as possible. For example, this mode could be turned on automatically when running CMD scripts, and remain off when running BTM scripts. Or, since there is already an option "Duplicate CMD.EXE bugs", TCC could emulate the CMD's "IF" behavior when this option is turned on.
 
I understand and accept that (since I've had and used this program since Windows 3.1, that's not a problem I would have ever run into). And I totally agree that, given the present circumstances (which Rex could not have foretold), it would be nice if something (a switch, an option, a setting that only applies to the current batch file, etc.) could be put at the top of files of this nature to fix the problem easily. He could even go so far as to provide an option ("options" dialog) to make this the default behavior for .bat (not .btm) files (with something to turn it off (rather than on) that can be placed at the top of the .bat file). This would be similar to "Duplicate cmd.exe bugs".)
 
mathewsdw said:
He could even go so far as to provide an option ("options" dialog) to make this the default behavior for .bat (not .btm) files (with something to turn it off (rather than on) that can be placed at the top of the .bat file). This would be similar to "Duplicate cmd.exe bugs".)
Click to expand...

I can't speak for Rex, but.... You're talking about deep-seated parser behavior here. I suspect that dynamically changing it would be a pretty serious challenge.
 
Charles Dye said:
I can't speak for Rex, but.... You're talking about deep-seated parser behavior here. I suspect that dynamically changing it would be a pretty serious challenge.
Click to expand...
Serious in the sense that a complete imitator of the CMD parser would need to be written, but the dynamic switching itself (between the native and the CMD parser) would be relative simple - just invoke the currently selected parser. Switching within a single command ... now that would be a real challenge! Good thing is, I cannot conceive of a reason one would ever want to do that. I think that most JPsoft customers use .BTM extension for all of their TCC batch files, and restrict .BAT and .CMD extensions for files to be run by CMD.EXE (though I noticed that in the past Vince used .CMD or .BAT for TCC-only batch files).
 
Charles,

On one hand, I've actually written a full-fledged compiler for a "standard" high-level language completely by myself (yes, really), on the other hand between the facts that I don't know any details about Rex's implementation of the parser in his interpreter (and, as I've mentioned in the past, his language is greatly different in a number of significant ways (none bad) than any other high-level language I've ever encountered) and the fact that my memory is so bad I'm essentially incompetent at this point in my life I have no opinion on the matter. However, Rex probably wouldn't do it unless somebody presents the idea to him as a suggestion, and that's all I was trying to achieve. (I'm not going to put it into the "wish list" because I, personally, have no need for it.)

- Dan

P. S. One of the most major differences (which makes his language inherently not fully compilable to machine code) is the fact that variables can be created dynamically at run time given the fact that a variable can contain what ultimately is the name of another variable, and that that variable can ultimately be evaluated is one of the primary differences between his language and any other high-level language I've ever heard of (although I'm not familiar with too many other scripting languages). Since the very existence of variables much less their memory addresses can not be determined at compile time this makes "full" compilation essentially impossible.
 
First, the base language is not Rex', it is IBM's, who paid Microsoft to develop the software for the original PC. In fact, there are only a few major additions to the language of COMMAND.COM: 1/ alias, 2/ variable function, and 3/ indirect variable: %[%x]. Simplified syntax, internal variables, added commands, added command options, even added features (such as NOCLOBBER) do not change the language. This does not detract from the value of all the TCC-only features, which make many tasks possible within TCC which CMD.EXE does not provide.

Second, the only thing that theoretically prevents a program to be fully compiled to machine code is dynamic self-modification. .BTM files (unless they contain the command LOADBTM OFF) are inherently incapable of such behavior, since they are loaded into TCC's memory workspace before execution of their first command. Indirect specification of variables does not by itself make a program uncompilable.
 
Steve Fabian said:
Serious in the sense that a complete imitator of the CMD parser would need to be written, but the dynamic switching itself (between the native and the CMD parser) would be relative simple - just invoke the currently selected parser. Switching within a single command ... now that would be a real challenge! Good thing is, I cannot conceive of a reason one would ever want to do that. I think that most JPsoft customers use .BTM extension for all of their TCC batch files, and restrict .BAT and .CMD extensions for files to be run by CMD.EXE (though I noticed that in the past Vince used .CMD or .BAT for TCC-only batch files).
Click to expand...
To be clear, I never used .CMD for anything. I used to use .BAT as a rule (20+ year habit) but it has been 10+ years since .BAT was associated with TCC (but then I almost never start any script via its association). Today, I only write BTMs. There are very few BATs from third parties here. The only two I'm aware of are the ones that set the environments for the VS08 and VS10 tools and they work OK under TCC. If any others are being used (by builds? or installs? or ...) then I suppose they're being run by CMD. I like the division of labor here. BATs and CMDs aren't mine and if anything runs them automatically, they're run under CMD. And, frankly, I don't give a @#$% about CMD compatibility.
 
Steve, first off, I'm not going to disagree with anything you say about MS DOS, I no longer remember/never really knew much about its history. (I came from the Amiga).

Secondly, what you say depends on what you mean when one says "fully" compiled, and I was careful to use that word specifically because of its implications. And those are this: by my definition of that word the (possibly relative) addresses of variables can be determined at compile time and placed directly into the generated machine code without further ado. And if all variables are not known at compile time, that's obviously not possible and therefore the program is not fully compilable.
 
Sorry, Vince, seems like I have elephantine memory... but I did write "in the past" - it ought to have been "in the long past".

Dave, look in Wikipedia or anywhere else, you will find that first there was PC-DOS, 1.0 through 3.3, before there was MS-DOS. Likewise, first there was X-Window, and later there was MS Windows.

As to compilability, it is necessary that a program not be self-modifying, but not all of its variables need to be explicitly defined. I have used dynamic storage allocation in Fortan programs over 30 years ago. And I know of programs which generated source code during their execution, called the compiler, and linked to the just-compiled code. BTW, in the specific program the purpose was to speed up execution (by a 60 to 1 ratio) instead of interpreting the same code every time it was used.
 
Steve, again I'm going to disagree, and I think it's based on your definition of the word "defined" vs. mine. By "defined" I mean that the very existence (i.e., its name) and data type (most languages have data types) is known at compile time - not its ultimate storage address (although its offset from some identifiable storage location must be known). Very few compiled languages maintain a symbol table (where this information is kept) at run time except as debug information. TCC must inherently keep a symbol table that both exists and is rather frequently updated at run time. And this has absolutely nothing to do with "dynamic allocation", where the ultimate address of variables is not known but their offset from a known address (the address of the "gotten storage) is known at compile time. And the fact that one program generates source code that is compiled by a compiler changes nothing, all variables must still be defined (as above) at compile time. (I started out as an IBM mainframe assembler programmer almost 40 years ago, the compiler that I wrote that I mentioned was written in IBM mainframe assembly language, this is a subject where I know whereof I speak.)
 
As a humorous aside, since I was thinking in terms of compiled languages/code when I wrote the above it didn't occur to me that of course the above is completely correct for TCC. TCC's "symbol table" is the "environment" where environment variables are kept, and of course TCC searches it looking for environment variables whenever a variable is referenced (except in a few special cases - like the "For" verb as I remember where an explicit environment variable is not created at all).
 
CaptainFlint said:
I'm trying to make the acquaintance of TCC/LE by using it everywhere instead of cmd.exe. However, when I tried to create Windows SDK environment by calling its setenv.cmd with needed parameters, it worked wrong. I found out that the following block of code from setenv.cmd is interpreted differently in cmd.exe and TCC/LE:
Click to expand...

This is actually the result of *two* bugs (or at least one bug and one serious inconsistency) in CMD.

First, both CMD and TCC(/LE) treat a multiline command group as as a single command. The only difference is that CMD echos the lines as it reads them, and TCC only echos the final construct. They both assemble the command group into a single compound command.

CMD's normal behavior with IF is to ignore everything else on a command line if the IF fails. This is undocumented behavior, which is one reason I consider it a "bug" -- the second being that it's senseless to treat something following a command separator (&) as being somehow syntactically related to the previous command. (Why not have FOR ignore compound commands if it fails??)

The inconsistency with CMD is that it treats an end of line within a command group as (slightly) different from a & -- but only for IF! (It resets its internal flag that would otherwise have it ignore the remainder of the line).

Now, I could add another kludge to TCC to emulate this peculiar behavior -- but it probably isn't necessary in most cases. If you turn off the "Duplicate CMD bugs" option, the batch file (or at least the fragment you posted) will work identically in CMD and TCC.
 
rconn said:
If you turn off the "Duplicate CMD bugs" option, the batch file (or at least the fragment you posted) will work identically in CMD and TCC.
Click to expand...
I tried this, but it still did not work as expected. In this case the & given after IF statement related to the whole statement. That is, the code:
Code: 
IF smth SET "TARGET_CPU=x86" & SET "CURRENT_CPU=x86"
is treated like
Code: 
IF smth SET "TARGET_CPU=x86"
SET "CURRENT_CPU=x86"
The second statement is applied unconditionally. This leads to two major problems with the setenv.cmd script:
First, the block quoted in the first post produced CURRENT_CPU="IA64" (which happened to be the last statement) — of course it's hard to expect that SDK would compile applications correctly under these conditions.
Second, the setenv.cmd script simply hangs after setting the CURRENT_CPU and TARGET_CPU. When I commented the "echo off" statement I saw that it is the following lines of code that are repeated constantly:
Code: 
:Parse_Args
IF /I "%~1"=="/debug" SET "Configuration=Debug" & SHIFT & GOTO Parse_Args
The two commands (SHIFT and GOTO Parse_Args) are executed always, regardless of whether the IF condition is true or false, so we have an unconditional endless cycle here.
 
rconn said:
The change is available in 13.06.74, which is already available on the JP Software web and ftp sites.
Click to expand...
13.06.74 is NOT on the FTP site!

I prefer downloading from the FTP site because ftp preserves file timestamps, http doesn't. Though I realize that both sites use Posix file systems, so the site timestamp reflects the time of upload, not of file content change, they are still a reliable guide whether or not the current files are newer than whatever I previously downloaded, thus saving my limited high-speed download volume. This is particularly important if I am unable to download for an extended time interval.
 
Steve Fabian said:
13.06.74 is NOT on the FTP site!
Click to expand...

Yes, it is. Refresh your cache.

I prefer downloading from the FTP site because ftp preserves file timestamps, http doesn't. Though I realize that both sites use Posix file systems, so the site timestamp reflects the time of upload, not of file content change, they are still a reliable guide whether or not the current files are newer than whatever I previously downloaded, thus saving my limited high-speed download volume. This is particularly important if I am unable to download for an extended time interval.
Click to expand...

Public FTP access on ftp.jpsoft.com is going away by the end of the month. It's an attack magnet, it's harder, far more cryptic and much slower than using the updater ("OPTION /U"), and the times have even less meaning than you think (they're in UTC). The updater also tells you what's been changed in the new version and gives you the option of downloading & installing it; the FTP download does not.

We also do NOT support installing or updating through FTP. (And we do not provide any support for TCC/LE.)
 
We do not provide any support for FTP access. But I wasn't talking about TCC (which has no cache), but your ISP's cache.

I've removed TCC/LE from the public FTP. Unless you're blocked from HTTP access, it provides no benefit (and several inconveniences) to the user. The FTP site is primarily used by attackers -- roughly 99.96% of the ftp.jpsoft.com accesses for the past month (8200+ per day) have been aimed either at accessing private directories or crashing the server.
 
rconn said:
The FTP site is primarily used by attackers -- roughly 99.96% of the ftp.jpsoft.com accesses for the past month (8200+ per day) have been aimed either at accessing private directories or crashing the server.
Click to expand...

Wow, just wow. How far back are the days when the devs posted their status reports on their ~/.plan files, so users could see them by simply fingering.

I *was* going to bitch about not having the FTP site anymore, but after seeing that number, I'll just shut up.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate