On Thu, Aug 11, 2005 at 02:20:04PM -0400, Christopher Faylor wrote: >On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote: >>> Well, it's stopping a real fix for the MinGW build failure being made. >>> Adding #! support to libiberty won't work because the problem scripts >>> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely >>> to be valid to plain Windows. >> >>DJGPP solves this thusly: >> >> /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try >> it with the usual extensions and, if that fails, will further >> search for the basename of the shell along the PATH; this >> allows to run Unix shell scripts without editing their first line. */ > >That was the technique I am in the process of using, too. > >Hmm. You know, I probably should just steal the code from DJGPP...
I am nearly ready to commit this patch but I went overboard and had it search in mingw and MSYS locations for the program to run (i.e., "/bin/sh"). Then it occurred to me that maybe this was a little too "product specific" for something like libiberty. So, the question is, should pex-win32.c encapsulate specific knowledge about MinGW and MSYS? Or should I yank out that code and just search for "sh" along the path? FWIW, finding the appropriate directories for MinGW and MSYS requires using a few of WindowsRoutinesForQueryingStuff. cgf