From: "Mark E." To: djgpp-workers AT delorie DOT com Date: Mon, 3 Apr 2000 14:47:33 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Bash 2.04 beta 1 now available Message-ID: <38E8AF05.4358.10FAD1E@localhost> References: <38E71B1E DOT 17249 DOT B912B AT localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com > Is that really a good idea? This could break non-DJGPP programs Why use DJGPP-specific filenames with non-DJGPP programs? > 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. > > What are the reasons for dropping PATH_EXPAND, anyway? After all, if > someone doesn't want it, they can simply avoid using it. Because updating the SimTel packages will fix the need for this, and 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. Chances are slim and none that this feature will be put back as-is. I am open to another way of handling this translation, as long as it's easier to maintain. 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`' > And what about PATH_SLASH? It decides which directory separator is used for environment variables that are converted from 'c:/foo/bar' to '/dev/c/foo/bar' form. When PATH_SLASH is '\', PATH_SEPARATOR is ':', and PATH is 'c:\djgpp\bin;c:\windows', PATH in Bash is translated to '\dev\c\foo\bar'. The problem with this is Bash doesn't recognize '\' as a path separator, and libc's _put_path2 won't translate it properly. Slashes are always translated to backslashes in the exported environment, so PATH_SLASH serves no purpose there either. > 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? If so, I agree it wasn't a very good solution.