X-Spam-Check-By: sourceware.org Date: Mon, 30 Jan 2006 17:57:45 -0500 (EST) From: Igor Peshansky Reply-To: cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com Subject: Re: MSYS path behavior in Cygwin In-Reply-To: <43DE9658.FBF4BF05@dessent.net> Message-ID: References: <01a101c625bb$56eef210$a501a8c0 AT CAM DOT ARTIMI DOT COM> <43DE9658 DOT FBF4BF05 AT dessent DOT net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mon, 30 Jan 2006, Brian Dessent wrote: > tom wrote: > > > I guess the two will be mutually exclusive, unless you Cygwin devs see > > some reason to merge some of Earnie's work. I'm have to believe > > there's some reason why it hasn't been done though. I'm sure it's > > non-trivial to say the least. > > > > Thanks for the help anyways! Cygwin and msys make life in Win32land > > bearable. > > To do that would go against the grain of what Cygwin is trying to > accomplish: provide a full posix environment. So to have > argument-translation code sort of defeats that purpose since all Cygwin > programs are supposed to recognise posix paths. > > Now in reality, everyone has to run a non-Cygwin program from time to > time, so of course there will be times where you run up against this. > But the question becomes, when should the library translate paths, and > when should it leave them alone? Because you can't just unconditionally > do it. The way MSYS handles this is by assuming that everything in the > MSYS bin directory is a MSYS binary that can handle posix paths, and > that everything else is a win32/mingw app that needs win32 paths. Now > that's a rather stark and arbitrary distinction. It works for MSYS > since it's intended to be a rather minimal system, just enough to build > packages using auto{conf,make},libtool. But I think for Cygwin this > would be way too restrictive. Unfortunately, sometimes you can't do this even if you know that a Win32 program is being invoked. The problem is that an arbitrary string with a "/" in it may or may not be a path to a file -- and the only way to know is to understand the semantics of the arguments. Since you don't always know those semantics, doing this in general is impossible. > The workaround that I think most people use is a wrapper script that > essentially just runs "cygpath -w" on each argument and then execs $1. > So you can type "wrapper win32program /posix/path/to/file" and it ends > up running "win32program c:/win32/path/to/file". If you do it right, > you can make this quite generic, so that you just prepend "wrapper" (or > whatever you want to call it.) > > Below is one that I use in my .bashrc that calls perl. It's probably > got bugs, and it's not perfect -- for example if you pass something like > -I/usr/local/bin it will not know how to translate that. > [snip] For more comprehensive behavior, you need to have program-specific wrapper scripts. For example, see my Java wrappers in the cygwin-apps CVS: . Notice that even those scripts don't do a complete job, since arguments given to the Java programs themselves are left as-is (by design, because those scripts can't just go about mangling arbitrary strings). Igor P.S. Is "dodos" short for "extinct birds"? :-) -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/