Detecting msys env and translating paths

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Detecting msys env and translating paths

dhoyt
I have what may be a rather unique environment -- I'm using python and jhbuild from an msys prompt. Python, as a standard Windows executable, expects standard Windows paths (C:\blah). I'm extending jhbuild (which is python based) to try and understand msys paths since it automatically launches configure and make scripts. I was wondering what a good way to test for msys' existence is so I can do a basic path translation. e.g. jhbuild has a "sanitycheck" operation which launches "aclocal-1.8 --print-ac-dir" which prints an msys path (/mingw/share/aclocal), which is to be expected. jhbuild sees that and tries, of course, to determine if the directory does indeed exist and that certain m4 scripts are present. It fails this check, so I'm augmenting it by first checking to see if we're in an msys environment. To do that, I look for the existence of "msysinfo" in the PATH. If it's there, I assume we're in an msys env. My main question is if there's a better way of doing that (I realize there's all sorts of potential pitfalls with the approach I took -- it's simply "good enough" for now).

After I've determined that we're running in an msys env., I do a path translation via launching a process from the python script to get the actual path (sh "cd /mingw/share/aclocal && pwd -W"). My next question is if that's a decent enough way to get the normal Windows path from an msys path or if there's a better/easier way to do it.

Really the fact that I'm using python is irrelevant -- it comes down to:

How do I easily determine from an arbitrary executable that it's being executed in an msys env.? (e.g. check an env. var.? look for standard msys executables in the PATH?)

How do I translate an msys-style path into a standard Windows path from an executable that is not linked to the msys dll? (e.g. launch a program that does link to the msys dll and can do the translation?)

Thanks so much for any advice/suggestions/wisdom that you can impart.

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Detecting msys env and translating paths

lrn-2
On 08.03.2011 3:02, Hoyt, David wrote:
> How do I easily determine from an arbitrary executable that it's being executed in an msys env.? (e.g. check an env. var.? look for standard msys executables in the PATH?)
MSYSTEM variable might be a good clue. From its value you can even
detect whether you're running under Msys in Msys mode or in Mingw mode
(mostly irrelevant; most people run in Mingw mode, and that is the default).
> How do I translate an msys-style path into a standard Windows path from an executable that is not linked to the msys dll? (e.g. launch a program that does link to the msys dll and can do the translation?)
>
> Thanks so much for any advice/suggestions/wisdom that you can impart.
>
You might try to anchor on WD env variable, which is a leftover from
msys.bat that is used to run Msys. Looking for msys-1.0.dll in PATH is
also a good idea (better than looking for msysinfo; msys-1.0.dll will
ALWAYS be in /bin).
Once you know THAT, you can do the path mangling yourself (it's not
difficult in Python).
You can even read /src/fstab use the information from it to properly
access paths that are "mounted" into msys root.
/usr maps to /
/.. maps to /
/X/ and /X map to X:/ (where X is from [a-zA-Z])



------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Detecting msys env and translating paths

John Brown

On Tue, 8 Mar 2011 03:32:26 +0300, LRN wrote:

>
> On 08.03.2011 3:02, Hoyt, David wrote:
> > How do I easily determine from an arbitrary executable that it's being
> > executed in an msys env.? (e.g. check an env. var.? look for standard
> > msys executables in the PATH?)
>
>
> MSYSTEM variable might be a good clue. From its value you can even
> detect whether you're running under Msys in Msys mode or in Mingw mode
> (mostly irrelevant; most people run in Mingw mode, and that is the
> default).

Just for my information, what are "Msys mode" and "Mingw mode"?

Regards,
Alias John Brown.
     
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Detecting msys env and translating paths

lrn-2
On 08.03.2011 9:39, John Brown wrote:

> On Tue, 8 Mar 2011 03:32:26 +0300, LRN wrote:
>> On 08.03.2011 3:02, Hoyt, David wrote:
>>> How do I easily determine from an arbitrary executable that it's being
>>> executed in an msys env.? (e.g. check an env. var.? look for standard
>>> msys executables in the PATH?)
>>
>> MSYSTEM variable might be a good clue. From its value you can even
>> detect whether you're running under Msys in Msys mode or in Mingw mode
>> (mostly irrelevant; most people run in Mingw mode, and that is the
>> default).
> Just for my information, what are "Msys mode" and "Mingw mode"?
>
> Regards,
> Alias John Brown.
>
I know of two things that are different between these modes:
1) The value of MSYSTEM variable
2) The order of directories in PATH. In Msys mode you have /bin before
/mingw/bin. In Mingw mode you have /mingw/bin before /bin. Because of
that, if you have msys-gcc installed (it is in /bin) to compile
msys-dependent programs, you need to run in Msys mode to make use of it
(in Mingw mode configure script will pick up your gcc in /mingw/bin).

Some other things might be different as well.

To run in Msys mode you have to set MSYSTEM=MSYS, or run `msys.bat
MSYS'. Normal people don't build msys-dependent programs, so by default
you'd get MSYSTEM=MINGW


------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe