swh@hpcupt1.HP.COM (Steve Harrold) (01/31/90)
Re: TurboC problem >>> 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... ---------- The problem lies in the fact that the "system()" call executes the named program directly without benefit of the "command.com" shell. Because of this, the file redirection intent is not handled by a shell; the "sort" program sees the "<.." and ">.." strings as parameters, which it does not know what to do with. If a shell were present, it (the shell) would process the "<.." and ">.." strings, remove them from the command line, and assign the named files to "stdin" and "stdout". The "sort" program would perceive no parameters. To achieve the intended file redirection you would have to either 1) use something like system("command /c sort <... >..."); 2) or, use the dup() and dup2() library routines to re-assign where "stdin" and "stdout" are to come from before using the simpler system("sort") ; Hope this helps.
ORCUTT@cc.utah.edu (02/01/90)
I don't know if this is the problem, but I had a similar problem with a MAKE I use. A makefile had the line maketbl < table.def > table.c in it. When MAKE was compiled under uSoft C 5.1, the program spawned the above line (using spawn, not system, I think). When spawned, the computer hung, waiting for input from the standard input device. I think that spawning from uSoft C doesn't run COMMAND.COM, but just runs the binary, maketbl in this case. COMMAND.COM does the redirection; without it, "<" was passed as an argument to maketbl, which ignores arguments. I'm not sure that this is the problem mentioned, but it may be.
platt@ndla.UUCP (Daniel E. Platt) (02/02/90)
In article <UZl651y00WB8IWjHtL@andrew.cmu.edu>, bg0l+@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@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
jeenglis@nunki.usc.edu (Joe English) (02/03/90)
ORCUTT@cc.utah.edu writes: > A makefile had the line > > maketbl < table.def > table.c > >I think that spawning from uSoft C doesn't run >COMMAND.COM, but just runs the binary, maketbl in >this case. COMMAND.COM does the redirection; without >it, "<" was passed as an argument to maketbl, which >ignores arguments. Try writing the rule with a '+' in front: +maketbl < table.def > table.c That will force the use of command.com instead of directly spawning the program under Borland's and Zortech's make. It seems to be a convention in MS-DOS. --Joe English jeenglis@nunki.usc.edu
mark.freedman@canremote.uucp (MARK FREEDMAN) (02/04/90)
sM>The problem lies in the fact that the "system()" call executes the sM>named program directly without benefit of the "command.com" shell. Odd .... the Turbo C Reference Guide states "system invokes the DOS COMMAND.COM file to execute a DOS command, batch file, or other program". It continues on to state "system is available on UNIX systems and is compatible with ANSI C. It is defined in Kernighan and Ritchie". mark.freedman@canremote.uucp --- ~ DeLuxe 1.11a20 #4219
john@wsl.UUCP (John Allen on wsl) (02/06/90)
In article <UZl651y00WB8IWjHtL@andrew.cmu.edu> bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: > >The statement: > > system("sort <c:\\directory\\filename.ext >c:\\directory\\filename.ext"); > >from this state, the system hangs up badly. Suggestions? > try this /* connect stdin & stdout to the files you want to process */ freopen("c:/directory/filename.ext", "r", stdin); freopen("c:/directory/filename.ext", "w", stdout); /* spawn the program */ spawnlp(P_WAIT, "sort", "sort", NULL); /* connect stdin & stdout back to the console */ freopen("con", "r", stdin); freopen("con", "w", stdout); -- People that don't know want to know from the people that do know and if the poeple that do know don't tell the people that don't know then the people that don't know still won't know. "Don't quote me on any issue whatsoever."