Mail Archives: djgpp-workers/2000/07/04/12:07:59
> If it's __dosexec_find_on_path that's linked into Bash, it should have
> seen forward slashes in PATH, since stock djgpp.env arranges for that.
Not in this case, because it's searching the PATH in the environment to be
exported to the new process/child/whatever which must use backslashes.
BTW, this problem doesn't happen with Bash 2.03 because it uses it's own
custom routines rather than use spawn* probably because he found that it
didn't work quite right like I've had to find out.
> I think if we need to solve a local problem with scripts, it's
> sufficient to solve it locally in script_exec.
Fair enough. Here's a patch that fixes the problem when used with Bash:
Index: djgpp/src/libc/dos/process/dosexec.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/dos/process/dosexec.c,v
retrieving revision 1.7
diff -c -p -r1.7 dosexec.c
*** dosexec.c 2000/06/14 14:23:44 1.7
--- dosexec.c 2000/07/04 15:38:24
***************
*** 1,3 ****
--- 1,4 ----
+ /* Copyright (C) 2000 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 1999 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 1998 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 1996 DJ Delorie, see COPYING.DJ for details */
*************** static int script_exec(const char *progr
*** 886,891 ****
--- 887,902 ----
else
return -1;
+ /* pinterp may contain backslashes because of __dosexec_find_on_path.
+ Convert them to slashes so Unix shell scripts can run without editing. */
+ p = pinterp;
+ while (*p)
+ {
+ if ((*p) == '\\')
+ *p = '/';
+ ++p;
+ }
+
i = (*spawnfunc)(P_WAIT, pinterp, newargs, envp);
return i;
}
- Raw text -