> On Oct 6, 2015, at 12:12 PM, Antony Gordon <cuzint...@gmail.com> wrote: > > Hi, > > Sometimes doing the "needful" exceeds the "requested". Jim has a vision of > what he wants, basically a batch file based simplified install. You (Jerome) > have created some very useful utilities for managing the screen and such. > > My thought was basically to incorporate your V8 tools as a part of FreeCOM to > make an "fdinstall.com" (or setup.com) which runs as a shell. The added > advantage is that the custom command shell retains the batch and environment > functionality, which can ultimately be expanded for other install processes > or even package management.
Maybe someday the V8 utilities may make it into a command shell. It would be extremely nice to have things like: vecho “Hello there “ /fRed Anthony /fGray . to spice up the console. > > -T > > On Tue, 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 :-) > > 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: > > 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. > > 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? > > > 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 > > 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. > > 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? > > 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. > > 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 ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
