[comp.lang.c] TurboC again

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."