Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
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 18:06:24 -0400 (EDT)
From: Jan Vicherek <honza AT ied DOT com>
To: Glen Coakley <gcoakley AT mqsoftware DOT com>
cc: cygwin AT cygwin DOT com
Subject: RE: How to (dynamically) control Unix/Dos PATH-like variable tran
 slation
In-Reply-To: <E1B42CFD544FD31193EE0000E87C5CE799B4AC@mailserver2.mqsoftware.com>
Message-ID: <Pine.LNX.4.21.0104031748050.936-100000@ann.ied.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


  Hi all,

 Here is the problem I have, and why do I think that the variable
translation would be really useful:

 Products get installed on NT/W2k. These products use environment
variables (ENVVARs), that point to files and directories, to determine
context from which they are being called.

 I am constructing some platform-independent makefiles, which 1) invoke
the installed programs and 2) pass ENVVARs containing pathnames to these
to communicate the context and 3) pass cmd-line args containing pathnames
to the invoked pgms.

 The makefile references the same variables. They do not contain all
relative paths, but ofter contain absolute paths (c:\prod\app\cfg\...).

 It semms to me quite natural, that the ENVVARs (and cmd line params) get
translated when crossing the Windows-Cygwin boundaries.

 It doesn't seem to me easy / easily maintainable to translate a variable
and parse and translate cmd args to windows path using "cygpath" every
time I make an invocation. But I find "cygpath" quite useful otherwise.

 I would welcome any suggestions on how to solve this !

 Would anybody have a suggestion for better solution than translating the
ENVVARs and cmd line args ?

    Thanks,

       Jan

On Mon, 2 Apr 2001, Glen Coakley wrote:

> 
> I also question the usefulness of this. There are special cases where it is
> useful, like when you are passing paths from a windows program to a Cygwin
> one (I created a hack recently to allow me to right-click on a directory and
> get a Cygwin Bash shell in that directory.) But for those cases, I would
> think the 'cygpath' utility would be sufficient.
> 
> ________________________________
> Glen Coakley, Sr. Software Engineer
> MQSoftware Inc., (763) 543-4845
> Have you ever wonder what happens when you run "rm -rf / " but been afraid
> to try it?
> 
> 
> > -----Original Message-----
> > From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> > Sent: Sunday, April 01, 2001 9:23 PM
> > To: cygwin AT cygwin DOT com
> > Cc: honza AT ied DOT com
> > Subject: Re: How to (dynamically) control Unix/Dos PATH-like variable
> > translation
> > 
> > 
> > On Sun, Apr 01, 2001 at 10:00:57PM -0400, Jan Vicherek wrote:
> > >On Sun, 1 Apr 2001, Christopher Faylor wrote:
> > >> On Sun, Apr 01, 2001 at 12:53:28AM -0500, Jan Vicherek wrote:
> > >> >On Fri, 30 Mar 2001, Christopher Faylor wrote:
> > >> >How can I control which variables get translated Dos->Unix when
> > >> >starting a CYGWIN binary from Windows and which variables get
> > >> >translated Unix->Dos when starting a DOS/Windows binary 
> > from CYGWIN ?
> > >> >
> > >> 
> > >http://www.cygwin.com/cygwin-ug-net/using.html#USING-PATHNAMES says
> > >> >that HOME, PATH, and LD_LIBRARY_PATH are converted, but 
> > it doesn't say
> > >> >how to control any additional ones in runtime.
> > >> 
> > >> The main reason for this is that it isn't possible.  Don't 
> > know why you think
> > >> that this list is flexible.  It isn't.
> > >
> > >I didn't see what would preclude the code which says "now translate
> > >PATH variable" from one format to another from saying "now translate
> > >PATH variable and all other variables listed in variable
> > >CYGWIN_TRANSLATABLE"
> > >
> > >Is there a reason why we couldn't have such "CYGWIN_TRANSLATABLE"
> > >variable, which would list names (or patterns) of other 
> > variables that
> > >are to be translated in fashion similair to "PATH" variable ?
> > 
> > Maybe you are misinterpreting what I said.  It isn't possible 
> > because it
> > isn't implemented.  My observation of "Don't know why..." was 
> > basically
> > aimed at the fact that you seemed to be under the impression that this
> > was some kind of undocumented feature.
> > 
> > >What efforts do you estimate it would take to whip up such code ?
> > >
> > >Do you think such feature wouldn't be very useful ?  Why ?
> > 
> > I'm not sure what estimates you're looking for.  It would 
> > probably take
> > me a couple of hours of programming to do this.
> > 
> > Would it be useful?  Since this is the first time that I can 
> > recall that
> > anyone has asked for this, I think it would be only marginally useful.
> > If you are controlling the environment to such a state that 
> > you can add
> > a CYGWIN_TRANSLATABLE variable, then just set the environment 
> > variables
> > using posix paths.  I believe that Cygwin already handles the 
> > ones that
> > should be handled.
> > 
> > However, as usual, if someone wants to contribute a patch, I will
> > consider it's inclusion in the sources.
> > 
> > In case anyone is interested in submitting a patch, please first check
> > out the Contributing link at http://cygwin.com/ .  Read it thoroughly
> > and, when it is time to provide the patch, make sure that you follow
> > all of the rules with regard to the ChangeLog entry, patch format,
> > and coding styles.
> > 
> > cgf


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple