Re: "run" changes behavior with cygwin-17.6

[Charles Wilson]

On 8/18/2010 1:12 PM, Charles Wilson wrote:

On 8/18/2010 11:09 AM, Corinna Vinschen wrote:

Looks like the "run" tool now needs a call to

CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));

and then use win32_cwd in the call to CreateProcess.

See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api

Yep. run2 also needs a similar update.

Thanks for the heads up; I didn't really think about how the recent
changes to cygwin's cwd handling would affect those two packages.

--
Chuck

Index: src/run.c
===================================================================
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.10
diff -u -p -r1.10 run.c
--- src/run.c   2 Dec 2009 02:51:54 -0000       1.10
+++ src/run.c   18 Aug 2010 18:35:47 -0000
@@ -198,6 +198,33 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
          {
            STARTUPINFO start;
            PROCESS_INFORMATION child;
+#if defined(__CYGWIN__)
+           /* Special CWD handling needed when calling CreateProcess() from a
+           * cygwin program, when cygwin kernel is 1.7.6 or above. See 
discussion
+           * in the following threads:
+           *   http://cygwin.com/ml/cygwin/2010-08/msg00205.html
+           *   http://cygwin.com/ml/cygwin-developers/2010-08/msg00002.html
+           */
+           char * win32_cwd;
+           long size;
+           char *posix_buf;
+           char *posix_cwd = NULL;
+           size = pathconf(".", _PC_PATH_MAX);
+           if ((posix_buf = (char *)malloc((size_t)size)) != NULL)
+             {
+               posix_cwd = getcwd(posix_buf, (size_t)size);
+               if (posix_cwd)
+                 {
+# if defined(HAVE_DECL_CYGWIN_CONV_PATH)
+                   win32_cwd = (char *) cygwin_create_path 
(CCP_POSIX_TO_WIN_A, (void *) posix_cwd);
+# else
+                   win32_cwd = (char *) malloc (MAX_PATH);
+                   if (win32_cwd)
+                     cygwin_conv_to_win32_path (posix_cwd, win32_cwd);
+# endif
+                 }
+             }
+#endif
            ZeroMemory( &child, sizeof(PROCESS_INFORMATION) );
            ZeroMemory (&start, sizeof (STARTUPINFO));
            start.cb = sizeof (STARTUPINFO);
@@ -209,9 +236,26 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
                FALSE,   /* handles are NOT inherited,          */
                0,       /* creation flags                      */
                NULL,    /* use parent's environment            */
-               NULL,    /* use parent's current directory      */
+#if defined(__CYGWIN__)
+               win32_cwd, /* working directory; may be null    */
+#else
+               NULL,    /* use parent's working directory      */
+#endif
                &start,  /* STARTUPINFO pointer                 */
                &child); /* receives PROCESS_INFORMATION        */
+#if defined(__CYGWIN__)
+           if (win32_cwd)
+             {
+               free (win32_cwd);
+               win32_cwd = NULL;
+             }
+           if (posix_buf)
+             {
+               free (posix_buf);
+               posix_buf = NULL;
+               posix_cwd = NULL;
+             }
+#endif
            if (ret_code == 0)
              {
                Trace(("getlasterror: %d\n", GetLastError()));

The following patch seems to fix it for me. There will still be problems if the win32-converted cwd is (a) longer than 259 chars, or (b) derived from a cygwin-specific "virtual" path. I don't want to duplicate all of cygwin's spawn_guts functionality in run, run2, and cygstart, so I think (a) and (b) are acceptable. After all, USUALLY you will invoke these tools via double-clicking some icon...so cygwin-specific or too-long paths are not an issue.

run.exe.bz2
Description: Binary data

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple