i know about %=exitCodeASCII% but its not the point of my interest, as i need opposite effect
Actually your script is exactly what i was thinking about (and just mentioned in some thread nearby without awareness that someone already did this script), but again it seems 2 slow and heavy -
255 for cycles with 255 more for cycles??? How many of them do we have in total, 65025??? I suppose coding some little hex\dec\ascii command line converter in C# or asm would be simpler and more effective and faster. Actually i googled for command line tool like this, but i only found hex2dec by Mark Russinovich, so i have no other choice but to do it in pure bat.
But i prefer external tools, its not a problem to redistribute such tools with bat script or hide it inside any exe container like bat2exe, but im not sure if tools like this exist.
Have your tried to code such tool instead of messing with mapping and 255*255 cycles?
As for !id! im not sure what Os you do use, but for me in Windows 7 !id! always returned "file not found" even without /f, by default "for" uses (something) as filename, not as string itself, and its clearly stated in for /? help, i think you messed something or have non default setting in registry or some older Os.
Im quite certain that "!id!" fixed "file not found" problem of original script.
As for removal of & and endlocal, im aware of what exactly they did, but i consider this "hiding" of variables from calling script unnecessary, actually i consider quite necessary to have access to any variable anytime from any part of script, so this is just the matter of taste and task, thats why i prefer to not use endlocal at all.
Also i think "&" is quite unnecessary too, it have nothing to do with local variables, all it can do is chaining 2 commands in one line, but command1 & command 2 is 100% the same as
command 1
command 2
but second looks more readable and eye friendly)
And how come that reading about 10 lines of text and performing 16 "for" loops with math equation could be faster than twoliner exit /b %dec% & %=exitcode% ?
What kind of speed testings you did to get such an unexpected results?
... wow this marco thread is crazy, i just tried thing like that recently, and come to conclusion that it complicates things to much.
escaping special characters needs to be done careful, any minor miscalculation with one more or less ^ symbol and whole macros is screwed, also syntax like this is quite unreadable and with lack of detailed instructions and explanations many people would not even get the idea how it works, also debuging such type of syntax also extra pain in arse and consuming more time, so i dont think its practical enough, it looks more like a challenge... unfortunately i have too little time to mess with challenges like this, and im more interested getting effective result faster.
Do you know about "lex parsimoniae" principle aka "law of parsimony" or "occam's razor"?
"The simplest solution is usually the best" - thats what lex parsimoniae means, and thats the principle i tend to follow and suggest anyone to follow it too.
Using as little for cycles and if else statements and variables as possible is the best solution.
Also i have my personal principle which dont have name but means this - light-weight, well structured, standardized and eye-friendly code is programmer's best friend that helps to debug and develop things faster and more efficient
Anyway, back to original topic - is there any simple dec\hex\bin command line convertor exist, or anyone here willing to code one, please?))