On 24/10/12 22:44, Eli Zaretskii wrote:
>> From: Renato Silva <br.renatosilva@...>
>> 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
> 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.