Kinook Software Forum

Go Back   Kinook Software Forum > Visual Build Professional > [VBP] General Discussion
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
  #1  
Old 03-18-2004, 11:41 AM
philip philip is online now
Registered User
 
Join Date: 09-23-2003
Posts: 5
DOSCMD recursive COPY NUL fails with exit code 104

I have a step in a build that does:
%DOSCMD% FOR /R D:\directory /D %%f IN (*.*) DO COPY NUL %%f\Vers_081.txt

This is intended to create a 0-byte placeholder file in each subdirectory in the path. If I run the command (without the %DOSCMD% and changing the %%f to %f) from a DOS prompt, it works correctly.

When this is run in Visual Build, it fails with an error:
Process completed with exit code 104
although it appears to create all the placeholder files correctly. If I change the "COPY NUL" to "ECHO. > ", it still fails in Visual Build with the same message and exit code (but again, it does create the files).

This is version 5.0 of Visual Build (licensed) running on Windows NT4 SP6a.
Reply With Quote
  #2  
Old 03-20-2004, 07:57 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
I suspect that COPY is returning exitcode 104 in both scenarios, but is only being detected and aborted by VBP. You could add that code to the success codes for the Run Program step (0, 104 in the Success exit codes field).
Reply With Quote
  #3  
Old 03-21-2004, 06:38 PM
philip philip is online now
Registered User
 
Join Date: 09-23-2003
Posts: 5
I tried the same command in a batch file, with a check for the ERRORLEVEL at the end of the batch file, and the ERRORLEVEL is 0 when run in a batch file.
Reply With Quote
  #4  
Old 03-21-2004, 10:19 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
To get an equivalent comparison with what VBP is doing when executing internal OS commands, create a .cmd script that looks like this:

cmd /c FOR /R D:\Directory /D %%f IN (*.*) DO COPY NUL %%f\Vers_081.txt
echo %ERRORLEVEL%

I'll bet that if you run this from a Command Prompt you'll get the same errorlevel/exitcode behavior as inside VBP (on Win XP, it shows an exitcode of 2012907760). The cmd /c part is necessary from within VBP since 'copy' is implemented by the command interpreter. I'm not sure why cmd.exe produces a different exitcode in this situation, but it sounds like a bug in Windows (unless there's something about the statement syntax that isn't technically valid, but then you would expect it to fail without doing anything).
Reply With Quote
  #5  
Old 04-01-2004, 09:22 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
This seems to be a general problem when calling cmd /c FOR. One workaround is to put the FOR call in a batch file (which tests the exitcode itself and performs a no-op statement to force a 0 exitcode on success). This can be copied/pasted into VBP:



<step action='Write File' type='0'>
<Filename>%TEMP%\x.bat</Filename>
<Text><![CDATA[@FOR /R %TEMP% /D %%%%f IN (*.*) DO copy NUL "%%%%f\Vers_081.txt"
@IF %%ERRORLEVEL%% == 0 GOTO Done
@rem this executes another statement that will succeed so the callee gets a 0 exitcode
:Done]]></Text>
<description>Create a temporary batch file to perform a FOR command and ensure a 0 exitcode on success when called via cmd /c</description>
<indent type='3'>1</indent>
<name>create batch file</name>
</step>
<step action='Run Program' type='0'>
<command>%DOSCMD% call "%TEMP%\x.bat"</command>
<description>Call the temporary batch file that was created</description>
<indent type='3'>1</indent>
<name>call batch file</name>
<outputfrom type='3'>1</outputfrom>
</step>
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 01:24 PM.


Copyright © 1999-2023 Kinook Software, Inc.