setup and mintty (was Re: New setup.exe release?)

Charles Wilson
Mon May 23 18:05:00 GMT 2011

On 5/23/2011 12:04 PM, Corinna Vinschen wrote:
> On May 23 11:33, Charles Wilson wrote:
>> e.g. the cygwin entry explicitly uses high codepoints for various line
>> draw stuff, (and cgywin's own terminal handling code does the magic to
>> replace them with unicode linedraw? or something?)
> Something.  I don't know how mintty works, but the Cygwin console knows
> the "switch to/from alternate charset" command "ESC [ 11 m", "ESC [ 10
> m".  The alternate charset is always codepage 437 which has the line
> drawing chars at known single-byte positions in the >= 128 region.
> This is apparently used by ncurses when running in a console window,
> but perhaps not when running in mintty.
> Whatever that is, I guess it may not be overly tricky to implement in
> mintty as well, *if* somebody takes the time to report the problem.

Sure, but to "report the problem" I first need to figure out WHERE the
problem is, so it's reported to the correct location: ncurses
(upstream)? our ncurses packages (which really means "fix it myself" as
cygwin-ncurses maint)?  mintty?  cygwin?

It just hasn't been real high on my priority list to figure that out.

>> My point: there are some things that don't yet seem to work "right" in
>> mintty, and I'm not really sure where the problem is.
> What is the difference to the Cygwin console exactly?

"real" line draw chars vs. fake ones like this:

|     \ /     |
|      |      |

> I'm sure, if you
> look a bit below the surface, you will easily find bugs in the Cygwin
> console implementation as well.  It's all about getting bug reports or
> even testcases.  Just because there are bugs in mintty and the Cygwin
> console doesn't mean both are unusable as default terminal.


>>   1) does mintty need to do magic linedraw character rewriting,
>> replacing what APPEAR to be attempts to print line draw chars with
>> unicode linedraw glyphs?  (ugh. heuristics. I hate heuristics. They
>> always guess wrong sometimes.)
> Btw., why is it so bad to have ASCII replacement chars?  They just
> work, even if they look ugly to some people.

'Cause they look ugly. :-)  And we get reports about that occasionally.
(e.g. pstree -G)

>>   2) do we need an explicit mintty terminfo entry, with a 'better' acsc
>> entry 
> I don't think so.  If at all, it's just some shortcoming in the current
> implementation, something which can be fixed or added.

I agree; was just trying to list all possibilities no matter how...unwise.

>>   3) Maybe there is some magic combination of envvar TERM/LANG,
>> settings, mintty options, font choices, etc, that will make linedraw work?
> Windows fonts are unicode anyway, and the line drawing chars are
> part of the unicode codeset.  I guess a translation table from
> CP437 to unicode line drawing chars and support of the alternate
> charset setting should do it.

*Supposedly* that's what ncursesw does (or used to do) but it doesn't
seem to be doing it any more (if it ever really did).  There's some talk
online about various vt escape codes so you know when \305 is supposed
to be the CP427 line draw char ┼, and when it's supposed to be some
other hibitset single byte glyph from some other specific locale.  More
research needed...sigh.

>>> If we switch to mintty we don't need the Cygwin.bat file anymore.  But,
>>> shouldn't we keep it anyway for people who maintain some handmade symlink
>>> to it?
>> yes.
>>> If so, should we stick to the content of Cygwin.bat as is, or should
>>> we change it to call mintty, too?
>> as-is.  What if you really WANT to use cmdbox?  How else can a
>> cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
>>  And since that's the only real way to do so, we ought to provide the file.
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
>                     Huh?
> You can simple create a Windows shortcut to bash.exe, edit it to
> add a --login option, and that's all you really need.

As cgf pointed out, .bat is necessary to set CYGWIN before launch,  It's been a while since I actually LOOOKED at the contents
of cygwin.bat.

I thought it set a lot of stuff, like SHELL and PATH and CYGWIN and TERM
and whatnot.  But...

@echo off

chdir C:\cygwin\bin

bash --login -i

Uhm, yeah, THAT can be replaced by a symlink.

>>> And who's going to create the patches?
>> Well, my proposal is a one-liner in setup.exe: just change the target of
>> the shortcut created in the Start Menu.
> I don't think it makes sense if the desktop shortcut and the menu entry
> behave differently.  The desktop shortcut is the first thing new users
> see, and this shortcut should start mintty in the first place.  Just
> as the menu entry since they should do the same.

I didn't mean to make a distinction between the two; I actually forgot
about the desktop one since I always uncheck that box on setup.exe -- so
much that its habit now and I don't even read it or think about it.

You are right, of course, both shortcuts should be the same -- so it's a
two-liner patch.  I just meant that the cygwin.bat file should exist,
but no shortcut to it should be automatically created by setup.exe.
Leave that up to the end-user to do manually.

'Course, that was when I thought cygwin.bat was a lot more is, the file merely serves as a placeholder that a tiny
minority of people can use as a customization point. If we remove it,
then it becomes a FAQ:

Q: How can I set CYGWIN to $myneeds before launching a shell?  I need to
use a cmd window because ${some reason mintty doesn't work for me}.

A: Create a .bat file with the following contents:
blah blah blah
and then create a shortcut to point to that batch file.

>>> Last but not least, shouldn't we add mintty to the Base package
>>> anyway, independently of what we do to setup?
>> I think so.
>> However, if we do change setup.exe, then mintty should later be updated
>> to eliminate its postinstall/preremove scripts.  We don't need TWO
>> shortcuts to the same proggie.
> I agree.

Well, there's that, then.


More information about the Cygwin-apps mailing list