From: "Tim Van Holder" To: Subject: Re: New bash 2.04 beta release Date: Tue, 10 Apr 2001 20:24:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AD30C3C.9.75C575@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 > I've noticed that 2.49e has PACKAGE_VERSION containing the version string > which 2.13 doesn't have. That should be usable in distinguishing the two > unless PACKAGE_VERSION is tossed in the future. And 2.49e uses Yes, there's plenty of ways I could depend on autoconf internals to decide what version it is, but they're internals for a reason. Plus, autoconf internals tend to change a LOT, so a config.site intended to distinguish between 2.13 and 2.50 may think 2.51 is 2.13 and break. > PATH_SEPARATOR, so should the Bash config.site not set > PATH_SEPARATOR=: as it > does now? Ah, good question. The point is that autoconf also AC_SUBSTs PATH_SEPARATOR to be used in template files (Makefile.in, etc.). There's no guarantee it will only be used in shell scripts (where bash will make sure it works properly, as long as it's only used to traverse 'known' PATH-like variables). Having PATH_SEPARATOR set to ':' in config.site (or the environment, for that matter), would "break" autoconf's pathsep check and cause it to use ':' everywhere; this is not a problem as long as it is only used in configure and sh-based Makefiles, but may break some other packages. Using ';' on DOS is more natural anyway, and autoconf can be used to propagate the correct pathsep to the necessary files (for example, my local ld tree has a genscripts.in file that autoconf transforms to genscripts.sh, so it uses ';' instead of ':' where appropriate).