The last part of your script, i.e. the conversion of slashes to backslashes, is not only unnecessary, but is actually *less* robust than simply leaving the slashes as they are, (which eliminates any concern over what level of escaping you require). Unless you are using some seriously inept software, which goes out of its way to misinterpret slashes in path names, the Win32 BDOS will accept the slash and the backslash as equivalent -- indeed, this is equally true of all versions of MS-DOS since 2.00, (which was the first to support a hierarchical file system), and also of Win16, (which ran on top of MS-DOS in any case).
It seems that the Bourne shell is therefore "seriously inept software" These paths are fed into the configure script where they are used to compute additional paths which are substituted into a configuration header for use within the compiled software.
The only place where you *should* need to pay attention to the distinction between slash and backslash is when you are constructing a command line which is to be parsed by cmd.exe, (or command.com), or one of the command line tools which emulates its CP/M style parsing conventions; IMHO, such cases are best dealt with individually, each in its own context.
Or if additional processing is required using the Bourne shell along with 'echo' or 'printf'. In this case, pre-escaping is valuable.
Notwithstanding the above, your script clearly works for you. I may not agree that it is the best solution for dealing with Win32 paths, but I'm sure that will not dissuade you from continuing to use it.
The script has been working fine for over three years.
Bob ====================================== Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
