Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote: The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. Right. I suggested that in cygwin-developers but neither Corinna nor I could really convince ourselves that it was a good idea. cgf -- 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
Re: run changes behavior with cygwin-17.6
On Aug 19 02:03, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote: The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. Right. I suggested that in cygwin-developers but neither Corinna nor I could really convince ourselves that it was a good idea. IMHO it's what you would call a bottomless pit. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 22:17, Corinna Vinschen wrote: On Aug 18 15:51, Charles Wilson wrote: On 8/18/2010 3:41 PM, Corinna Vinschen wrote: Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Yes, I was just looking at that. I think setup_win_environ (or its guts before some early refactoring) pre-dated CW_SYNC_WINENV. Before removing it, I'll have to verify some things -- like whether that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it would be to add if not -- since I want run to work over there too. CW_SYNC_WINENV is available since May 2006. That's Cygwin 1.5.20-1. With respect to the orginal discussion that spawned this thread, I'm going to hold off on any changes to run/run2/cygutils until a consensus is reached regarding: 1) what's going to happen inside cygwin wrt win32 cwd; I'm not sure yet. Maybe we should really go cgf's idea to stick to the Win32 CWD, as long as chdir isn't called the first time. 2) what new APIs are provided In PM we agreed on my suggestion. I just have to test and document it first... 3) and a project on how soon an official 1.7.7 will be released with those changes I think 1.7.7 will be released rather very soon. Maybe this weekend. I applied the patch which adds the CW_SYNC_WINCWD code and I updated the documentation accordingly. I uploaded the rewritten chapter about using the Win32 file API here: http://cygwin.de/cygwin-ug-177/using.html#pathnames-win32-api Please have a look. As for the documentation about CW_SYNC_WINENV, it's already in the official docs at http://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32 HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On 8/19/2010 6:48 AM, Corinna Vinschen wrote: I applied the patch which adds the CW_SYNC_WINCWD code and I updated the documentation accordingly. I uploaded the rewritten chapter about using the Win32 file API here: http://cygwin.de/cygwin-ug-177/using.html#pathnames-win32-api Please have a look. The commentary about the errno values is duplicated. Other than that, it seems clear. I have one question, specifically as it relates to run/run2/cygstart: these apps use CreateProcess. In the documentation, you say: If you need a valid Win32 CWD only for a child application started via CreateProcess and friends, you don't have to set your own Win32 CWD. In that case, just utilize the lpCurrentDirectory parameter. See the description of the CreateProcess function in the MSDN manual pages. But earlier in this thread, you suggested that run/run2/cygstart should use the new CW_SYNC_WINENV. Which is it? As for the documentation about CW_SYNC_WINENV, it's already in the official docs at http://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32 Thanks. -- Chuck -- 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
Re: run changes behavior with cygwin-17.6
On Aug 19 09:20, Charles Wilson wrote: On 8/19/2010 6:48 AM, Corinna Vinschen wrote: I applied the patch which adds the CW_SYNC_WINCWD code and I updated the documentation accordingly. I uploaded the rewritten chapter about using the Win32 file API here: http://cygwin.de/cygwin-ug-177/using.html#pathnames-win32-api Please have a look. The commentary about the errno values is duplicated. Other than that, it Oh, fixed. I missed to upload the latest version of the file. Sorry! (I experimented with DocBook's segmentedlists and tables) seems clear. I have one question, specifically as it relates to run/run2/cygstart: these apps use CreateProcess. In the documentation, you say: If you need a valid Win32 CWD only for a child application started via CreateProcess and friends, you don't have to set your own Win32 CWD. In that case, just utilize the lpCurrentDirectory parameter. See the description of the CreateProcess function in the MSDN manual pages. But earlier in this thread, you suggested that run/run2/cygstart should use the new CW_SYNC_WINENV. Which is it? It's something completely different. CW_SYNC_WINCWD is to sync the CWD. But it's your choice, whether ^^^ you use CW_SYNC_WINCWD or just utilize the lpCurrentDirectory param to CreateProcess. http://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32 Thanks. CW_SYNC_WINENV is for sync'ing the Win32 *environment* with the Cygwin ^^^ environment. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On Thu, Aug 19, 2010 at 10:33:16AM +0200, Corinna Vinschen wrote: On Aug 19 02:03, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote: The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. Right. I suggested that in cygwin-developers but neither Corinna nor I could really convince ourselves that it was a good idea. IMHO it's what you would call a bottomless pit. Yeah, we try to avoid things with the BP acronym these days. cgf -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 10:21, Rodrigo Medina wrote: Hi, After upgrading to cygwin17.6 the program run changes behavior. For example: If I start mintty with the followin .bat @echo off C: chdir \cygwin\bin run mintty -e '/bin/bash' --login -i exit In the mintty window that is started appears the following message: /bin/find: failed to restore initial working directory: No such file or directory 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 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On 18 August 2010 15:51, Rodrigo Medina wrote: After upgrading to cygwin17.6 the program run changes behavior. For example: If I start mintty with the followin .bat �...@echo off C: chdir \cygwin\bin run mintty -e '/bin/bash' --login -i exit In the mintty window that is started appears the following message: /bin/find: failed to restore initial working directory: No such file or directory You can invoke mintty with the cmd.exe built-in 'start' instead of 'run'. Even better, just invoke it directly from a shortcut rather than from a .bat script, which also avoids a console window flashing up briefly. The 'mintty' package in setup.exe automatically creates a suitable shortcut under Cygwin in the start menu. Andy -- 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
Re: run changes behavior with cygwin-17.6
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 -- 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
Re: run changes behavior with cygwin-17.6
On 8/18/2010 10:12 AM, 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. I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. -- David Rothenberger daver...@acm.org micro: Thinker toys. -- 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
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 10:16:50AM -0700, David Rothenberger wrote: On 8/18/2010 10:12 AM, 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. I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? cgf -- 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
Re: run changes behavior with cygwin-17.6
On 18 August 2010 18:16, David Rothenberger wrote: On 8/18/2010 10:12 AM, 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. I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Ouch. This might affect even more cygutils. We really should have thought of that. At least there aren't any chdir() calls in any of the cygutils, so it should primarily be a question of setting the Win32 current directory in line with the POSIX one at startup, in any of the utils that may invoke a Win32 function with a relative path. Chuck, do you need a hand with going through them? Andy -- 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
Re: run changes behavior with cygwin-17.6
On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Andy -- 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
Re: run changes behavior with cygwin-17.6
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.
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.
--
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 - 1.10
+++ src/run.c 18 Aug 2010 18:35:47 -
@@ -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/msg2.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()));
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
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote: On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. ??If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Yes, I guess I did not properly appreciate the fact that we presumably broke every CreateProcess call in a cygwin program when we did this. While I'm on record about not caring too much about that scenario, it seems meaner than usual for us to break this since the report which caused the recent change was from someone calling CreateProcess in a cygwin program. But, anyway, since we have broken this, I don't think we should force every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH. We probably should add an internal interface which sets the current working directory for windows if it can. cgf -- 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
Re: run changes behavior with cygwin-17.6
On 8/18/2010 2:25 PM, Andy Koppe wrote: Ouch. This might affect even more cygutils. We really should have thought of that. At least there aren't any chdir() calls in any of the cygutils, so it should primarily be a question of setting the Win32 current directory in line with the POSIX one at startup, in any of the utils that may invoke a Win32 function with a relative path. Chuck, do you need a hand with going through them? Oh, right. The problem is this: since the win32 CWD is *always* bogus, it is possible that other win32 functions will croak, not just CreateProcess. So, there are a number of native win32 calls in the cygutils tools, like: cygstart: CreateProcess, among others lpr: ...many... putclip/getclip: GetClipboardData, SetClipboardData, etc Now, I haven't tested each of these tools exhaustively under cygwin-1.7.6, so I'm not sure the bogus win32 cwd affects them (except obviously cygstart). But...by their very nature many of these tools use the native w32api. So...each should probably take care to set the win32 cwd if at all possible. Yeah, patches would be great. -- Chuck -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 14:54, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote: On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. ??If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Yes, I guess I did not properly appreciate the fact that we presumably broke every CreateProcess call in a cygwin program when we did this. While I'm on record about not caring too much about that scenario, it seems meaner than usual for us to break this since the report which caused the recent change was from someone calling CreateProcess in a cygwin program. But, anyway, since we have broken this, I don't think we should force every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH. We probably should add an internal interface which sets the current working directory for windows if it can. I'm going to add a new call cygwin_internal (CW_SYNC_WINCWD); which will do the same for the CWD as cygwin_internal (CW_SYNC_WINENV); already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. However, in contrast to CW_SYNC_WINENV, CW_SYNC_WINCWD will return -1 and set errno if setting a Windows CWD fails. The error codes will be typically ENOTDIR if the CWD is a virtual directory EACCESif the directory is actually inaccessible or ENAMETOOLONG if the directory has a pathname 258 chars. I'll also add documentation for this. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 09:13:40PM +0200, Corinna Vinschen wrote: On Aug 18 14:54, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote: On 18 August 2010 19:24, Christopher Faylor wrote: I noticed a similar change in cygstart, too. I used to have a script that would cd to a directory and then run cygstart. After the upgrade to 1.7.6, this stopped working. I had to use the --directory switch to cygstart to get the right behavior. Call me dense but I don't understand why any changes are needed. ??If you're cd'ed to a non-Cygwin-special location why doesn't stuff just work? The Win32 working directory is changed to '\\?\PIPE\' at process startup, otherwise the working directory can't be deleted from under the process, which you can do on Linux. Yes, I guess I did not properly appreciate the fact that we presumably broke every CreateProcess call in a cygwin program when we did this. While I'm on record about not caring too much about that scenario, it seems meaner than usual for us to break this since the report which caused the recent change was from someone calling CreateProcess in a cygwin program. But, anyway, since we have broken this, I don't think we should force every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH. We probably should add an internal interface which sets the current working directory for windows if it can. I'm going to add a new call cygwin_internal (CW_SYNC_WINCWD); which will do the same for the CWD as cygwin_internal (CW_SYNC_WINENV); Actually I just checked in CW_SETCWD which just calls SetCurrentDirectoryW. I was just going to request trying a snapshot when I saw your message. already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. cgf -- 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
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. cgf -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 15:19, Christopher Faylor wrote:
On Wed, Aug 18, 2010 at 09:13:40PM +0200, Corinna Vinschen wrote:
I'm going to add a new call
cygwin_internal (CW_SYNC_WINCWD);
which will do the same for the CWD as
cygwin_internal (CW_SYNC_WINENV);
Actually I just checked in CW_SETCWD which just calls
SetCurrentDirectoryW. I was just going to request trying a snapshot
when I saw your message.
Oh. Shouldn't SetCurrentDirectoryW only be called if cygheap-cwd.get_error
is 0? Here's what I had in mind:
Index: external.cc
===
RCS file: /cvs/src/src/winsup/cygwin/external.cc,v
retrieving revision 1.116
diff -u -p -r1.116 external.cc
--- external.cc 4 Jul 2010 17:12:26 - 1.116
+++ external.cc 18 Aug 2010 19:37:33 -
@@ -162,6 +162,24 @@ sync_winenv ()
free (envblock);
}
+/* Synchronize Win32 CWD with Cygwin CWD. Return -1 and set errno if
+ setting the Win32 CWD fails. */
+static unsigned long
+sync_wincwd ()
+{
+ if (cygheap-cwd.get_error ())
+{
+ set_errno (cygheap-cwd.get_error ());
+ return (unsigned long) -1;
+}
+ if (!SetCurrentDirectoryW (cygheap-cwd.win32.Buffer))
+{
+ __seterrno ();
+ return (unsigned long) -1;
+}
+ return 0;
+}
+
/*
* Cygwin-specific wrapper for win32 ExitProcess and TerminateProcess.
* It ensures that the correct exit code, derived from the specified
@@ -514,6 +532,9 @@ cygwin_internal (cygwin_getinfo_types t,
res = (uintptr_t) strerror (err);
}
break;
+ case CW_SYNC_WINCWD:
+ res = sync_wincwd ();
+ break;
default:
set_errno (ENOSYS);
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, the current change affects every one of those programs and more. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Yes. cgf -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 21:34, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On 18 August 2010 20:39, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, the current change affects every one of those programs and more. Right, that's a pretty big argument for favouring Windows integration rather than Linux compatibility here. So what would be the consequences of not allowing the current working directory of a running process to be deleted? And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Yes. I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). Andy -- 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
Re: run changes behavior with cygwin-17.6
On Wed, 18 Aug 2010, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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
Re: run changes behavior with cygwin-17.6
On 8/18/2010 3:41 PM, Corinna Vinschen wrote: Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Yes, I was just looking at that. I think setup_win_environ (or its guts before some early refactoring) pre-dated CW_SYNC_WINENV. Before removing it, I'll have to verify some things -- like whether that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it would be to add if not -- since I want run to work over there too. With respect to the orginal discussion that spawned this thread, I'm going to hold off on any changes to run/run2/cygutils until a consensus is reached regarding: 1) what's going to happen inside cygwin wrt win32 cwd; 2) what new APIs are provided 3) and a project on how soon an official 1.7.7 will be released with those changes and then evaluate how best to modify the client apps. -- Chuck -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 20:47, Andy Koppe wrote: On 18 August 2010 20:39, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, the current change affects every one of those programs and more. Right, that's a pretty big argument for favouring Windows integration rather than Linux compatibility here. So what would be the consequences of not allowing the current working directory of a running process to be deleted? And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Yes. I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). The question here is a bit tricky, me thinks. 1) Do we want as much POSIX compatibility as possible? 2) Do we want POSIX compatibility but not compromise on Win32 compatibility? 3) Do we want as much POSIX compatibility as possible, but are willing to compromise if it breaks backward compatibility in the Win32 realms? Right now I tend strongly to 1, but I'm still open to 3 if the problems are really too heavy. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On Wed, 18 Aug 2010, Brian Ford wrote: Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. Nevermind, sigh... -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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
Re: run changes behavior with cygwin-17.6
On 08/18/2010 01:55 PM, Corinna Vinschen wrote: I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). The question here is a bit tricky, me thinks. 1) Do we want as much POSIX compatibility as possible? POSIX allows the refusal to delete an in-use directory; and Solaris NFS mounts behave this way. But since Linux can delete in-use directories (where an in-use directory includes the condition of at least one process owning that directory as its cwd), and cygwin emulates Linux rather than POSIX, we can try harder if it makes sense. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: run changes behavior with cygwin-17.6
On Aug 18 14:49, Brian Ford wrote: On Wed, 18 Aug 2010, Corinna Vinschen wrote: On Aug 18 15:22, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote: already does for the environment. Dropping the environment had roughly the same consequences way back when, after all. Except that not every program uses the windows environment. This affects quite a few native windows calls. It affects every program which calls CreateProcess or ShellExecute, for instance. This includes GDB, tcl, run, run2, cygstart, etc. And, for that reason, I think we should reconsider this change. Maybe as a compromise maybe we could at least avoid cd'ing to the dummy location on entry to the first cygwin program. I disagree. When do you change the directory to //?/pipe then? The first time chdir is called? Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. It breaks POSIX compatibility in terms of not being able to rename or delete a directory which is the CWD of any process. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On 08/18/2010 01:58 PM, Corinna Vinschen wrote: Can someone please remind me why you shouldn't change to that directory only when SetCurrentDirectory would fail due to a long path, virtual path, etc? I think it was covered in the developer list, but I can't find it right now. It breaks POSIX compatibility in terms of not being able to rename or delete a directory which is the CWD of any process. It breaks Linux, but not POSIX, compatibility. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: run changes behavior with cygwin-17.6
On Aug 18 15:51, Charles Wilson wrote: On 8/18/2010 3:41 PM, Corinna Vinschen wrote: Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Yes, I was just looking at that. I think setup_win_environ (or its guts before some early refactoring) pre-dated CW_SYNC_WINENV. Before removing it, I'll have to verify some things -- like whether that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it would be to add if not -- since I want run to work over there too. CW_SYNC_WINENV is available since May 2006. That's Cygwin 1.5.20-1. With respect to the orginal discussion that spawned this thread, I'm going to hold off on any changes to run/run2/cygutils until a consensus is reached regarding: 1) what's going to happen inside cygwin wrt win32 cwd; I'm not sure yet. Maybe we should really go cgf's idea to stick to the Win32 CWD, as long as chdir isn't called the first time. 2) what new APIs are provided In PM we agreed on my suggestion. I just have to test and document it first... 3) and a project on how soon an official 1.7.7 will be released with those changes I think 1.7.7 will be released rather very soon. Maybe this weekend. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On Aug 18 13:57, Eric Blake wrote: On 08/18/2010 01:55 PM, Corinna Vinschen wrote: I'm not convinced such a compromise would be worthwhile, because it would forfeit Linux compatibility while still breaking some Win32-using programs. I think it should be one way or the other: either stick with the current approach, or always sync the Win32 working directory up-to-date (except when that's not possible). The question here is a bit tricky, me thinks. 1) Do we want as much POSIX compatibility as possible? POSIX allows the refusal to delete an in-use directory; and Solaris NFS mounts behave this way. But since Linux can delete in-use directories (where an in-use directory includes the condition of at least one process owning that directory as its cwd), and cygwin emulates Linux rather than POSIX, we can try harder if it makes sense. That lets me more tend to 3 now (cgf's idea to defer until the first chdir). I'm still chewing nails, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: run changes behavior with cygwin-17.6
On 8/18/10 1:19 PM, Corinna Vinschen wrote: POSIX allows the refusal to delete an in-use directory; and Solaris NFS mounts behave this way. What about renaming directories though? (Damn this tight coupling Windows has between files and filenames.) But since Linux can delete in-use directories Not just Linux -- OS X and the other BSDs too, presumably, allow renaming and deleting directories that are the CWD of some process. (where an in-use directory includes the condition of at least one process owning that directory as its cwd), and cygwin emulates Linux rather than POSIX, we can try harder if it makes sense. That lets me more tend to 3 now (cgf's idea to defer until the first chdir). I'm still chewing nails, though. IMVHO, #1 is the right choice. It's a lot less surprising than #3, and it fails safe. It's a very simple model: relative filename use will fail unless you do something special, and by doing something special, you signify that you understand the magic. I can imagine #3 causing subtle bugs in programs that only chdir() sometimes. Using Win32 functions in a Cygwin program already requires extra knowledge; adding CWD tracking doesn't hurt much. The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. -- 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
