Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Tue, 3 Apr 2001 21:24:52 -0400 (EDT) From: Jan Vicherek To: cygwin AT cygwin DOT com Subject: Re: How to (dynamically) control Unix/Dos PATH-like variable tran slation In-Reply-To: <20010403195342.A1588@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Chris, On Tue, 3 Apr 2001, Christopher Faylor wrote: > On Tue, Apr 03, 2001 at 06:06:24PM -0400, Jan Vicherek wrote: > > Would anybody have a suggestion for better solution than translating the > >ENVVARs and cmd line args ? > > If you are using Cygwin programs, then set the environment variables > using UNIX paths. > > If you are using non-Cygwin programs, then use Windows paths in the > environment variables. Environment variable A contains some path(s). I'm using non-Cygwin programs, which set variable A, then they call Cygwin programs (for process control, makefiles and bash scripts, etc, for building stuff). These Cygwin programs use and set variable A, and then in turn call non-Cygwin programs, which again use the variable A. I'm failing to see how the ENVVAR/cmd_args translation on demand could cause more problems than it solves. > I really don't understand the problem. Environment variables like HOME, > TMP, and PATH which have meaning in both a UNIX and Windows environment > obviously need to be translated. > > Environment variables like LENNYSOFTWARE don't need to be translated. > If The "lenny" software is a Cygwin program then the LENNYSOFTWARE > environment variable should be set to a Cygwin path. If it is a Windows > native program then the environment variable should be set to a Windows > path. It only makes sense to use the same variable in both. See above. Translating them maually every time control is about to be handed over the Win/Cygwin boundary is cumbersome, sometimes even impossible. Using different variables may be another cumbersome solution, but again keeping them in sync has to be done manually, which is almost the same level of pain. I still fail to see any more natural solution than saying "My cygwin process needs to be able to reference and access paths stored in windows env. variables PATH_TO_X and CLASSPATH. So add their names to special variable CYGWIN_TRANSLATE_ENVVARS_W2C" and saying "The Windows binaries that my cygwin process calls need to understand variables PATH_TO_Y and ZIPPATH that my cygwin process sets and uses and the Windows binaries use them. So add their names to special variable CYGWIN_TRANSLATE_ENVVARS_C2W" and saying "My cygwin programs is called by both cygwin programs and by Windows programs. These cygwin programs of mine receive paths on their command line args. It is difficult (and sometimes impossible) to change all of these cygwin programs to process their cmd line args to translate every occurance of a path from Windows path to Unix path. It is much easier to execute these Cygwin programs with variable CYGWIN_TRANSLATE_ARGS_W2C set, and all that work is done automatically behind the scenes. If these programs are expected to receive the original args, I simply will not set the ENVVAR CYGWIN_TRANSLATE_ARGS_W2C before I call them." and saying "My Windows programs is are unchangeable, yet I have to call them both from other Windows programs (which I cannot change), and from other Cygwin programs (which I sometimes can, sometimes don't want to, but sometimes even cannot change). So whenever I want my cygwin program to pass Windows paths to the windows app, I'll just set the CYGWIN_TRANSLATE_ARGS_C2W before I start it, and viola, my windows programs will receive the windows paths !" Do these scenarios seem unreasonable ? Am I missing something ? -- -- Gospel of Jesus is the saving power of God for all who believe -- ## To some, nothing is impossible. ## http://Honza.Vicherek.com/ -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple