> On Oct 6, 2015, at 8:55 AM, Eric Auer <e.a...@jpberlin.de> wrote: > > > Hi Jerome, for clarification: I was referring to > the specific case where your tools are used as a > part of the install process of FreeDOS :-)
I know, I was just using an easy to state example. :) > > In your given "pick a file and unzip" example, it > would be possible to do alternative tricks like: > > VASK-PRO /F *.zip "Pick a file to unzip" "unzip $F" > > The proposed VASK-PRO tool would display a file picker > (another option could select a directory picker) for > all files called "*.zip" together with the question > text in the next option. Once the user picks a file > (if the user aborts, VASK-PRO just exists) then the > command "unzip THATFILENAME" will be invoked. Voila, > a solution without SET /P and without pipelines :-) > > My question was: Which variables do you set using the > SET /P trick and is it really necessary to have them > in environment variables? Could you use the values in > other ways (as in the above example)? Or would it be > sufficient to have a small RAM storage area to keep > status of your tools? An obvious example would be the > cursor case: Post Stage 6, There is some math stuff to simplify creating of “window” frames and options. The installer is extensible. With very little effort. Stage 7 scans the installers directory for and calls each FDASK???.bat file to query the user on one thing. (Not always, sometimes the bat will detect things like no os is installed, don’t ask my question. And, running in basic mode so assume System file transfer and don’t ask.) Stage 8, scans that path and all existing drives that contain a FDSETUP\SETUP directory and includes there FDINS???.bat files in the actual install process. All of this scanning, enumerating and executing could be accomplished with another utility. But, that utility would not belong as part of the V8 toolchain. I’ve used several different methods to accomplish this scanning. The most reliable (always works as designed) method requires some stuff using vmath, vstr and set /p. > > VCURSORX /PUSH /SET=full > > could store the current cursor size in a V-specific > RAM area and change the cursor to full block size. > > VCURSORX /POP /CLEAN > > could restore the cursor size from that RAM area (if > none found, do nothing) and deallocate the RAM area > as far as cursor data is concerned. Of course it is > not necessary to make a real stack here, probably a > single cursor size storage slot will be enough. The only problem doing things this way is the requirement of a TSR to pass the data around. Every tool in V8 is completely stand-alone and requires no other tool in V8. Some, like vchoice could get rather tricky to use without vframe and vline. But, you do not need them to use vchoice. > > Other variations of the same idea will apply to other > uses of your tools for the installer. My question is: > > Are there installer actions which REQUIRE some SET /P > support and if no SET /P is available, what is lost? Mostly, this would just break the easy expansion and adding of options to the installer. It could be hard coded to do a FreeDOS install without it. But, that would require modifying the main installer logic everytime anyone wanted to make a minor change to install prompts, packages or just about anything else. With the set /p support, the installer is very flexible and easy to update once there is a basic understanding of how to extend it. > >> The only tools that will require set /p support for any usable functionality >> will be vask (when I get around to making it) and vmath. There are advanced >> functions in vcursor, vfdutil, vgotoxy, vmode, vstr and vchoice that can be >> taken advantage of when set /p works. But, for the most part they are >> not needed or required to accomplish most things. >> >> Let’s take vchoice for example. You can fairly easily have a area that >> vchoice will use for selection. It will by default output your choice >> as an exit code (errorlevel). No set /p required. >> >> However, if lets say you have displayed 20 file names, your batch file does >> not >> know what the filenames are since you basically are just listing a >> directories >> contents. You want the user to pick one. If you knew what the names were, >> you could use 20 “if errorlevel n” instructions to set an environment >> variable >> you want to pass as an archive name to the zip utility. If you use the /Q >> option >> on vchoice that text will be sent to STDOUT. So, you could use basically >> 1 line to achieve something that is not really possible otherwise. Just, >> by doing “vchoice /Q | set /p ZARC=“ >> >> But, like I said this is an advanced function and would not be needed most >> of the time. >> >> Another example is vfdutil. You can go directly to a drive and path of a >> filename. changing the current drive and directory by using “vfdutil /c/p >> %SOMETHING%”. > > You can simply change the active directory to do thisk :-) As there > is directory stack support (PUSHD, POPD...) in FreeCOM command.com, > things get even more convenient. Same example, without SET /P usage: > > pushd > VFDUTIL /PATH /GO-THERE > dir *.* > x:\filelist.txt > popd Did’t know it had push/popd. BTW, I know it was and example. The following is an actual code snippet that requires set /p: set _TI=0 :Looping dir /a /b /p- %_TSA%\FDINS*.BAT | vstr /l %_TI% | set /p _TA= if "%_TA%" == "" goto Finished verrlvl 0 if not exist %_TSA%\%_TA% goto AbortBatch vfdutil /c/p %_TSA%\ call %_TA% if errorlevel 1 goto AbortBatch vfdutil /c/p %FINSP%\ vmath %_TI% + 1 | set /p _TI= goto Looping :Finished ( Notes on above code: The variable names are short to reduce the space used by the env. vstr /l nun returns a specific line in a file. If that line doesn’t exist, it returns “” ) > > Note that I explicitly store the resulting file list in X:, which in > my example could be a small ramdisk. If the user later has to pick a > file from that list and unzip it, the example near the beginning of > my mail can be combined with this to do everything WITHOUT ramdisk. Actually, the installer does something like this but explicitly uses the %TEMP% directory. > > On the other hand, if you plan to unzip a file, you probably unzip > it to the drive where you install DOS, so you can simply use that > drive for temporary storage of the file list as well... :-) > >> vfdutil /p %SOMETHING% | set /p FPATH=“ >> dir %FPATH%\*.* >FILELIST.TXT > > Regarding mathematical and cursor processing: Are you sure that you > have to do this with several tools which have to communicate using > a memory area or environment variables? How about doing ALL steps > for a single cursor move inside a SINGLE call to one of your tools? Actually, it looks more like this before stage 6: vcls /f %TSF% /b %TSB% /c %TSC% /y2 /h24 vframe /b %TFB% /f %TFF% /w60 /h10 /c /y7 hidden shadow vframe /b %TFB% /f %TFF% /w58 /h10 /c /y7 %TFS% vframe /b %TFB% /f %TFF% /w56 /h8 /c /y8 hidden After stage 6: vmath %1 - 2 | set /p _TA= vcls /f %TSF% /b %TSB% /c %TSC% /y2 /h24 vframe /b %TFB% /f %TFF% /w60 /h %1 /c hidden shadow vframe /b %TFB% /f %TFF% /w58 /h %1 /c %TFS% vframe /b %TFB% /f %TFF% /w56 /h %_TA% /c hidden set _TA= > > This could be for example: VCURSORX /GOTO $WIDTH/2-10 $HEIGHT/2-3 > In my example, VCURSORX supports width and height look-ups and some > basic math calculations itself, avoiding the need to pass on data. It would drastically increase the size of each utility to add math functionality to each of the utilities that may only rarely make use of it. For strictly moving and polling the cursor position, vgotoxy has a bunch of shortcut commands. Things line eop, sol, sor……. These accomplish most of what would be commonly needed. vframe has a /c option that centers it. > > Cheers, Eric > > :) > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
