WAD 0 Files Deleted

[samintz]

I have a script that contains (among other things) the following lines:

iff '%3' == 'clean' then
    del /se *.obj;*.d;*.lib;*.lis;*Results.xml
        pause
endiff

However, I get inconsistent results when I run the script. I ran it three times in a row and got the "0 files deleted" message. Then I ran it in bdebugger and it deleted over 9000 files. Then again at the prompt with the following results. You can ignore the "4 failed" as that is expected since those are read-only files.

[R:\LogixTests\UnitTests] Build.btm Solutions.xml ReleasePC Clean
     0 files deleted
Press any key when ready...^C
 
[R:\LogixTests\UnitTests] Build Solutions.xml ReleasePC Clean
Deleting R:\LogixTests\UnitTests\CmTests\SQLite\sqlite3.lib
Deleting R:\LogixTests\UnitTests\InstructionSet\FbImcTests\TuningTest\ProgOperTestRunResults.xml
Deleting R:\LogixTests\UnitTests\IoTests\Tools\dtl32\DebugPC\dtl32.lib
Deleting R:\LogixTests\UnitTests\IoTests\Tools\dtl32\ReleasePC\dtl32.lib
     0 files deleted       4 failed
Press any key when ready...^C
 
[R:\LogixTests\UnitTests] Build.btm Solutions.xml ReleasePC Clean
Deleting R:\LogixTests\UnitTests\CmTests\SQLite\sqlite3.lib
Deleting R:\LogixTests\UnitTests\InstructionSet\FbImcTests\TuningTest\ProgOperTestRunResults.xml
Deleting R:\LogixTests\UnitTests\IoTests\Tools\dtl32\DebugPC\dtl32.lib
Deleting R:\LogixTests\UnitTests\IoTests\Tools\dtl32\ReleasePC\dtl32.lib
     0 files deleted       4 failed
Press any key when ready...^C

Any idea what's going on?
-Scott

 

[Frank]

can you see any errors if you omit the "/E" ?

 

[rconn]

You're not providing a path -- are you sure that when you ran it in the debugger you were starting in the same path?

Do you have any other processes on the system that are creating these files?

 

[samintz]

You're not providing a path -- are you sure that when you ran it in the debugger you were starting in the same path?

Do you have any other processes on the system that are creating these files?

Unless BDEBUGGER changes the CWD, then it was the same.

Essentiallly, I ran my batch script like this:

build.btm Solutions.xml ReleasePC Clean

And then pre-pended bdebugger to the command line and ran it again.

The build itself parses the XML file to know which solutions to build and then builds them invoking devstudio to do the build. The build output consists of all those file types. The ones that cause the most grief are the .d files which are dependency files. When files in a project change and the old dependency files stay around the build will complain about not being able to build something or other. So in order to insure a clean build I want to delete all the .d files and while I'm at it delete all the object files, libraries and sundry files used in the build.

I've never had the DEL command fail when I issue it at the command prompt. It only seems to fail when run from this batch file.

 

[rconn]

Unless BDEBUGGER changes the CWD, then it was the same.

BDEBUGGER starts a new session (IDE.EXE) and a new parser, so unless you've configured TCC to always start (and stay) in the same directory, it's unlikely it was the same.

I've never had the DEL command fail when I issue it at the command prompt. It only seems to fail when run from this batch file.

DEL doesn't know anything about batch files, and there will be no difference as far as TCC & DEL are concerned between the command line and a batch file.

 

[samintz]

BDEBUGGER starts a new session (IDE.EXE) and a new parser, so unless you've configured TCC to always start (and stay) in the same directory, it's unlikely it was the same.

It deleted the correct files. I was on drive R: and TCMD is installed in C:\TC13.

My TCSTART file contains: if %_pipe != 0 .or. %_transient != 0 .or. %_ide != 0 quit

So no special code or directory changes are being done in TCSTART. The first time I encountered this behavior I was surprised there were no files deleted. That's why I added the PROMPT after the delete.

 

[rconn]

I think it is extremely unlikely you're seeing a DEL bug (which would affect a few hundred thousand users, not one). I tried your batch file, but I was unable to make it misbehave. (Though you really should correct your invalid "/se" syntax.)

If you can create a reproducible failcase I'll be happy to look at it; but there's not much I can do with anecdotal bugs.