Date: Thu, 12 Apr 2001 12:21:29 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: djgpp-workers AT delorie DOT com Subject: RE: New bash 2.04 beta release In-Reply-To: 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 Wed, 11 Apr 2001, Tim Van Holder wrote: > > > An AC_SUBST for a pathsep was very desirable, as it allows files (such > > > as, in the case of autoconf, the test harness) to use the > > correct pathsep > > > for the system. > > > > This is not required by DJGPP. Our Bash will do the right thing both > > with ':' and with ';', provided that the configure script and > > PATH_SEPARATOR are consistent. That is, if the configure script uses > > ';' and PATH_SEPARATOR is ';', the script will work, and the same for > > ':'. > Ah, but not all those files will be shell scripts. Perl, for example, > does not honor PATH_SEPARATOR as far as I know. Sorry, I'm not following: if Perl doesn't honor PATH_SEPARATOR, why would setting PATH_SEPARATOR in any way affect how Perl works? If you meant to say that Perl scripts which were written to honor PATH_SEPARATOR will DTRT, then the name of the variable is not important; it can be anything. PATH_SEPARATOR was introduced into the DJGPP port of Bash several versions (and quite some time) ago. We were there first; it is not nice for Autoconf to usurp that name when doing so could cause trouble for DJGPP. > Also, not all these scripts will be using a path variable that is > recognized and handled by bash. PATH_SEPARATOR was introduced to handle PATH and it alone. It doesn't solve all the problems with using ':' in Unix shell scripts, but it did succeed to let us run configure scripts, and also some other scripts, such as mkinstalldirs, unaltered. If there's a need and a will to solve more problems specific to Autoconf, I will be the first to applaud, but it doesn't feel right to affect PATH_SEPARATOR while at that. PATH_SEPARATOR is a tested feature, so I think it should be left alone. Don't forget that there are quite a few unmaintained packages out there, or packages for which newer DJGPP ports are not available. Those packages will still need to rely on the old ways of getting them to configure and build in the years to come. We cannot rely on always having the bleeding-edge Autoconf in every package DJGPP users compile. Also, there are important packages that still don't use Autoconf. One notable example is GDB, where the gdb/ subdirectory is not autoconfiscated yet. > If it were just scripts being created and run, there would indeed be > no problem; just setting PATH_SEPARATOR to ':' in config.site would be > enough. Whether to set PATH_SEPARATOR in config.site or not is a separate question. If newer versions of Autoconf don't require that because the configure scripts they produce do the Right Thing without PATH_SEPARATOR, we can remove that setting. Or maybe we will decide not to remove it, because some packages which use old Autoconf versions, or don't use Autoconf at all, still need it. But IMHO Autoconf should not _require_ a user to do anything specific with PATH_SEPARATOR, because that would be a step backwards. In other words, if the new Autoconf produces scripts which automatically detect the path separator character and then use it, then those scripts should not require that PATH_SEPARATOR be set in any special way, and they should not themselves set PATH_SEPARATOR to anything. They should use the normal ac_* variables internal to Autoconf. Setting PATH_SEPARATOR in a Makefile is likewise evil, IMHO, because it interferes with the user environment without any real reason. > > > It's also very useful for typical Makefile's that build > > > manuals; they tend > > > to set TEXINPUTS (using a ':' as separator). Now such Makefile.in's can > > > use @PATH_SEPARATOR@ instead and get the correct pathsep at > > > configure time. > > > > This is indeed a welcome change, one that I was talking with varuious > > maintainers about for a long time. But it doesn't need to use the > > same variable name. In fact, it better not use PATH_SEPARATOR, > > because it is quite possible that some scripts which are run by Make > > do not honor PATH_SEPARATOR and still rely on ':' without testing. > > This is the breakage that I'm afraid of. > True, but then it's the scripts that are broken and need to be fixed. That might be true, but how does this help Joe Random User who just wants to build the darn thing? It's the users I'm worried about, not about fixing every script out there. Most of these users don't have a clue about shell script programming, and will not be able to fix such problems. > In any case, it would be easy enough to modify Makefile.in where > necessary and replace the @PATH_SEPARATOR@ with ':' for those instances > where ';' won't work. I strongly believe using ';' as default on DOS > is a Good Thing. ';' is indeed a Good Thing; using PATH_SEPARATOR as a vehicle for that is _not_. > So what would you have me do? I think the name of the variable used by Autoconf should be changed to something of the ac_* variety.