Thread: [Mingw-users] python installation

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello,

I need a Python interpreter on the MinGW shell, how I can setup a interpreter? Should I need to install the normal Windows Python interpreter?

Thanks

Phil

On Tue, Oct 23, 2012 at 12:30 PM, Kraus Philipp wrote:
> Hello,
>
> I need a Python interpreter on the MinGW shell, how I can setup a interpreter? Should I need to install the normal Windows Python interpreter?

The "normal Windows Python interpreter" works.  You just need to make
sure to configure it properly and set the environment variables for
PYTHON_*.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Am 23.10.2012 um 19:37 schrieb Earnie Boyd:

> On Tue, Oct 23, 2012 at 12:30 PM, Kraus Philipp wrote:
>> Hello,
>> 
>> I need a Python interpreter on the MinGW shell, how I can setup a interpreter? Should I need to install the normal Windows Python interpreter?
> 
> The "normal Windows Python interpreter" works.  You just need to make
> sure to configure it properly and set the environment variables for
> PYTHON_*.

Which configuration must be set? Do you have got a how-to?

Thanks

Phil

On Tue, Oct 23, 2012 at 1:57 PM, Kraus Philipp wrote:
>
> Am 23.10.2012 um 19:37 schrieb Earnie Boyd:
>
>> On Tue, Oct 23, 2012 at 12:30 PM, Kraus Philipp wrote:
>>> Hello,
>>>
>>> I need a Python interpreter on the MinGW shell, how I can setup a interpreter? Should I need to install the normal Windows Python interpreter?
>>
>> The "normal Windows Python interpreter" works.  You just need to make
>> sure to configure it properly and set the environment variables for
>> PYTHON_*.
>
> Which configuration must be set? Do you have got a how-to?

http://bit.ly/T92tAX

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

2012/10/23 Kraus Philipp <phi...@fl...>

> I need a Python interpreter on the MinGW shell, how I can setup a
> interpreter? Should I need to install the normal Windows Python interpreter?
>
>
You mean you need Python at all? Or why MinGW shell not, say, cmd.exe or
the one bundled together?

There shouldn't be any special steps to use Python under MSYS per se, the
configuration mentioned above is regardless of using MSYS or another shell.
You should be able, however, to deal with specific issues as MSYS is not
designed itself as a general purpose command line, but as support for the
MinGW compilers. For example, I'm having a problem with the TZ environment
variable which must not be set for Python otherwise it reports local time
incorrectly. In practice, there shouldn't be any severe issues.

On 23/10/12 21:06, Renato Silva wrote:
> ... as MSYS is not designed itself as a general purpose command line,
> but as support for the MinGW compilers.

I do wish users would stop broadcasting this blatant propaganda.  MSYS 
shell is GNU bash; as such, it is every bit as suitable for any general 
purpose use on Windows, for which users may choose to adopt it, as it is 
on Linux, BSD or other Unix, or any other GNU hosting system.

-- 
Regards,
Keith.

2012/10/23 Keith Marshall <kei...@us...>

> On 23/10/12 21:06, Renato Silva wrote:
> > ... as MSYS is not designed itself as a general purpose command line,
> > but as support for the MinGW compilers.
>
> I do wish users would stop broadcasting this blatant propaganda.  MSYS
> shell is GNU bash; as such, it is every bit as suitable for any general
> purpose use on Windows, for which users may choose to adopt it, as it is
> on Linux, BSD or other Unix, or any other GNU hosting system.
>
>
I assumed that after Eli Zaretskii's [message] in the TZ thread, but good
to know! I like MSYS, and I haven't seen any good reasons to switch to
Cygwin as I have been said several times every time I face some issue.
That's because I have been getting them all fixed before ever considering
that.

[message] *"If you want MSYS and native Windows programs live in peace,
don't mix
them in the same window and environment.  The only exception to this
rule is the compiler and Binutils needed to create MinGW programs --
and that's because MSYS was specially and carefully crafted to allow
this very kind of jobs."*

>  --
> Regards,
> Keith.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe
>

Am 23.10.2012 um 22:06 schrieb Renato Silva:

> 
> You mean you need Python at all? Or why MinGW shell not, say, cmd.exe or the

I need the Python interpreter under the MinGW shell for running Scons (www.scons.org),
a Python based build system. And I have some problems with pathes & path seperators.
The shell address all pathes with /, but within the python scripts \ is used, so this is a problem,
because the path structures are not correct. 
And also I get the problem, that the the input commands on building libraries are too long if
I use absolut pathes eg: configure --prefix=/c/..../
So I can not build my libraries

Phil
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24.10.2012 0:52, Kraus Philipp wrote:
> 
> Am 23.10.2012 um 22:06 schrieb Renato Silva:
> 
>> 
>> You mean you need Python at all? Or why MinGW shell not, say, 
>> cmd.exe or the
> 
> I need the Python interpreter under the MinGW shell for running 
> Scons (www.scons.org), a Python based build system. And I have
> some problems with pathes & path seperators. The shell address all 
> pathes with /, but within the python scripts \ is used, so this is 
> a problem, because the path structures are not correct. And also I 
> get the problem, that the the input commands on building libraries 
> are too long if I use absolut pathes eg: configure 
> --prefix=/c/..../ So I can not build my libraries

Why do you need MSys then?

SCons normally works outside of MSys. You just make sure you have
%PYTHON% , %PYTHON%/Scripts and %MINGW%/bin in your PATH (here
%PYTHON% is a placeholder for Python directory, i.e. D:\\Python27, and
%MINGW% is a placeholder for MinGW directory, i.e. E:\\MinGW32), and
then you run "scons" in the directory where SConstruct is. You might
also need to either modify the SConstruct to look for mingw (like
this: env = Environment(tools = ["mingw", <put other compatible
toolchains here>]), or supply some kind of commandline argument
(depends on your SConstruct contents. I'm not sure, maybe it'll work
ok by default.

If SConstruct or SConscripts require MSYS tools or run POSIX shell
scripts, then they are badly written and should be fixed - most of the
things that sed, grep, find and other often-invoked-from-scripts utils
do can be reproduced in native (and portable!) Python; using shell
scripts when you have Python makes little sense either.

And why did you mention a configure script? SCons does not use them.

If scons is not invoked directly, but is run from within a shell
script, port that shell script to Python.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQh4LdAAoJEOs4Jb6SI2CwZkQIAM0fbxp/oEFWZ2rayW6GvmpN
uxtnJW+C2Fup6umtuu2t7hL9a/Fhmw5fhxAVt3fY49Ld3dt/sR74yz8rpntHarUZ
gkLMhKPR3dDjlv36Mc+ErbMh5dMdJbQetRIV+vNHo+7fTiaBUzPfm7yIvRqbujB5
VLnFy79bD4c/ynyrZ2B05KGgI3G/Gg3yehI+0sWAwPfn4e20gGLtgu54h6yjMWUD
W/Yuvvko1ipuWxDEkgmv+z9KnAzI6YJHNMnYPU74LNs/+lHqCqsp0U8GfmsmuvnX
Q5lOnnLR9d1H8JpRHQkNaOWlNFwSTEmvGEQf3/XSWvTxv0Z3f28zrfGUXdlRy9A=
=XkvO
-----END PGP SIGNATURE-----

2012/10/23 Kraus Philipp <phi...@fl...>

> I need the Python interpreter under the MinGW shell for running Scons (
> www.scons.org),
> a Python based build system. And I have some problems with pathes & path
> seperators.
> The shell address all pathes with /, but within the python scripts \ is
> used, so this is a problem,
> because the path structures are not correct.
> And also I get the problem, that the the input commands on building
> libraries are too long if
> I use absolut pathes eg: configure --prefix=/c/..../
> So I can not build my libraries
>
>
I'm not sure if I understand, can you provide an easy example?

Am 23.10.2012 um 23:35 schrieb Renato Silva:

> 2012/10/23 Kraus Philipp <phi...@fl...>
> I need the Python interpreter under the MinGW shell for running Scons (www.scons.org),
> a Python based build system. And I have some problems with pathes & path seperators.
> The shell address all pathes with /, but within the python scripts \ is used, so this is a problem,
> because the path structures are not correct. 
> And also I get the problem, that the the input commands on building libraries are too long if
> I use absolut pathes eg: configure --prefix=/c/..../
> So I can not build my libraries
> 
> 
> I'm not sure if I understand, can you provide an easy example? ------------------------------------------------------------------------------

The path problems seems to be solved after reinstall of MinGW but my command are too long:

cd C:\Users\Administrator\Documents\msys\library\atlas3.10.0-buildtmp; ..\configure --dylibs --with-netlib-lapack-tarfile=..\lapack-3.4.2.tgz --prefix=C:\Users\Administrator\Documents\msys\library\build_release\atlas\3.10.0; make; make install

Der Dateiname oder die Erweiterung ist zu lang.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24.10.2012 0:23, Keith Marshall wrote:
> On 23/10/12 21:06, Renato Silva wrote:
>> ... as MSYS is not designed itself as a general purpose command
>> line, but as support for the MinGW compilers.
> 
> I do wish users would stop broadcasting this blatant propaganda.
> MSYS shell is GNU bash; as such, it is every bit as suitable for
> any general purpose use on Windows, for which users may choose to
> adopt it, as it is on Linux, BSD or other Unix, or any other GNU
> hosting system.
> 
Does that mean that MSys sh.exe will never crash without explanation,
leaving a dump file, or that sh.exe or make.exe (ok, make is not part
of the shell, but it is part of MSys, so that's applicable to me
bitching about MSys) will never hang up (again, without explanation)?
Because that's not what i usually see.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQh3NbAAoJEOs4Jb6SI2Cww1QH/1FOC5pGvRdyv90XfAUGMrXT
8gfLhhDELrsujWUyfFJbGkKE89p6R2wfcT/9wegmQWfVSEkVgTtiNI81ZPPePcZX
4/oP2WW3yxydY27hOsSiimOV6F8NOssWLnMMhccmVTyqIv+ubILtfGSXGiVkzjcy
S8ZVwyfeuz3fe5pyOO/AnV1+dMCEmzC+K3+lNExSRbirX3SvqarE+i7I+Zk1dFlB
t9xhZZLuVk0O5zBXFpnd/+jiOaZiIDRv+u4dLipbP8+7Rxb4FKYUl6N17svh79qM
ehvu1117w9U6skjFii4E0kXOz3GWqWu3EFi/FI1MIlMUv+1/w9I1LAVVVe+1wc8=
=Biwm
-----END PGP SIGNATURE-----

2012/10/24 LRN <lr...@gm...>

> Does that mean that MSys sh.exe will never crash without explanation,
> leaving a dump file, or that sh.exe or make.exe (ok, make is not part
> of the shell, but it is part of MSys, so that's applicable to me
> bitching about MSys) will never hang up (again, without explanation)?
> Because that's not what i usually see.
>

Well it doesn't crash on me, not that often at least, so I wonder what
could be wrong there in your environment. In general, I like MSYS, even
though I feel like there's a place for improvements. You could try to track
down these crashes and ask for help here, maybe there's some solution. For
example, some time ago I was trying to make ls deal ok with non-ascii
characters in filenames, and people kind of looked down to me like that's
the way MSYS was designed, getting even to the point at me looking at bash
source code to try get it fixed. All that for finding out in the end, that
I just needed to do two small edits in some config file. I've been going
though a timezone problem too, but I think I have tracked down the root
cause and I hope now for a fix. In short, don't give up.

Am 23.10.2012 um 23:35 schrieb Renato Silva:

> 2012/10/23 Kraus Philipp <phi...@fl...>
> I need the Python interpreter under the MinGW shell for running Scons (www.scons.org),
> a Python based build system. And I have some problems with pathes & path seperators.
> The shell address all pathes with /, but within the python scripts \ is used, so this is a problem,
> because the path structures are not correct. 
> And also I get the problem, that the the input commands on building libraries are too long if
> I use absolut pathes eg: configure --prefix=/c/..../
> So I can not build my libraries
> 
> 

Sorry, I have got a mistake, the path problem with Python exists too:

The correct path for the msys command line sould be configure --prefix=/C/Users/Administrator/Documents/
but I get configure --prefix=C:\Users\Administrator\Documents\

but in my Python script I need a string replace

path = os.path.abspath(os.path.join(workingpath))
if env["TOOLKIT"] == "msys" :
        path = "/"+path.replace("\\", "/")
        path = path.replace(":", "")

So os.path.join with returns a windows-style path and not a unix-style path.
This is not a solution to add special for Msys a string replace for the correct path format.

Phil
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24.10.2012 14:33, Kraus Philipp wrote:
> 
> Am 23.10.2012 um 23:35 schrieb Renato Silva:
> 
>> 2012/10/23 Kraus Philipp <phi...@fl...> I need the
>> Python interpreter under the MinGW shell for running Scons
>> (www.scons.org), a Python based build system. And I have some
>> problems with pathes & path seperators. The shell address all
>> pathes with /, but within the python scripts \ is used, so this
>> is a problem, because the path structures are not correct. And
>> also I get the problem, that the the input commands on building
>> libraries are too long if I use absolut pathes eg: configure
>> --prefix=/c/..../ So I can not build my libraries
>> 
>> 
> 
> Sorry, I have got a mistake, the path problem with Python exists
> too:
> 
> The correct path for the msys command line sould be configure
> --prefix=/C/Users/Administrator/Documents/ but I get configure
> --prefix=C:\Users\Administrator\Documents\
I still don't understand why you're mixing SCons with configure scripts.

> but in my Python script I need a string replace
> 
> path = os.path.abspath(os.path.join(workingpath)) if env["TOOLKIT"]
> == "msys" : path = "/"+path.replace("\\", "/") path =
> path.replace(":", "")
You don't really need to replace ":", msys will understand
"c:/Users/Administrator/Documents" just fine.

> 
> So os.path.join with returns a windows-style path and not a
> unix-style path.
Because you're using msvc-Python. It would have been the same with
mingw-Python too. Only msys-Python would know how to handle MSYS paths
correctly. Sadly, msys-Python does not exist :)

> This is not a solution to add special for Msys a string replace for
> the correct path format.
This is basically what everyone does. I.e. there are some
MinGW-compiled software that uses Python (gobject-introspection, for
example), and it does exactly this - checks what os it's running on,
and does '\\'-replace and some other compatibility tricks.
You can also use "if os.name == 'nt':" and maybe couple it with
checking that your toolkit is "mingw" (which would mean MinGW+Msys;
though again, it's a questionable decision to mix MSys and SCons).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQh8VpAAoJEOs4Jb6SI2CwnnoH/RM/NHmZraXy5Sz//9/snMPj
hm8LPU3Jy3yn3FPhbZwLuvAvZZFOeHP6V1YVRpLp4FBqU5XlJ3XPfJ1T3Zn7oXgD
IVHXbFi6XEU64HzIBgjxl/QmgeYuuAumctUWYUx0JvJbeRJ4szTY1ptD9vrLW8i9
Nho3Y9QLgOFWTV6mquNsyVl834TnUcjgEQddee1dw02okKIacqmkNlW/EjRxq0Cg
OeIiN9k6rj+jbZ7vfotiIipV2hO+2K8vAumNjrsNQLwA4ZHxyXU/1ngTJK3KcGfK
ZH0nPV6nhNVLIo2DofU5VcfChWQ31M/W8TGzP/6l3rNXf9p5ODPJyXFLzr/EFa0=
=HOql
-----END PGP SIGNATURE-----

On Wed, Oct 24, 2012 at 6:39 AM, LRN wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 24.10.2012 14:33, Kraus Philipp wrote:
>> but in my Python script I need a string replace
>>
>> path = os.path.abspath(os.path.join(workingpath)) if env["TOOLKIT"]
>> == "msys" : path = "/"+path.replace("\\", "/") path =
>> path.replace(":", "")
> You don't really need to replace ":", msys will understand
> "c:/Users/Administrator/Documents" just fine.

And Python understands this format as well.

>
>>
>> So os.path.join with returns a windows-style path and not a
>> unix-style path.
> Because you're using msvc-Python. It would have been the same with
> mingw-Python too. Only msys-Python would know how to handle MSYS paths
> correctly. Sadly, msys-Python does not exist :)
>

Correct, it is the reason we have an MSYS perl.  But when I developed
MSYS Python wasn't as common and so wasn't considered to be important
for MSYS.  It would be nice if MSYS could apply some magic and
reformat the strings in files but that would lead to more headache
than it is worth.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Msys python does exist but its not widely known as its normally part of 
a specialized package im maintaining.

http://sourceforge.net/projects/cbadvanced/files/Msys%20Specific/msys-python-2.5.5.tar.gz/download

You can also find other packages ported to Msys that are not part of the 
official Msys.

Revelator

> From: Renato Silva <br....@gm...>
> Date: Tue, 23 Oct 2012 19:29:11 -0200
> 
> 2012/10/23 Keith Marshall <kei...@us...>
> 
> > On 23/10/12 21:06, Renato Silva wrote:
> > > ... as MSYS is not designed itself as a general purpose command line,
> > > but as support for the MinGW compilers.
> >
> > I do wish users would stop broadcasting this blatant propaganda.  MSYS
> > shell is GNU bash; as such, it is every bit as suitable for any general
> > purpose use on Windows, for which users may choose to adopt it, as it is
> > on Linux, BSD or other Unix, or any other GNU hosting system.
> >
> >
> I assumed that after Eli Zaretskii's [message] in the TZ thread

I stand by what I said, but your interpretation of what I said is too
far-fetched:

> [message] *"If you want MSYS and native Windows programs live in
> peace, don't mix them in the same window and environment.  The only
> exception to this rule is the compiler and Binutils needed to create
> MinGW programs -- and that's because MSYS was specially and
> carefully crafted to allow this very kind of jobs."*

This talks about mixing MSYS and native Windows programs.  When the
MSYS shell is used either in isolation or to invoke MSYS programs, I
don't expect any special problems (although I myself don't use MSYS
that way).

I don't see how your comment is not a disagreement with Keith's, since we
were talking about using a native Windows program, Python, from within MSYS
shell.

You sounded like a MSYS developer knowing what you were saying, but so it
did Keith. What should I believe? After all, is MSYS designed as a
minimalist general-purpose system, not free of issues with native
(non-MSYS) programs, or was it "specially and carefully crafted" to write
MinGW programs?

2012/10/24 Eli Zaretskii <el...@gn...>

> > From: Renato Silva <br....@gm...>
> > Date: Tue, 23 Oct 2012 19:29:11 -0200
> >
> > 2012/10/23 Keith Marshall <kei...@us...>
> >
> > > On 23/10/12 21:06, Renato Silva wrote:
> > > > ... as MSYS is not designed itself as a general purpose command line,
> > > > but as support for the MinGW compilers.
> > >
> > > I do wish users would stop broadcasting this blatant propaganda.  MSYS
> > > shell is GNU bash; as such, it is every bit as suitable for any general
> > > purpose use on Windows, for which users may choose to adopt it, as it
> is
> > > on Linux, BSD or other Unix, or any other GNU hosting system.
> > >
> > >
> > I assumed that after Eli Zaretskii's [message] in the TZ thread
>
> I stand by what I said, but your interpretation of what I said is too
> far-fetched:
>
> > [message] *"If you want MSYS and native Windows programs live in
> > peace, don't mix them in the same window and environment.  The only
> > exception to this rule is the compiler and Binutils needed to create
> > MinGW programs -- and that's because MSYS was specially and
> > carefully crafted to allow this very kind of jobs."*
>
> This talks about mixing MSYS and native Windows programs.  When the
> MSYS shell is used either in isolation or to invoke MSYS programs, I
> don't expect any special problems (although I myself don't use MSYS
> that way).
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe
>

> Date: Wed, 24 Oct 2012 08:49:32 +0400
> From: LRN <lr...@gm...>
> 
> On 24.10.2012 0:23, Keith Marshall wrote:
> > On 23/10/12 21:06, Renato Silva wrote:
> >> ... as MSYS is not designed itself as a general purpose command
> >> line, but as support for the MinGW compilers.
> > 
> > I do wish users would stop broadcasting this blatant propaganda.
> > MSYS shell is GNU bash; as such, it is every bit as suitable for
> > any general purpose use on Windows, for which users may choose to
> > adopt it, as it is on Linux, BSD or other Unix, or any other GNU
> > hosting system.
> > 
> Does that mean that MSys sh.exe will never crash without explanation,
> leaving a dump file, or that sh.exe or make.exe (ok, make is not part
> of the shell, but it is part of MSys, so that's applicable to me
> bitching about MSys) will never hang up (again, without explanation)?

That's unfair: programs that crash are not limited to MSYS in any way.

FWIW, the MSYS shell never crashed on me.

> From: Renato Silva <br....@gm...>
> Date: Wed, 24 Oct 2012 18:05:57 -0200
> 
> I don't see how your comment is not a disagreement with Keith's, since we
> were talking about using a native Windows program, Python, from within MSYS
> shell.

Maybe I misread what was written about this, but I don't think anyone
suggested that running a native Windows Python from the MSYS shell
will be difficult.  I think Earnie said that a similar situation with
Perl was handled by providing an MSYS Perl, and that there's no MSYS
Python on the MinGW site only because it was thought to be a much
rarer issue at the time.

I agree with every word of that.

I cannot speak for Keith, but I'm sure that if he wishes to speak up
on this matter, he will.

> You sounded like a MSYS developer knowing what you were saying, but so it
> did Keith.

I'm not an MSYS developer, I just use it a lot for building MinGW
ports.  So my opinions on this, while they are backed up by my
experience, weigh much less that Keith's.

On 24/10/12 22:44, Eli Zaretskii wrote:
>> From: Renato Silva <br....@gm...>
>> Date: Wed, 24 Oct 2012 18:05:57 -0200
>>
>> I don't see how your comment is not a disagreement with Keith's, since we
>> were talking about using a native Windows program, Python, from within MSYS
>> shell.
>
> Maybe I misread what was written about this, but I don't think anyone
> suggested that running a native Windows Python from the MSYS shell
> will be difficult.  I think Earnie said that a similar situation with
> Perl was handled by providing an MSYS Perl, and that there's no MSYS
> Python on the MinGW site only because it was thought to be a much
> rarer issue at the time.
>
> I agree with every word of that.
>
> I cannot speak for Keith, but I'm sure that if he wishes to speak up
> on this matter, he will.
>
>> You sounded like a MSYS developer knowing what you were saying, but so it
>> did Keith.
>
> I'm not an MSYS developer, I just use it a lot for building MinGW
> ports.  So my opinions on this, while they are backed up by my
> experience, weigh much less that Keith's.

Well, I am a MinGW project administrator, so I hope I can speak with 
some authority.  However, I will make it clear, from the outset, that my 
development efforts are focussed primarily on the MinGW, (i.e. the 
native Windows code), aspects of the project offerings; contributions I 
have made to MSYS development have been minor, and mostly peripheral.

That said, I have been a user of MSYS for about seven or eight years, 
yet *not* as a hosting environment for my MinGW code development; (I use 
Linux hosted GNU tools, complemented by a MinGW cross-compiler for that 
purpose).  On the contrary, I use MSYS to host the documentation 
production system I use in my workplace, to produce technical papers and 
operating manuals in hyperlinked PDF format, for use in the oil refinery 
where I work as a chemical/control engineer.

At the heart of this document production system is GNU troff (groff), 
built as a native MinGW application, coupled with my own pdfmark macro 
set, (a component I myself have contributed to the GNU troff project, 
and which is not well supported by Chuck's MSYS port of groff), driven 
by pdfroff, (a substantial Bourne shell script which I contributed to 
groff, to complement the pdfmark macros).  In conjunction with these, I 
originally used the MSYS implementation of CVS to maintain an audit 
trail of documentation updates; for this I now use the standard Windows 
build of Mercurial, (which is a Python dependant).  All of this works 
flawlessly under MSYS, but in no way could any of it be described as 
MinGW application development.

Coming back to LRN's glib reference to mysterious unexplained crashes
and hangs, I can only say that in all the years I have been using MSYS,
the shell has *never* crashed, and I have observed only one hang, (in
circumstances which were consistently reproducible), and that occurred
only when running in the RXVT terminal, (which used to be the default
for running the MSYS shell, but is now strongly discouraged); this
problem was never apparent when running in the standard Windows console,
(often confused with cmd.exe, but actually the container in which
cmd.exe commonly runs, and equally capable as a container for other
shells, such as MSYS bash), nor when running in Console2.

This is not to say that the MSYS shell is entirely without its problems;
there are some known issues, (such as overly-aggressive heuristic path
format conversion, when it isn't wanted, or some difficulties in passing
globbing tokens amongst command arguments), and probably other as-yet
unidentified issues.  If your application falls foul of any of these
issues, then maybe MSYS shell isn't for you, but there are many, many
applications for which it is admirably suited, and they go far beyond
MinGW application development; to claim that you shouldn't use MSYS for 
such applications, simply because they don't represent MinGW application
development, is just patently ridiculous.

-- 
Regards,
Keith.

2012/10/25 Keith Marshall <kei...@us...>

>  Well, I am a MinGW project administrator, so I hope I can speak with
> some authority.  However, I will make it clear, from the outset, that my
> development efforts are focussed primarily on the MinGW, (i.e. the
> native Windows code), aspects of the project offerings; contributions I
> have made to MSYS development have been minor, and mostly peripheral.
>
> That said, I have been a user of MSYS for about seven or eight years,
> yet *not* as a hosting environment for my MinGW code development; (I use
> Linux hosted GNU tools, complemented by a MinGW cross-compiler for that
> purpose).  On the contrary, I use MSYS to host the documentation
> production system I use in my workplace, to produce technical papers and
> operating manuals in hyperlinked PDF format, for use in the oil refinery
> where I work as a chemical/control engineer.
>
> At the heart of this document production system is GNU troff (groff),
> built as a native MinGW application, coupled with my own pdfmark macro
> set, (a component I myself have contributed to the GNU troff project,
> and which is not well supported by Chuck's MSYS port of groff), driven
> by pdfroff, (a substantial Bourne shell script which I contributed to
> groff, to complement the pdfmark macros).  In conjunction with these, I
> originally used the MSYS implementation of CVS to maintain an audit
> trail of documentation updates; for this I now use the standard Windows
> build of Mercurial, (which is a Python dependant).  All of this works
> flawlessly under MSYS, but in no way could any of it be described as
> MinGW application development.
>
> Coming back to LRN's glib reference to mysterious unexplained crashes
> and hangs, I can only say that in all the years I have been using MSYS,
> the shell has *never* crashed, and I have observed only one hang, (in
> circumstances which were consistently reproducible), and that occurred
> only when running in the RXVT terminal, (which used to be the default
> for running the MSYS shell, but is now strongly discouraged); this
> problem was never apparent when running in the standard Windows console,
> (often confused with cmd.exe, but actually the container in which
> cmd.exe commonly runs, and equally capable as a container for other
> shells, such as MSYS bash), nor when running in Console2.
>
> This is not to say that the MSYS shell is entirely without its problems;
> there are some known issues, (such as overly-aggressive heuristic path
> format conversion, when it isn't wanted, or some difficulties in passing
> globbing tokens amongst command arguments), and probably other as-yet
> unidentified issues.  If your application falls foul of any of these
> issues, then maybe MSYS shell isn't for you, but there are many, many
> applications for which it is admirably suited, and they go far beyond
> MinGW application development; to claim that you shouldn't use MSYS for
> such applications, simply because they don't represent MinGW application
> development, is just patently ridiculous.
>
>
Thanks for your clarifications, Keith. I use bash with mintty as
general-purpose command line and replacement for cmd.exe, and I haven't
found crashes or severe issues. There are problems as you said, for example
path expansion in Windows-like parameters (e.g. attrib /?), but nothing
that I could not circumvent somehow.

On Thu, Oct 25, 2012 at 5:36 PM, Renato Silva wrote:
> Thanks for your clarifications, Keith. I use bash with mintty as
> general-purpose command line and replacement for cmd.exe, and I haven't
> found crashes or severe issues. There are problems as you said, for example
> path expansion in Windows-like parameters (e.g. attrib /?), but nothing that
> I could not circumvent somehow.

Using mintty will give you grief with MSYS to NATIVE I/O.  If you
communicate with a lot of NATIVE programs then you should use the
native CONSOLE window.  If you want to research search for PTY and
Cygwin or MSYS.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Thread: [Mingw-users] python installation

A native Windows port of the GNU Compiler Collection (GCC)

mingw-users