From: 71231 DOT 104 AT compuserve DOT com (Richard Slobod) Newsgroups: comp.os.msdos.djgpp Subject: Re: shell scripts in DJGPP Date: Wed, 09 Feb 2000 23:13:10 GMT Organization: - Lines: 21 Message-ID: <87ssa1$5lb$1@nnrp1.deja.com> References: <87pes3$2l8$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> NNTP-Posting-Host: 208.242.201.247 X-Article-Creation-Date: Wed Feb 09 23:13:10 2000 GMT X-Http-User-Agent: Mozilla/4.6 [en] (Win98; U) X-Http-Proxy: 1.0 x28.deja.com:80 (Squid/1.1.22) for client 208.242.201.247 X-MyDeja-Info: XMYDJUIDr_slobod To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article , Eli Zaretskii wrote: > That's not surprising: the problems with redirection from a batch file > are a misfeature of COMMAND.COM, caused by the fact that it doesn't > spawn another copy of itself to run the batch. If COMMAND.COM spawned a new shell to run batch files, it would (1) waste precious conventional memory (and note that batch files are often used to launch application programs which might need that memory), (2) make it impossible to permanently set environment variables from a batch file, and (3) make it unsafe to start TSR programs from a batch file. For that matter, this behavior doesn't really prevent I/O redirection with batch files; it just complicates implementing it a bit and Microsoft didn't bother to go to the trouble. Note that 4DOS works the same way and it manages redirection with batch files just fine. Sent via Deja.com http://www.deja.com/ Before you buy.