Yes, that SET /E is a tricky beast. I am currently struggling to implement this for EDR command.com for the EDR-DOS fork at https://github.com/SvarDOS/edrdos. At first this seems to be easy to implement. But as always, the tasks that seem to be easy…
I also had some thoughts of how to process pipes in the context of set /e. And my conclusion was that the output of set /e should be piped, because that fits the ordinary parsing of the command line best. Is there already an issue for this at https://github.com/FDOS/freecom/issues? If not would be good to open one. Greetings, Bernd > Am 31.01.2024 um 09:05 schrieb Jerome Shidel via Freedos-devel > <freedos-devel@lists.sourceforge.net>: > > Hi All, > > This bug has been around a very long time. I just did not think of mentioning > it until now. > > The FreeCOM SET /E bug is easy to reproduce by trying to use I/O redirection. > > Example: > > set /e TEST=time /d | more > > Now, the behavior of pipe here is debatable. > It could redirect from “time /d” into “set /e TEST=“. > Or, it redirect the output from “set /e TEST=time /d” instead. > What it should not do is crash the system. > > At present, attempting that will lock up the system with a repeated PC > speaker beep and require a reboot. > > Other uses of SET do not seem to cause this issue. > > For example: > > echo one | set /p TEST= | echo two > > Outputs two and stores one in the TEST variable. > > (Note: not redirecting input to SET when using /P will cause the system to > wait on a carriage return from the console. That is expected behavior.) > > Jerome > > > _______________________________________________ > 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
