> I'd agree with Tom here. Reinventing the wheel makes little sense. > After all, one of the points of FreeDOS is being a free replacement > of, well DOS, so you shouldn't really need a replacement for something > that has worked fairly well since the Romans left.
> In fact, I'm not even sure we should go too far in extending batch > capabilities. After all you'd just create incompatibilities to the > digital ancestors, NO. Adding features like the mentioned ones does NOT create incompatibilities. And I'm pretty certain that CMD.EXE with all it's extensions will execute 30 year old batches absolute flawless. MS did a good job in that respect. > and if you want a verstile scripting language, it > might make more sense to 'outsource' it to a separate interpreter, > like OS/2 did with Rexx. Yes. With the minor drawback that FreeDOS will never see such an interpreter, unless there is such a thing for linux available, waiting to be ported to DOS. Tom > On Sat, 14 Dec 2024 at 18:42, tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: >> >> >> > * Create a new alternative shell, similar to COMMAND.COM but with expanded >> > BAT programming. >> creating a *new* command.com is a really idiotic idea. the existing >> freecom.com is stable, tested, >> and mostly bugfree. Why would someone even get the idea to create a *new* >> one (including investing >> the work) ? >> >> however, teaching freecom.com new tricks would be welcome, even if pretty >> much nobody >> would ever know about and use them. >> >> > So like Windows's CMD.EXE with FOR /L and FOR /D and FOR /F etc? >> exactly. additionally, CMD.EXE has useful features like >> set /A count=%count% + 1 # arithmetics >> set W # list environment variables starting with >> W >> echo %date% # 14.12.2024 >> echo %date:~0,2%'th day of month %date:~3,2% in year %date:~6,4% # 14'th >> day of month 12 in year 2024 >> and probably many more. >> >> may I suggest in addition >> TYPE /B file1 >> file2 # append file1 to file2 *in BINARY mode, >> ignoring ^Z and CR/LF >> >> >> some (like the extended FOR options) may be more complicated, some fairly >> easy. >> >> >> of course, fixing one of the latest discovered freecom bugs (?) might also >> be nice; >> essentially fixing not well defined behaviour, similar to >> >> COPY File1+File2+File1 File1 >> >> i.e. reusing the output file for input after modifying it. >> would have to start with investigation on how other implementations >> (MSDOS,WINNT) handle this. >> >> Tom >> _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
