Danilo, > Tom, what's the joke with the references to Linux? Not Linux specifically. ANY decent interpreter ready to be ported would do.
I just don't expect someone writing something new from scratch. And DOS certainly has not been waiting for REXX and friends. Tom > Not that I would > mind. I've run Linux since 1994. Took home an early Slackware system > on 64 floppy disks, had to write an X11 driver for my weird-ass 512K > Realtek SVGA card and then ruined my eyes looking at 1024x768 pixels > interlaced, but why would FreeDOS require an interpreter from Linux? > If anything, OS/2 was the better DOS. Yout might have triggered me ito > proting Rexx... > On Sun, 15 Dec 2024 at 00:26, tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: >> >> >> > 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
