Hi guys,
Having resident data will reduce issues with needing SET /P which has limitations (e.g. using pipes, which in most DOS command.com variants need temp files on a writeable drive) and is not in the classic MS DOS version of command.com (in case somebody tries to use your batch files to upgrade an existing MS DOS install).Of course I do not know if ALL instances of SET /P can be avoided this way, but it would be interesting to hear more about this :-)
I'm not sure what you mean. The batch syntax "[...] | set /p VAR[...]" will _always_ create a temporary file (under DOS), as you wrote. Or do you think that V8Tools' resident part could preprocess command lines (including lines inside batch files) and replace " | set /p VAR[...]" parts - starting from the pipe character, not the "set" command! - with something else that reroutes command.com to itself (the part responsible for "set /p")?
Maybe, preprocess batch files to turn " | set /p" parts into a special command (without a pipe), and _patch_a_hook_directly_ into command.com's (version/release specific, checks needed) command tokenizer/executor to be able to recognize these special commands before command.com tries to. Nasty, :-) and I'm not sure if it's worth the trouble.
Under Windows (XP), where I'm using GnuWin32 (http://gnuwin32.sourceforge.net ) heavily but have not yet started using a Unix shell (stupid me?), this "set /p" command would've been extremely useful _if_ it could also be used as the end of a pipe. (I just checked: it doesn't work under Windows 7 either.) So I'm using a program called "xset" of my own (as usual, not releaed yet <:-) ) that does what "set /p" is supposed to do (and some more), reaching up into its parent process and injecting values into the parent process' (usually: cmd.exe executing it) environment variable block. Pipes are not as primitive under Windows as under DOS, though.
PS: Regarding the block driver discussion, I *guess* that exFAT is too different from FAT. So a block driver to make it look like FAT to a DOS kernel would have to trick a lot. Better use CDEX/net API.
Yes, that's what I realized, too. Especially if continuing to other file systems, those will be more and more different from FAT(12/16/32), even in basic concepts. The limit is there, useful discussion can only be about _where_ it is. What? Behind exFAT? It _is_ exFAT. ;-)
Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
------------------------------------------------------------------------------
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
