From bug-octave-request at bevo dot che dot wisc dot edu Tue Mar  9 10:36:30 2004
Subject: Randomly failing "ls" command
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: David Bateman <David dot Bateman at motorola dot com>
Cc: bug-octave at bevo dot che dot wisc dot edu
Date: Tue, 9 Mar 2004 10:35:32 -0600

On  9-Mar-2004, David Bateman <David dot Bateman at motorola dot com> wrote:

| I've had someone point out to me that the following sometimes fails in
| 2.1.55 or 2.1.56....
| 
| octave:1> ls
| octave:2> ls
| octave:3> ls
| ascii.mat  binary.mat  hdf5.mat  testls.m
| 
| However,
| 
| octave:4> system('ls');
| ascii.mat  binary.mat  hdf5.mat  testls.m
| 
| always works.... Not sure what the cause of this one is at all, so am just
| reporting the issue at this point...

When you use system('ls'), the command is run directly by the
C-library function system and the output goes to stdout (see the DEFUN
for system in src/toplev.cc).

If you use the Octave function ls, then Octave creates an iprocstream
object to run the command and read the output back into Octave so that
it can send it through Octave's pager (see the DEFUN for ls in
src/dirfns.cc).  There seems to be a race condition so that the output
from running ls is not available when Octave tries to read it.  There
is some code that attempts to handle that situation, but it is either
wrong or not enough.  I've tried, but I don't seem to understand all
the details, so it would be most helpful if someone who does can say
how to fix it properly.

Note that similar problems also exist for the popen2 function.

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------