Date: Sun, 30 Aug 1998 18:02:12 +0300 (IDT) From: Eli Zaretskii To: "Peter J. Farley III" cc: djgpp AT delorie DOT com Subject: Re: Subtle bash/ls/environment bug? In-Reply-To: <35e89dbf.32961430@news1.banet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.