Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Message-Id: <4.3.1.2.20010621113437.0210bae8@pop.ma.ultranet.com> X-Sender: lhall@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 21 Jun 2001 11:36:50 -0400 To: Martin Oberhuber , "'cygwin@sourceware.cygnus.com'" From: "Larry Hall (RFK Partners, Inc)" Subject: Re: ash and bash: Backquotes don't work reliably on Windows 2000 In-Reply-To: <549191FE7B71D311BC5900104B292132010E5084@kirk.takefive.co. at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:19 AM 6/20/2001, Martin Oberhuber wrote: >Hello, > >we have found out that on some Windows 2000 computers (particularly >very fast laptops with rather slow hard disk), the result of a command >in backquotes isn't put into the variable associated reliably. A >command like > >UNAME=`uname` > >will return the correct result most of the time, but will sometimes >return an EMPTY result! It looks like a race condition where the >shell tries to read the program's output before the subprocess for >uname is finished... This is extremely annoying and makes it >impossible to write reliable shellscripts! > >The problem is very hard to reproduce. It seems to turn up only >on few computers, and only with lots of disk access around the >"backquote sections". > >Is this problem already known, and what can we do to fix it? > >I can try and put together a simple shellscript for reproducing >the problem, if needed. This is not a known issue. You're best bet is to try to debug it and inform the list of your findings. I'm sure anyone else with ideas to help you will chime in as appropriate. Larry Hall lhall@rfk.com RFK Partners, Inc. http://www.rfk.com 118 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple