This is the mail archive of the
mailing list for the Cygwin project.
Re: How to (dynamically) control Unix/Dos PATH-like variable translation
- To: cygwin at cygwin dot com
- Subject: Re: How to (dynamically) control Unix/Dos PATH-like variable translation
- From: Jan Vicherek <cygwin-user at ied dot com>
- Date: Tue, 3 Apr 2001 21:24:52 -0400 (EDT)
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
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
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
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
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. ##
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple