On Saturday 08 December 2007 14:11, Johannes Schindelin wrote:
> > If you think that running MSYS in a native Woe32 console means
> > running cmd.exe or command.com, then perhaps you should question
> > your own understanding of the issues, before branding others as
> > incompetent.
> The native console on Windows XP is cmd.exe.
No, it *isn't*! This discussion has come up before, not so many weeks=20
ago. cmd.exe is a *shell*; the console is a container, in which to run=20
a shell; it provides the infrastructure to manage the interface between=20
the user and the shell. cmd.exe is by no means the only shell which=20
can be run in a native Woe32 console; sh.exe, from MSYS, is just as=20
much at home there.
> > > Think resizing the window (not that hard, everybody else seems to
> > > do it just fine).
> > Yes, this is about the *only* real limitation of the native
> > console. Console2 is able to do this, while still maintaining
> > proper interaction with the stdio streams; that's why I suggested
> > that their *technique* may be worth exploring.
> I tried Console2 twice. =A0The first time I did, it had massive
> problems rendering the text properly. =A0But my second try did not
> confirm that, and I did not have time to reproduce the exact setup of
> the first try to find out what was changed.
> > > Think copy/pasting (you have to enable it manually!
> > One time *only*, then you can forget about it.
> One time per box/reinstall.
Sure. I only use one Woe32 box at a time; (couldn't tolerate more), and=20
I've never done a reinstall, (and if I did, it wouldn't be Woe??).
> Oh, and per user who downloads MSys.
And each user will have their own preferences anyway. I don't consider=20
five minutes in the 2-year life cycle of my Woe32 boxes to be too high=20
a price to pay, to configure the console to my liking.
>=A0And on some setups (don't pretend you have not see them) per reboot,
> because the admins reset the registry on boot.
I've *never* seen any such thing, and our admins impose some asininely=20
draconian restrictions on their users.
> > > you have to _right_ click to finish the selection!
> > So what? =A0Sure, it's a little bit different, but you can quickly
> > get used to it. =A0I don't see this as a particular problem.
> So we disagree.
And must, apparently, agree to do so.
> > > You can forget about multi-line selections if the first line of
> > > what you want to select does not start in the first column).
> > Yes. =A0This can be a bit fiddly, but achievable nonetheless.
> And you can move to a new house by bike. =A0It is just very
Hardly a particularly useful analogy, I think.
> > > Think scrolling back with a keyboard shortcut.
> > This is a limitation; I've learned to live with it. =A0Console2 can
> > do it, just like in the KDE konsole on my Linux box, so no reason
> > an MSYS work alike couldn't be developed.
> I can live with it, too. =A0However, I like to live a _happy_ life.
> > If you are suggesting Earnie is incompetent, [...]
> I came nowhere near that. =A0Neither will I, ever.
> > We live on their OS platform [Windows], so we just have to do the
> > best we can with what they provide.
> No, I live on planet earth.
As do I. I meant that we, as a project providing MSYS, live on Woe32;=20
if we weren't saddled with Woe32, we would have no need for MSYS.
> When I have to work on Windows, I try to=20
> solve the issues beforehand, rather than live with limitations.
I don't have the energy for writing lots of Woe32 specific code. I need=20
gvim, and a shell to run pdfroff; MSYS sh.exe in the native console is=20
fine for my needs, and its limitations don't bother me at all.
> That is the reason we rewrote spawnvpe() in msysGit, since the native
> version of that function is too limiting.
The entire family of spawn and exec functions is utterly broken; that's=20
why we (MinGW) provide the execwrap library, which I originally wrote=20
as part of the Woe32 port of groff, (GNU troff), for the FSF.
> Actually, we have quite a=20
> lot of examples where we do not just take what they provide, since it
> is not good enough.
Sure. We also have added quite a bit of extra functionality ourselves. =20
However, most of us can live with the console limitations; it isn't a=20
burning priority for us to provide a replacement, but if anyone wants=20
to develop and contribute one, we'll be happy to consider it.