Date:	Sun, 30 Aug 1998 18:02:12 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: Subtle bash/ls/environment bug?
In-Reply-To:	<35e89dbf.32961430@news1.banet.net>
Message-ID:	<Pine.SUN.3.91.980830180146.20257r-100000@is>
MIME-Version:	1.0

On Sun, 30 Aug 1998, Peter J. Farley III wrote:

> because a relative path (../intl/lib*) works, but the
> absolute path version "//h/mc-4.1.35/intl/lib*" causes the "ls"
> command to produce ENOENT errors.

You should *never* let DJGPP programs except Bash itself see pathnames
such as //h/mc-4.1.35/.  The only program that understands them is
Bash itself; other DJGPP programs will choke on them.

I don't have enough information to tell you how to correct that in
your case.  If you run GCC from the Bash prompt, just use the usual
DOS h:/mc-1.4.35 form.  If the //h/foo pathnames come from the
Makefile, you will need to figure out how did they get there and
change the configure script accordingly.

One thing I always do when running configure scripts is to set
PATH_EXPAND=y in the environment; you should also do that when running
Bash interactively.  Usually, this does the trick for me.

I tried to ask the other DJGPP developers whether it was a good idea
to add in v2.02 support for the //h/foo pathnames in the core DJGPP
library (so that all DJGPP programs will know about that), but there
were too many negative responces with concerns about things that might
break, so I guess it won't happen.

- Raw text -