Date: Tue, 4 Apr 2000 13:55:01 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: Bash 2.04 beta 1 now available In-Reply-To: <38E8AF05.4358.10FAD1E@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 3 Apr 2000, Mark E. wrote: > > Is that really a good idea? This could break non-DJGPP programs > > Why use DJGPP-specific filenames with non-DJGPP programs? Because some shell script might require that. The /dev/c/foo feature was invented to help out shell scripts which would be impractical to modify. Also, there are people who use Bash as their interactive shell, which means they invoke non-DJGPP programs from it. If they set PATH_SEPARATOR=: (for running shell scripts), the non-DJGPP programs will break. > > and > DJGPP programs compiled with old versions of libc. > > Then update them. The only package left that needs PATH_EXPAND for use in > configure scripts is Fileutils. So this means people won't be able to upgrade to the new Bash until I find the time to report Fileutils (and Sh-utils, and Findutils, and cpio, and TeX/Web2c, and...)? Sounds a bit too tough on users, doesn't it? > the code > to implement it is very fragile and has become unmaintainable and unreliable > due to internal changes starting in Bash 2.03 and more so in Bash 2.04. FWIW, I didn't have any problems in Bash 2.03 with these features. > I am open > to another way of handling this translation, as long as it's easier to > maintain. I have never looked at the sources that do this conversion. If you could explain why is it hard to maintain, perhaps someone could come up with useful ideas. > The only idea I to offer (and it's a bad one) is to create a > builtin called 'realpath', so 'realpath /dev/c/djgpp/bin' would write > 'c:/djgpp/bin' to stdout. Then do 'prog.exe `realpath /dev/c/djgpp/bin`' This would mean that shell scripts will have to be changed, which kinda defeats the purpose of the feature. > Slashes are always translated to backslashes in the exported > environment, so PATH_SLASH serves no purpose there either. Yes, I agree. I wonder if PATH_SLASH was ever widely used at all; I don't think I recall anybody ever asking about it. > > As for SYSROOT, I have no problems with dropping it: I think it was evil in > > the first place. > > Was it supposed to handle the '/bin/sh' problem? Not /bin/sh (which was supported by the library since v2.01), but other /bin/foo and /tmp strings you meet in many shell scripts. These cases are nowadays considered bugs by all GNU maintainers, so the right solution is to fix the scripts instead of using SYSROOT.