Mail Archives: cygwin/2001/04/03/21:48:07
On Tue, Apr 03, 2001 at 09:24:52PM -0400, Jan Vicherek wrote:
>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'm failing to see what value having a Cygwin program in the middle of
this process brings to anything. It sure seems like it is just complicating
things.
However, if the middle cygwin program knows that it is translating paths,
then it can call the appropriate Cygwin functions to do this itself without
burdening the Cygwin DLL with more feature cruft.
>> 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.
Again, translate the environment variables *yourself* in the Cygwin program.
> 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"
Except for feeping creaturism. I really am not convinced that this is
a good thing for Cygwin to be doing. It complicates the environment variable
scanning which is already sort of slow. I don't like to introduce options
that will be convenient for a small minority but impact everyone.
> 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."
It is much much easier for me to say "Deal with it in your Cygwin
program".
Also, most Cygwin programs should be able to deal just fine with Windows
style paths. So, just use those.
> 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 ?
I don't quite understand the "sometimes can, sometimes don't want to,
but sometimes cannot change". If it is a Cygwin program, you have the
source. You absolute, positively categorically can change it.
Regardless, (is my face blue yet?) show me a patch. I'm dubious about
adding this feature but perhaps actual source code will convince me.
This argument is completely moot if no one is going to take the time
to implement this.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -