DosTips.com

For work I regularly end up with a bunch of hex files with the extension .hex, but I can have anywhere from 5 all the way up to in the hundreds. Most of the time the files will be the same, but require me to open them and edit a select set of values before saving and closing. Right now I am using H...

Your subroutine :treatment is missing the 'end subroutine' command.
This causes processing of :treatment to continue with the command in :end, so processing stops with the''exit %CodeRetour%' command.

Add 'exit/B' or 'goto :eof' at the end of the subroutine to correct this.

The 'set "file2=%%~i"' does work, but is done inside the for-commandblock enclosed in ()
Use delayed expansion to echo and use the uptodate value of %file2%.
Change %file2% in !file2! and %newfile2% in !newfile2! and your code will work as expected.

or with less carets but more ""

I am not entirely sure but these might work:

SET COMMAND=('find /n "" < %2')
SET COMMAND=('find /n "" %2')

The first: leave out the caret
The second: leave out the redirect, find does not need it

? EQU is correct, EQL does nothing. Personally I prefer using == for EQU comparisons. You are right. I got EQL from if /? (Vista language: dutch) EQL - is gelijk aan NEQ - is niet gelijk aan LSS - kleiner dan LEQ - kleiner dan of gelijk aan GTR - groter dan GEQ - groter dan of gelijk aan I always u...

A minor syntax problem might be the problem.
change EQU to EQL

These are not the same: set "PathExt=" set "PathExt=;" The first deletes the PathExt from environment. CMD falls back to internal default:.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC The second set PathExt to: No extensions to search for. I have tested some more just to be sure: Disabli...

If I set the path to nothing DOS will not search the path for a file named echo when echo. right ? Almost, just disabling path is not enough. FileSearch will still be done in the current directory. That is why the FileExt has to be disabled as well. I was wondering if it also has effect on performa...

A similar solution using only the file-attributes.

hmmm I guess my explanation was not very clear. I started with Jebs "Call Set" - "Set.bat" vulnerability. Tried to encapsulate the Call Set to isolate this from de FileSearch. Then I expanded my test to all internal commands. I can confirm that all internal commands are vulnerabl...

Restoring the path is not a requirement, just good practice. Imagine working from the commandline. You run a batchfile that wipes the path and does not restore it before finishing. Suddenly your external commands don't work anymore. Just because these are normally found through the default path-sear...

In the thread CALL me, or better avoid call at http://www.dostips.com/forum/viewtopic.php?f=3&t=1947&hilit=precedence Jeb demonstrated the slowness and unsafety of 'call set' and 'call echo' The code below is an attempt to tackle both problems. This is done by skipping the superfluous direct...

A quick glance at your code Errors for external dos commands are not so weird. With set "path=D:\TEST\%petsa%" you have blocked access to the previous path including access to %windir%\system32 the location of all external dos commands. Change this line to path=%path%;D:\TEST\%petsa% or at...

use the exit command
exit /b 0 or exit /b 1