Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Percentage of pipes #62

Open
shidel opened this issue Dec 3, 2021 · 0 comments
Open

Percentage of pipes #62

shidel opened this issue Dec 3, 2021 · 0 comments
Labels
bug Something isn't working

Comments

@shidel
Copy link

shidel commented Dec 3, 2021

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...

fdisk /info 1 | grep %% >nul
rem no output
fdisk /info 1 | grep %%
 C: 1      A     500   FAT16     100%
fdisk /info 1 | grep % >nul
usage: grep [-[AN] ]<num>] ..........
fdisk /info 1 | grep %
 C: 1      A     500   FAT16     100%

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.

@PerditionC PerditionC added the bug Something isn't working label Dec 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants