DosTips.com

Each leading-colon-equation token is echo-suppressed in a nested IF too:

Trying a bunch of other leading characters, only the colon (:) exhibits the equation-suppression behavior: C:\Test>IF ?0 == false ECHO C:\Test>IF *0 == false ECHO C:\Test>FOR %# in (: "%" "^" "&" "|" ";" "," "=" ` ~ ! @ # $ - _ + \ / [ ] { } .)do IF %~#0 == false ECHO C:\Test>IF ECHO C:\Test>IF %0 =...

Using CMD /c to conduct the If operation will show the full command This makes sense since the original command processor is doing the echoing at that point. :D This could work for debugging a one-line statement. However, for the more complex debugging scenarios I originally intended, such as neste...

... But, I don't understand why you used the prefix of: "@FOR %%$ in ($)do" This only seems to complicate things without bringing any benefit. ... Good point! I can't remember why I had to do that my first time through, and it might only be needed inside a parenthetical block, but you're right: wit...

In my debugging of IF statements, I've noticed that the evaluation equation is ECHO-suppressed sometimes so that the echoed IF statement doesn't reveal the values being compared, obviously impeding the intended debugging. So far, I've localized this phenomenon to equations where the resulting equati...

... It's a problem of the CALL, it's independent of the command, because the command is never be used, when the CALL detects the /? before. ... Agreed, since CALL is the one intercepting with its own help (or not passing on the CALLed command I should say). I was pointing out the interesting behavi...

... In my opinion, there is a champion: echo( It's the most reliable in most of the cases. It fails only with: :case1 call echo( /? ... I see. "call echo( /?" apparently suffers from the same issue I mentioned which suggests there might be a way to escape it somehow: Fails: call echo( /? Works: cal...

This subject seemed to tail off without resolution, yet using ECHO to reliably display information is such a necessity. ... fails, if a file in the current directory exists named my.bat echo\..\my.bat echo:\..\my.bat echo.\..\my.bat ... ... The echo:\..\my.bat behavior really blows my mind. :shock: ...

I wrote this one-liner to handle (only in the first argument) the help command option in batch files: @For %%? in ("" : - /)do @IF %%~??==%1 GOTO:Help ... :Help ... It supports whatever leading switch characters you want to allow (in the FOR command set, except "*" which triggers a wildcard replacem...

Also, since "n<<<<<<" matches an ".exe"-file, i would expect "n<<<<<<.exe" to match the same executable, but on my system the first executes "C:\Windows\Notepad.exe" while the last starts "C:\Windows\System32\Narrator.exe". Yes, but while "n<<<<<<" does indeed match an ".exe"-file, that's not the F...

Create a shortcut to your batch file in the Send To folder, which is easily opened from the command line with: start shell:sendto Then you can right-click on your selected files, click Send To ; [your shortcut name] The batch file will receive the list of files as arguments, which you can iterate th...

... My PATH variable contains ";C:\WINDOWS\system32;C:\WINDOWS;" in that order, so it should search system32 folder first... On my system as well, except if I DIR "C:\Windows\System32\no*****.*" , the first file (of 11) returned is NOISE.DAT , causing PATHEXT to be searched for: NOISE.D.COM , NOISE...

... executing "C:\Windows\notepad.exe", you get that different icon. I just tried that, and it sure does. That's so weird, especially since it's a hardlink, effectively pointing to the SAME file! >fsutil hardlink list C:\windows\notepad.exe \Windows\notepad.exe \Windows\System32\notepad.exe \Window...

Adding the file "netbios.dll" to that folder makes it the first listed using 'dir "n<s.*"', but it doesn't execute net.exe (at least on my system). I tried your scenario, adding my \Test directory to the PATH before any \Windows paths, then I started with the current directory as %UserProfile%: >"n...

... in the taskbar, the notepad window does not have the notepad icon. Whoa! I didn't notice that. Good catch! I'm betting the icon resource lookup doesn't recognize wildcards. This extends to Task Manager's Details pane where if you look-up the Properties of that task, the Properties window also h...