delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/04/03/19:11:01

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:55:29 -0400
From: linguist-cygwin AT rich-paul DOT net
To: Jan Vicherek <honza AT ied DOT com>
Cc: Glen Coakley <gcoakley AT mqsoftware DOT com>, cygwin AT cygwin DOT com
Subject: Re: How to (dynamically) control Unix/Dos PATH-like variable tran slation
Message-ID: <20010403185529.A11153@monster.master-link.org>
References: <E1B42CFD544FD31193EE0000E87C5CE799B4AC AT mailserver2 DOT mqsoftware DOT com> <Pine DOT LNX DOT 4 DOT 21 DOT 0104031748050 DOT 936-100000 AT ann DOT ied DOT com>
Mime-Version: 1.0
User-Agent: Mutt/1.3.16i
In-Reply-To: <Pine.LNX.4.21.0104031748050.936-100000@ann.ied.com>; from honza@ied.com on Tue, Apr 03, 2001 at 06:06:24PM -0400
X-Operating-System: Linux monster 2.2.13

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Just to put my two cents in, I would LOVE to see this patch!  I'm using a
cygwin build environment to product a product from both c++ and java source.
CLASSPATH is a *NIGHTMARE* to deal with.  I finally write a script that
generates it, but it is really inefficient.

Portability is another concern with switching variables from DOS format to
POSIX and back ... you have to have a stubbed cygpath on your POSIX platfor=
ms,
or perform some other hack.  Changes to this stuff on one platform nearly
always breaks it on the other, and there is a back and forth until we
stabilize.

Anyway, I'd give my right ... right ... right to arm bears for this capacit=
y!





On Tue, Apr 03, 2001 at 06:06:24PM -0400, Jan Vicherek wrote:
>=20
>   Hi all,
>=20
>  Here is the problem I have, and why do I think that the variable
> translation would be really useful:
>=20
>  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.
>=20
>  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.
>=20
>  The makefile references the same variables. They do not contain all
> relative paths, but ofter contain absolute paths (c:\prod\app\cfg\...).
>=20
>  It semms to me quite natural, that the ENVVARs (and cmd line params) get
> translated when crossing the Windows-Cygwin boundaries.
>=20
>  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.
>=20
>  I would welcome any suggestions on how to solve this !
>=20
>  Would anybody have a suggestion for better solution than translating the
> ENVVARs and cmd line args ?
>=20
>     Thanks,
>=20
>        Jan
>=20
> On Mon, 2 Apr 2001, Glen Coakley wrote:
>=20
> >=20
> > I also question the usefulness of this. There are special cases where i=
t is
> > useful, like when you are passing paths from a windows program to a Cyg=
win
> > one (I created a hack recently to allow me to right-click on a director=
y and
> > get a Cygwin Bash shell in that directory.) But for those cases, I would
> > think the 'cygpath' utility would be sufficient.
> >=20
> > ________________________________
> > Glen Coakley, Sr. Software Engineer
> > MQSoftware Inc., (763) 543-4845
> > Have you ever wonder what happens when you run "rm -rf / " but been afr=
aid
> > to try it?
> >=20
> >=20
> > > -----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
> > >=20
> > >=20
> > > 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=20
> > > from CYGWIN ?
> > > >> >
> > > >>=20
> > > >http://www.cygwin.com/cygwin-ug-net/using.html#USING-PATHNAMES says
> > > >> >that HOME, PATH, and LD_LIBRARY_PATH are converted, but=20
> > > it doesn't say
> > > >> >how to control any additional ones in runtime.
> > > >>=20
> > > >> The main reason for this is that it isn't possible.  Don't=20
> > > 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=20
> > > variables that
> > > >are to be translated in fashion similair to "PATH" variable ?
> > >=20
> > > Maybe you are misinterpreting what I said.  It isn't possible=20
> > > because it
> > > isn't implemented.  My observation of "Don't know why..." was=20
> > > basically
> > > aimed at the fact that you seemed to be under the impression that this
> > > was some kind of undocumented feature.
> > >=20
> > > >What efforts do you estimate it would take to whip up such code ?
> > > >
> > > >Do you think such feature wouldn't be very useful ?  Why ?
> > >=20
> > > I'm not sure what estimates you're looking for.  It would=20
> > > probably take
> > > me a couple of hours of programming to do this.
> > >=20
> > > Would it be useful?  Since this is the first time that I can=20
> > > 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=20
> > > you can add
> > > a CYGWIN_TRANSLATABLE variable, then just set the environment=20
> > > variables
> > > using posix paths.  I believe that Cygwin already handles the=20
> > > ones that
> > > should be handled.
> > >=20
> > > However, as usual, if someone wants to contribute a patch, I will
> > > consider it's inclusion in the sources.
> > >=20
> > > 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.
> > >=20
> > > cgf
>=20
>=20
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>=20

--=20
---------------------------------------------------------------------
If this message was not digitally signed, do you really know who it
came from?  Encrypt everything, let the NSA sort it out.

Unsolicited email advertisements will be proofread and returned for a fee of
$500 per message.  Sending such email to this address implies acceptance
of these terms.

--9amGYk9869ThD9tj
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIEuQYJKoZIhvcNAQcCoIIEqjCCBKYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AowwggKIMIIB8aADAgECAgMEF6IwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAyMDExOTI2MDVaFw0wMjAyMDExOTI2MDVa
MEkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJjAkBgkqhkiG9w0BCQEWF3Jp
Y2gtcGF1bEByaWNoLXBhdWwubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRS7H6
sh/VWqGGQ08TgL+BWIwE0gHxGupk9faIme7Yja40XoI34vjAjFmlH9uEw9Q3OMvc17EOHVBi
hr14kccoshzM7We/9WjoogaNwreFEADaT1pSnz8fucYULgUOMXs9Q9zvTBMfzeWWmwoA6IDm
PlF904rCQj33o/Kftzb6AwIDAQABozQwMjAiBgNVHREEGzAZgRdyaWNoLXBhdWxAcmljaC1w
YXVsLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAJycXbzWO6nJ/pqO/mqT
/iuV8tf7Q0xM3Kh/Vn8vxoywitl0rQl2lEvaLZ661TZLROXBhJN3rFHp+q4O0yRgqQrZ31Vl
IeSieL8hn3rwFSXzWa8OVDwcFyaIN7Zo4aSO2CIcM51oj73KYWlCVC1kwRKEx3EzfSq8TZ7z
5JQm9MutMYIB9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
MDAuOC4zMAIDBBeiMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMDEwNDAzMjI1NTI5WjAjBgkqhkiG9w0BCQQxFgQUS6sOTQ/2mcSz
B2FcYtRcvWeQj1UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC
AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB
BQAEgYARDQ4OCfrE5hVRB+IFUnFobXUocGYNP8A4mjQv8Pxr3oFIXC64bgMq94k91O8HrRK/
24zKEY7s42SNvv08L7B98aRYYl/eLyN80T+hnGrLAngPWf2ov4o+DNOH2kvq0LvfL9pyfswQ
I6bOT9A8N7Ycm5OyczH5t+3DzXG8XwNybg==

--9amGYk9869ThD9tj--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019