Date: Thu, 8 May 1997 13:30:10 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "John M. Aldrich" <fighteer AT cs DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: DIR/System question - speed
In-Reply-To: <336E545A.4F8C@cs.com>
Message-ID: <Pine.SUN.3.91.970506131551.14346C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 5 May 1997, John M. Aldrich wrote:

> >         The problem is if I do a SYSTEM call, it is WAY to slow, and of course
> > SPAWN or EXEC won't work because dir isn't an executable but a command
> > shell call.

`system' is not much slower than `spawn', so you don't lose anything.

> Well, there's always the popen() command, which allows you to spawn an
> external program and redirect its standard input or standard output to a
> file.

`popen' calls `system' internally, so no gain in speed here, either.

>     while ( !feof( fp ) )
>     {
>         fgets( line, 256, fp );
>         printf( line );
>     }
> 
> Strangely, I just tested this and it froze when the pipe command was
> invoked.  Maybe this is a bug?

Which bug?  Your program worked flawlessly on my machine, both with 
dir.exe from Fileutils and with built-in command of COMMAND.COM.

One thing that you might look into is that it is better to test when 
`fgets' returns a NULL pointer than to call `feof'.  That's because 
`fgets' is not guaranteed to set EOF condition when it reads only part of 
a line.  In DJGPP, it only sets EOF when it can't read *anything*.  So 
your program at the best prints the last line twice, and at worst might 
crash, because you print a line from a call that returned NULL.

But as I said, the problem worked for me, this bug notwithstanding.