DosTips.com

Well Dave, I would never program anything that works most of the time but not always.
I think my "fix" is not a fix but the proper coding. And I see no advantage in a second to best solution.

Hmm, I think all this has nothing to do with the for loop and its case (non)sensitivity as your last example shows. It is a question of the cmd.exe-implementation of set y=%x:str1=str2% Obviously this implementation is wrong and from a performance point of view badly implemented since the program se...

@Ed Thanks for your advice and consolation. I am an old battlehorse as well. I have not touched .bat files for many years. But currently I am in Saudi Arabia and they are still on a much lower level than we use to be. Hence I wrote an administration bat-script for file distribution of server files t...

@Ed I think this is basically the same algorithm as above. It is written down a bit shorter and more difficult to understand. But it does exactly the same. (Maybe even a little bit more since it needlessly replaces lowerase characters as well). Of course one could easily add the German umlaut and th...

Thanks Dave for clarifying what's happening within the original toLower-code. That's funny with the a-variablenames. Of course I take your enhancements for the code. Thanks. I do not agree with you in all points about the effort analysis of the code. It is true that for longer strings the disadvanta...

@amel27
Aha! Thank you for that explanation. I did not know that but it is clear now.

So the trick would be to somehow capture the stdout from "echo" without starting a new command processor.

Thank you jeb for this link to "Geheimnisse ..". Very interesting. It proofes what I was afraid of. The language has no formal definition. This cmd.exe is by no means a proper parser, but mountains of stacked if-statements. I would call it a hobby-program that grew over some years by addin...

OKI, so we seem to have a strange bug in echo piped to find. I did not understand the prompt-game in your code. (Btw: another undocumented feature "prompt $"). I do not want to toggle echo-state, but - switch it temporarily off (or on) - normaly after entry into a subroutine - and then bac...

??? This works: > echo ECHO ist eingeschaltet (ON). > echo>e.tmp & find "(ON)" e.tmp ---------- E.TMP ECHO ist eingeschaltet (ON). > echo off echo ECHO ist ausgeschaltet (OFF). echo>e.tmp & find "(ON)" e.tmp ---------- E.TMP But I don't like that useless e.tmp file. And I...

During debugging with "echo on" I want to disable echo within uninteresting subfunctions and reestablish the original state later. I.e something like: call :EchoOff :: do uninteresting things call :EchoBack I try: :EchoOff :: Store current echo-state. Switch echo off set $LEchoOn=off&f...

Oh Gott, wie dumm von mir. Peinlich, peinlich.

On my keyboard you will neither find asterix nor obelix, so I cannot help out Hups. You are right. What we have is a Unicode MULTIPLICATION SIGN. The U+2217 ASTERIX OPERATOR has nobody. That is why I fell back to my 4711 solution. No, seriously, it's a time problem. I spent far too much time allrea...

Thanks for the asterix. Unfortunatly I have no obelix on my keyboard, hence I can not use him either. Or is there another tricky recursive obelix-key simulator solution? Seriously: I fell back to my original understandable for /l %%i in (1,1,47) do solution. This command interpreter is really myster...

OMG! I just noticed that this %* processing loop for %%c in (%*) do (...) delivers a list of all files in current directory when the parameter lists contains * or "*"! This is really crazy. Since I need the asterix as parameter in my application I cannot use this simple solution.

I had a set x=%y% somewhere in my code and the program did not work. I needed hours to find that my editor (TextPad) had left a space at the end of that line which was then appended to x. Sometimes I saw code like set "x=%y%" which I did not understand and which should be an error accordin...