TurboC again

[Daniel E. Platt]

In article <UZl651y00WB8IWjHtL at andrew.cmu.edu>, bg0l+ at andrew.cmu.edu (Bruce E. Golightly) writes:
>...
> The statement:
> 
>     system("sort <c:\\directory\\filename.ext >c:\\directory\\filename.ext");
> 
> causes some odd behaviour. The applications spawns to the DOS level, but does
> not execute the command. While at the DOS level, I can execute the command by\
> entering it manually.
> 
> Now for the really obnoxious bit. When I attempt to get back to the application
> from this state, the system hangs up badly. Suggestions?
> 
> Bruce E. Golightly
> bg0l at andrew.cmu.edu

This sounds interesting... I wonder if this is why Borland doesn't allow
re-direction of stdio in their 'make'?

It sounds to me like there's a problem with the way Borland is managing their
re-direction when they do a 'system()' call.  If you call 'system()' in unix,
there is a 'fork' and an 'exec' to an 'sh' which interprets the command line
for you.  The child's actions on its file descriptors won't screw up the parent.
DOS invokes children in much the same way, except that 'fork' isn't there.
Instead, the child just gets loaded into memory above the parent calling
program (all one process).  If re-direction of 'stdin' and 'stdout' isn't
handled carefully, the child will modify the place these re-directed files
go, and the parent will inherit these.  Doing it from a second level shell
('command.com') may be safer, since 'command.com' should look after itself.
The only thing that bothers me about this explanation is that it seems to me
that 'system()' invokes 'command.com'... maybe there's something about the
way it does this...


Shear conjecture...

Dan Platt