Re: [Mingw-users] python installation

[Renato S. <br....@gm...>]

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.