The installer (FDI) really gives FreeCOM a good work out. It is probably one of the most complex BATCH scripts ever to run on DOS. If a problem exists it tends to crop up. For example, during early stages of development (years ago), I found that occasionally FreeCOM would "lose" information passed through pipes. It was inconsistent, impossible to predict and didn't always happen. So, the installer got a lot of code looking like this (made up code, not part of the installer, wouldn't actual work)...
:TryIt
rem Clear RESULT value
set RES=
rem Count drives and store total in RES
fdisk /info 1 | grep -i "drives" | grep -iv "space" | vstr /b /l total | set /p RES=
rem RES cannot be empty, it must be a number
if "%RES%" == "" goto TryIt
rem RES is now some number of value 0 or greater
After some repeated loops of the exact same thing, it would no longer loose the data. I have know idea if recent builds still have the issue or not. All those leaky pipe checks are still in the installer.
All that was just to say, it gives FreeCOM a good beating. :-)
Now onto something new...
During testing of installing RC5, something in the new FreeCOM broke the installer. This caused me to rewrite that small section to avoid the problem. So, the installer works fine again and it is't an issue for it. I just want to put out the change and how it is rears it's head in the installer.
So, that is how I discovered this interesting little bug...
So I think that piping to nul, causes the single % to do some weird things. The following example can demonstrate it happening using vecho. vecho outputs text through BIOS not STDOUT. So redirecting to NUL has no effect on vecho. The /I switch is to output text from STDIN.
echo %
%
echo test %
test
echo %%
%
echo test %%
test %
echo test % test
test test
echo test | vecho a /i b %
atest b %
echo test | vecho a /i b% >nul
atest b
echo test | vecho a /i b % c >nul
atest b c
echo test % two | vecho a /i b
atest two b
echo test % two | vecho a /i b %
test
echo test % two | vecho a /i b % >nul
(no output)
echo test %% two | vecho a /i b % >nul
atest % two b
So, as you can see. Something very odd is happening when a single percent is used.
The installer (FDI) really gives FreeCOM a good work out. It is probably one of the most complex BATCH scripts ever to run on DOS. If a problem exists it tends to crop up. For example, during early stages of development (years ago), I found that occasionally FreeCOM would "lose" information passed through pipes. It was inconsistent, impossible to predict and didn't always happen. So, the installer got a lot of code looking like this (made up code, not part of the installer, wouldn't actual work)...
After some repeated loops of the exact same thing, it would no longer loose the data. I have know idea if recent builds still have the issue or not. All those leaky pipe checks are still in the installer.
All that was just to say, it gives FreeCOM a good beating. :-)
Now onto something new...
During testing of installing RC5, something in the new FreeCOM broke the installer. This caused me to rewrite that small section to avoid the problem. So, the installer works fine again and it is't an issue for it. I just want to put out the change and how it is rears it's head in the installer.
So, that is how I discovered this interesting little bug...
So I think that piping to nul, causes the single % to do some weird things. The following example can demonstrate it happening using vecho. vecho outputs text through BIOS not STDOUT. So redirecting to NUL has no effect on vecho. The /I switch is to output text from STDIN.
So, as you can see. Something very odd is happening when a single percent is used.