problem with <if exist> condition

[sst]

When using windows cmd.exe, if we want to know whether an existing File System Object(FSO) is a file or a directory, all we have to do, is to append a BackSlash at the end of the object name and then check for its existence:

if exist example (
    if exist example\ (
        echo This is a directory
    )else (
        echo This is a file
    )
)

But unfortunately the above code does not work correctly under tcmd/tcc. It always echos "This is a directory".

Note that I'm already aware of ISFILE and ISDIR condition expressions, But consider the situation when we need a simple batch file that does not have to incorporate the advanced features of tcmd and also, we want to be able to run the batch file under both cmd and tcmd comspecs. We simply fail to achieve that purpose if we need to perform that very basic and common query about an FSO.

I don't think this can be considered a bug, but a matter of interpretation that is incompatible(unnecessarily maybe?) with windows cmd.

So I have a couple of questions regarding this issue:
1. Is this behavior intentional or is it something that was missed?
2. If the latter, could it expected to be fixed(bug?) or be made compatible with cmd in future versions?
3. If the former, what would be a recommended/reliable method to detect the comspec (cmd/tcmd) at batch run time and choose the execution path accordingly?

 

[Steve Fabian]

I never used CMD, nor I ever expect to in the future. However, there is a simple test since the 4DOS days to determine whether or not COMSPEC is a JPsoft program:
if "%_4ver" ne ""
is true if and only if it is executed by a JPsoft command processor. This test can be reliably used to disambiguate.

 

[vefatica]

When using windows cmd.exe, if we want to know whether an existing File System Object(FSO) is a file or a directory, all we have to do, is to append a BackSlash at the end of the object name and then check for its existence:

if exist example (
    if exist example\ (
        echo This is a directory
    )else (
        echo This is a file
    )
)

But unfortunately the above code does not work correctly under tcmd/tcc. It always echos "This is a directory".

Note that I'm already aware of ISFILE and ISDIR condition expressions, But consider the situation when we need a simple batch file that does not have to incorporate the advanced features of tcmd and also, we want to be able to run the batch file under both cmd and tcmd comspecs. We simply fail to achieve that purpose if we need to perform that very basic and common query about an FSO.

I don't think this can be considered a bug, but a matter of interpretation that is incompatible(unnecessarily maybe?) with windows cmd.

So I have a couple of questions regarding this issue:
1. Is this behavior intentional or is it something that was missed?
2. If the latter, could it expected to be fixed(bug?) or be made compatible with cmd in future versions?
3. If the former, what would be a recommended/reliable method to detect the comspec (cmd/tcmd) at batch run time and choose the execution path accordingly?

A simpler example shows the same thing:

v:\> d ex*
2014-03-07  23:10  0  example <------ it's a file

v:\> if exist example\ ( echo yes ) else ( echo no )
yes

The Win32 function FindFirstFile() fails (87, the parameter is incorrect) if the string passed to it ends with '\'. So I wouldn't be surprsed if TCC simply removes a trailing '\'.

 

[vefatica]

CMD must do a little extra to make the distinction between "example" vs. "example\"

I'm a little surprised that that incompatibility hasn't caused a genuine complaint by now.

 

[mikea]

> I'm a little surprised that that incompatibility hasn't caused a genuine complaint by now.

I expect that most people using TCC simply use "if isdir" and don't bother with cmd.exe's not-always-reliable tests (I've found they aren't always reliable; YMMV).

Well, pending a 100.0% cmd-compatible world, there's always something like this (tested w/TCC 15.01 and whatever g-dforsaken flavor of cmd.exe they're sending out with Win 7):

if "%_tccver%" NEQ "" (
    iff isdir xyzzy then
        echo TCC: directory xyzzy exists
    elseiff isfile xyzzy then
        echo TCC: file xyzzy exists
    else
        echo TCC: 'xyzzy': no such file or directory
    endiff
) else (
    if exist xyzzy\ (
        echo CMD: directory xyzzy exists
    ) else if exist xyzzy (
        echo CMD: file xyzzy exists
    ) else (
        echo CMD: 'xyzzy':no such file or directory
    )
)

Then again, if the script is extensive enough, I prefer:

if "%_tccver%" NEQ "" RunThisScriptInstead.btm

Or, if the script isn't extensive enough to call for an entirely separate file:

if "%_tccver%" NEQ "" goto Do_It_With_TCC_Instead

... and just put the infinitely-better-designed script commands within the label.

 

[sst]

Thanks for the replies guys. I appreciate that. Specially for the comments/recommendations about detecting the Comspec at run time.

Yes, TCC is superior to CMD in every aspect. there is no doubt about that.
TCC is capable of performing very complex tasks that are not imaginable to doing them by CMD.
It is great, but just for our own personal use or for use in our own controlled environment.
When in comes to the outside world, It does not matter which comspec is better, we love, or prefer to use, What's most important is compatibility.

If I want to distribute a solution that all or parts of its functionality are carried by a batch file, I need that batch file to be compatible with all the target systems so that it does not get failed because of syntax incompatibility or lack of functionality in the command processor.
Therefor I have to make that batch file CMD compatible. If by chance some of the target systems are using TCC as their default batch processor, I don't expect that my batch file to get failed(at least most of the times) or else i need the extra effort to handle those special cases.

In the opposite side, If I want to make TCC the default batch processor in my environment, I need it to be compatible with most(ideally all) of the existing batch files that I already have or will receive in the future, which are not specifically written for TCC.

Compatibility is so important that Rex bothered implementing the option "Duplicate CMD.EXE bugs" in TCC.
So while TCC is compatible with CMD to a great degree, the example above showed that we may get failed more than we think, if we rely too much on compatibility between the two Comspecs.


BTW, I've found a solution(not necessarily reliable) to this specific issue which is compatible with both Comspecs:

if exist "example\*"

Returns true for directories and false for files in both TCC and CMD.