Command name parsing of GNU compilers

#1
Calling c++ or g++ from tcc.exe results in the following errors when either a batch file, or an alias with a shorter name (matching the command name before the "++") is defined:

PROMPT> c++
Usage: db [bcimp] (calls c.btm)

PROMPT> g++
fatal: Not a git repository (or any of the parent directories): .git (calls g, an alias)

Otherwise (renaming the batch file, or unaliasing the alias) the compiler is called.
 
Last edited:
#3
That's a workaround, not a solution that is compatible with the behavior when there is no "c.btm" or no "g" alias. The program name is "c++" not "c". I think this is a parsing problem; having e.g. a "c.cmd" (or "c.bat" for that matter) in "c:\windows" doesn't prevent cmd.exe from starting "c++.exe".
 
#5
I understand that. However, this breaks compatibility with cmd.exe which also supports "+" for "copy" (besides, AFAIK there is no "copy+<to_something>"). Wouldn't it just be possible to accept "+" as part of the first token in the command line?
 

rconn

Administrator
Staff member
May 14, 2008
10,504
94
#7
I understand that. However, this breaks compatibility with cmd.exe which also supports "+" for "copy" (besides, AFAIK there is no "copy+<to_something>"). Wouldn't it just be possible to accept "+" as part of the first token in the command line?
CMD has a separate parser for every command, while TCC has a single parser for all commands. I think the latter is vastly preferable for the sake of uniformity (and not increasing the code size 10x). But if you want you could post something in the suggestion forum that TCC should adopt the CMD style (this would, however, break a LOT of existing functionality).
 
#9
Adding the file extension will also work: notepad++.exe (without quotes) works fine here

Btw: Tab completion on the command-line already "knows" that filenames like this have to be quoted.
My notepad++.exe gets expanded to "notepad++.exe" (with quotes) whereas notepadplusplus.exe gets expanded to notepadplusplus.exe (without the quotes)
 
Sep 24, 2013
27
0
#11
From the FAQ:
Is Take Command completely compatible with the standard Windows CMD.EXE?
It's impossible to be 100% compatible with CMD.EXE, because
(1) Take Command has several thousand additional features, and
(2) CMD.EXE itself is incompatible with other versions of CMD.EXE.
We strive for 99.9% compatibility (generally more than CMD.EXE manages with differing versions of itself!) . There are always workarounds for the rare situation where Take Command doesn't execute a batch file in an identical way.
Looks like you've found part of the 0.1%.
 
#12
@gentzel
That's an argument you can use in either direction. (And in fact, it was already used by JPSoft to turn down other requests "this is not compatible with cmd.exe").
Anyway, I take it that most of the guys on this forum are ok with the current implemention; well then - so will I.
 
#13
Adding the file extension will also work: notepad++.exe (without quotes) works fine here
Turns out I was wrong about this. I defined a 'notepad' alias in another TCC box, but forgot it was a local alias. So, adding the file extension doesn't do the trick.

I like the beauty of simplicity/consistency, but I don't think it is possible in this case:
The most simple parsing rule would be: if not "space" before "+", the "+" is part of the filename/alias/..
But .... CMD (and TCMD) supports a command like: copy 1.txt+2.txt all.txt (without spaces around the "+"). So it will be "messy" anyhow.

Ergo:
The carpet in the room is just too small to cover all the problems. If you fix the (CMD-) problems on one side of the room, you will uncover new problems on the other side of the room. And buying a complete new (handmade, expensive) carpet is not really an option.
So in this case an extra piece of the same carpet was made and put in an unremarkable corner and stitched together with a few """ ...
I can live with that (but I have to confess: I never have to be in that corner of the room :-)


On the other hand: there is some strange "+"-related behaviour:
- dir++ (without a space) gives you: The system cannot find the file specified. "C:\Temp\ff\++".
- If + is not a valid filename character ([title] ), then why is echo something > "+++.+++" supported? (Or at least warn me that I'm being stupid).
- echo something > one+two.txt needs too be quoted in TCMD, too (as expected)

Out of curiosity: what will the parser do with external commands that have command-line options like /+4 (can't think of a real scenario or a good example)

BTW: Isn't there some thread where the differences between CMD and TCMD can be logged? Couldn't find it.
 
Last edited: