[darcs-users] There is a specific, limited, set of ways in which the presence of cygwin on the operating system can have any effect on darcs's functionality.

[zooko]

On Sep 17, 2008, at 13:44 PM, Eric Kow wrote:
>
> Could you kick the buildbot again?

Done.  By the way, Zandr is likely to add more RAM to that (virtual)  
machine and reboot it soon.


> I've pushed a patch to disable the entirety of the record_editor test,
> since the os check seems to be correct.  Previously, I had only  
> disabled
> the last one -- there are three -- because the first two worked under
> MSYS.  Perhaps they do not work under Cygwin.

I'll bet that it has to do with the EDITOR environment variable, or  
the VISUAL environment variable, or the DARCS_EDITOR environment  
variable, or the presence of some tool such as gvim which is  
installed on one machine and not another...

Being "under Cygwin" as such has relatively little meaning for this  
test -- I think it means that the Perl interpreter is a cygwin- 
compile of perl and that when perl invokes a system process it goes  
through the cygwin bash shell.  But when darcs invokes a system  
process it does not, so the fact that the perl interpreter is "under  
Cygwin" shouldn't be construed as meaning that darcs itself is  
operating in some foreign, non-Windows environment if you see what I  
mean.


I feel like I'm having trouble explaining this fact about cygwin.   
Let me put it like this:

There is a specific, limited, set of ways in which the presence of  
cygwin on the operating system can have any effect on darcs's  
functionality.

Those ways are:

1.  If darcs executes an executable in a subprocess, and darcs is  
surprised that the executable acts differently than it expected since  
it accidentally got a cygwin executable rather than a Windows  
executable.

I don't think that this currently happens, although this issue with  
the "editor" might be a case of it, if darcs is executing a  
subprocess named "edit" or something.

2.  If there are some funny environment variables set in the  
environment by tools that changed the user's environment when the  
tool was installed, or set in the environment by the process which  
invoked darcs (which in this case is perl).

If this is the case, we can tell since buildbot helpfully prints out  
the entire contents of the environment at the top of every subprocess  
log, e.g.:

http://buildbot.darcs.net/builders/zooko%20allmydata%20virtual2% 
20Windows-XP%20i386/builds/61/steps/test/logs/stdio

I'm guessing that this issue with the editor is a case of this.

3.  If the process that is using darcs has different behavior with  
regard to pipe management, such as buffering, blocking, etc., because  
that process (e.g. perl running tests, or bash running tests, or a  
user running bash using darcs) is a cygwin app and has different  
assumptions than darcs has about the use of sockets.


However, let me emphasize that, basically, none of these should be  
capable of causing darcs to fail.  Let me try to put it in the  
affirmative sense:

Running darcs "under cygwin" is exactly like running darcs "under  
Windows" in the following ways:

1.  The x86 object code that is being executed is identical in both  
cases.

2.  The interpretation of that object code by the CPU as managed by  
the operating system is indentical in both cases.

3.  Any system calls that darcs makes to Windows are identical in  
both cases -- cygwin is incapable of intercepting system calls and  
causing them to behave differently.

4.  Any dynamic link libraries that darcs uses are identical in both  
cases.

5.  ?  Etc.

There is really only a few very specific possible reasons why being  
"under cygwin" can cause darcs to behave any differently than darcs  
behaves "under Windows".

I hope I've made the point clear.

I suspect that if people train themselves not to say "under cygwin"  
and instead say something more specific, such as "when executed as a  
subprocess of cygwin perl", or "when there is an environment variable  
named VISUAL set" then things will be clearer.

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month