On Fri, 28 Jan 2005, Stephen wrote: > Good point, if Configure excepts the existence of an echo file in /bin for > the first test, but looks explicitly for /bin/echo.exe for the second test, > Configure might be confusing itself by changing the criteria. Yes indeed. That's why I asked for the output of (that part of) Configure so I could see what it thought it found. > /bin/echo, if that helps to clarify things below. By the way isn't it > standard in Unix that an executable does not have to have an extention to > work, unlike in Windows? Yes, but on Windows the extension does matter, at least sometimes. If you are running a Unix-ish environment under Windows (which I now understand is the case here), then Configure tries to helpfully guess whether or not to append an .exe to the command names. This guess is stored in the Configure variable $_exe. That's apparently getting set to '.exe' in your case, probably due to this code in Configure: elif test -d c:/. -o -n "$is_os2" ; then : OS/2 or cygwin _exe=".exe" Then, later on, when Configure has found '/bin/echo', it unconditionally does eval $file=$xxx$_exe (where file='echo' and xxx=/bin/echo). In short, since you're on Windows, Configure expects the 'echo' command to be called echo.exe, not just a plain 'echo'. fine for everyone else all these years. I don't really know if that $_exe is really required, nor do I know what would happen if we dropped the $_exe there. I suppose we could try it and see, but the current version has been working well for many years for at least some users, so we do have to be careful. I suppose we could put in some sort of additional test -f $xxx$_exe before unconditionally setting the variable. That would probably be safe and wouldn't break anything. -- Andy Dougherty doughera@lafayette.edu