>>> https://sourceforge.net/p/freedos/bugs/88/ set /p fails to close pipe,
>>> leading to creative sources of problems :-p
>> "set /p" is non-standard, and FreeCOM is not exactly actively
>> maintained, so probably close as "wontfix". (As much as I hate to say
>> it, there's probably better tools to do similar functionality. Ask
>> Jerome or take a look at J. Hoffman's DOSUTILS.)
> nothing of FreeCOM is exactly actively maintained. Are you suggesting
> to no longer fix bugs?
> or are you suggesting that *you* are not able/interested/... to fix
> bugs.
also: with world.txt containing
world1
world2
01.12.2016
execute
set /p hello1=<world.txt
set /p hello2=<world.txt
date
echo %hello1%
echo %hello2%
echo %date%
should be fixed by maintainer; results from freely mixing
open()/dup() for file redirection, and fgets() for actual input
processing
fix: SHELL\COMMAND.C
int oldinfd = -1; /* original file descriptor #0 (stdin) */
int oldoutfd = -1; /* original file descriptor #1 (stdout) */
+long oldstdinpos;
...
if (in || (num > 1)) /* Need to preserve stdin */
{
oldinfd = dup(0);
+ oldstdinpos = ftell(stdin);
}
...
if (oldinfd != -1) /* Restore original STDIN */
{
close(0);
dup2(oldinfd, 0);
+ fseek(stdin, oldstdinpos, SEEK_SET );
close(oldinfd);
oldinfd = -1;
}
now I'm wondering how long it takes for
a) a new version of command.com on the website,
b) updateable by the famous FreeDOS 1.0 package management process,
c) updateable by the famous FreeDOS 1.1 package management process, which is
different
d) updateable by the famous FreeDOS 1.2 package management process,
which is probably different, again
Tom
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
