Date:	Wed, 11 Mar 1998 11:00:40 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc:	djgpp AT delorie DOT com
Subject:	Re: Rebuilding config.in in gcc-2.8.1
In-Reply-To:	<35054A42.4ECC@rug.ac.be>
Message-ID:	<Pine.SUN.3.91.980311110023.7344C-100000@is>
MIME-Version:	1.0

On Tue, 10 Mar 1998, Vik Heyndrickx wrote:

> because that ENOENT error was certainly not correct. I now the exact
> code line in the library core that fails. And I haven't got a clue why.
> I even know that the correct filenames are passed to the INT21-7156h
> call.
> i.e. 'autoh14625' and a temporary filename (with a lot of dollar
> characters) to work around a Win95 bug (see the libc sources).

It might be that the devil is in the details.  Please post these:

   1) The *exact* command line which is run (by Bash, I presume),
      before any expansions (that is, if it includes things like
      `pwd` etc., please include them verbatim).

   2) The details of what happens inside the innermost libc function
      that fails (`_rename', if I understand correctly), including the
      file names it uses and the DOS error codes returned by
      `__dpmi_int'.

> Or it must be a program different from bash, that is run from within the
> script and is still running when mv is run. But this cannot be the case
> in DOS, can it?

Not in the same DOS box, no.  The only programs that still ``run'' are
the parent program which spawned `mv' (and any grand-parents etc.).

> > Of course, you should make sure you have the latest port of Bash.
> 
> And also this I can confirm it to be the latest port and release.

Bash 1.14.7 or Bash 2.x?  (I use the former.)

- Raw text -