From: pavenis AT lanet DOT lv
Message-ID: <B0000102979@stargate.astr.lu.lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, Davin McCall <DavMac AT iname DOT com>,
        djgpp AT delorie DOT com
Date: Fri, 24 Sep 1999 11:00:01 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Compiling GCC
References: <B0000102732 AT stargate DOT astr DOT lu DOT lv>
In-reply-to: <Pine.SUN.3.91.990923104155.10652E-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12a)
Reply-To: djgpp AT delorie DOT com

On 23 Sep 99, at 10:45, Eli Zaretskii wrote:

> 
> On Wed, 22 Sep 1999 pavenis AT lanet DOT lv wrote:
> 
> > > djconfig.log's first line reads:
> > > 
> > > c:/djgpp/bin/sed.exe: -e expression #2, char 1: Unknown command: ``.''
> > > 
> > > Maybe this is the problem?
> > > 
> > It seems to be due bug in DJGPP port of bash-1.14.7 (result depends 
> > on length of name of directory where gcc sources are unpacked, mor 
> > exactly perhaps length of full patch:
> > 	c:/tmp/x/   - problem was there
> >        c:/tmp/xxxxxxxx/  - no problem
> 
> Bash does some special magic for Sed, because the automatic 
> transformation of the //x/foo form of the DOS file names can misfire if 
> it is actually a Sed script that uses slashes.  Perhaps this is what 
> causes Bash to fail in this case.
> 
> One more proof that //x/foo is not such a good idea, if you ask me.
> 

I would agree that //x/foo is not nice idea, but I also think that 
dependence of results on directory name (results are different for
c:/tmp/x/   and   c:/tmp/xxxxxxxx/  shows that we perhaps have a bug

Andris