RE: setup and mintty (was Re: New setup.exe release?)
Christopher Faylor sent the following at Monday, May 23, 2011 1:26 PM >Maybe we should be looking into introducing a way to set the CYGWIN >environment variable in the global environment and adding c:\cygwin\bin >(or whatever) to the global PATH as well. http://cygwin.com/ml/cygwin/2010-01/msg00977.html Still "Just a suggestion, not a request." - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: setup and mintty (was Re: New setup.exe release?)
On 5/23/2011 3:42 PM, Andy Koppe wrote: > On 23 May 2011 17:04, Corinna Vinschen wrote: >> On May 23 11:33, Charles Wilson wrote: >>> In the former, I see pseudo-line drawing characters (e.g hyphens and >>> plus signs, etc), but in the latter I see real line draw characters. >> >> 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. > > Mintty does support that already. The feature was introduced by a > certain three-letter PC Unix company, and the Linux console supports > it too. > > The DEC vtXXX series did not have that, however, which is why xterm > doesn't either. Instead, they have the "DEC Special Character and Line > Drawing Set". When activated, character codes 0x60 to 0x7E map to > those special characters, as shown here: > http://vt100.net/docs/vt102-ug/table5-13.html. Mintty supports that > one too. Yes, I had thought that you'd put some work in that, which is (one reason) I was confused. >>> 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. > > Chuck, what font are you using in mintty? It could just be that it > doesn't have glyphs for the relevant codepoints, in which case mintty > falls back to ASCII replacements. The default Lucida Console does have > the linedrawing glyphs needed for the vt100 set. Never mind. http://www.hulu.com/watch/2364/saturday-night-live-weekend-update-emily-litella-on-violins-on-tv Yep, works fine with Lucida Console. I was using Consolas, which IMO looks better...but yep, it appears to be missing the glyphs -- although rumor has it that MS added the glyphs in their W7 version of this font. Since I'm running Vista and XP, well... I probably knew that at one point. Maybe. > If it's not that, then the xterm terminfo entry would indeed need a closer > look. > > You can test support for the CP437 alternate charset, the vt100 > graphics, and also direct Unicode line drawing by catting the attached > file created by Thomas Wolff. Neat. Do we have a list of "good" fonts for mintty, or is it basically just Lucida Console + Courier New? Maybe when I get home I'll test out a few... Consolas Andale Mono Courier New Lucida Console Vera Sans Mono (or DejaVu LGC Sans) Droid Sans Mono Inconsolata ... -- Chuck
Re: setup and mintty (was Re: New setup.exe release?)
On Mon, May 23, 2011 at 09:14:15PM +0100, Andy Koppe wrote: >What it should be called: >a) "mintty": Few are going to know what that is. >b) "Cygwin Bash Shell": That's the current name of course. Not >compatible with option 1 above. >c) "Cygwin Shell": Shell-neutral, but encourages the confusion between >terminal and shell. >d) "Cygwin Terminal": Linux desktops usually have "Terminal" entries >in their menus. >e) something else? > >I also think the console's start menu entry in the Cygwin folder >should be kept, perhaps with a new name. "Console" vs "Terminal"? I think "Cygwin Terminal" makes sense. As you say, Linux has something similar. Linux doesn't call it "Linux Terminal" because it doesn't have to, of course. cgf
Re: setup and mintty (was Re: New setup.exe release?)
On 23 May 2011 12:50, Corinna Vinschen wrote: > On May 20 17:09, Yaakov (Cygwin/X) wrote: >> The setup.exe download is still 2.738. Could it be updated to 2.749 >> to include jturney's recent bug fixes? > > I'd like to fix the mintty issue first. > > So, do we swtch to mintty as default terminal, yes or no? > > 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, I think so. > If so, should we stick to the content of Cygwin.bat as is, or should > we change it to call mintty, too? Better not, so as not to change people's existing setup. And because it would flash up a console for the .bat. > And who's going to create the patches? I suppose that should be me, but my spare time is rather limited at the moment and I still owe a patch or two for other things. > Last but not least, shouldn't we add mintty to the Base package > anyway, independently of what we do to setup? Seems sensible. Further all this, if the change to mintty as the default is going ahead, there's the question of what the desktop shortcut should do and what it should be called. What it should do: 1) Invoke the user's default shell as set in /etc/passwd as a login shell. (This is what the mintty start menu shortcut currently does) 2) Invoke bash as a login shell. What it should be called: a) "mintty": Few are going to know what that is. b) "Cygwin Bash Shell": That's the current name of course. Not compatible with option 1 above. c) "Cygwin Shell": Shell-neutral, but encourages the confusion between terminal and shell. d) "Cygwin Terminal": Linux desktops usually have "Terminal" entries in their menus. e) something else? I also think the console's start menu entry in the Cygwin folder should be kept, perhaps with a new name. "Console" vs "Terminal"? Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 23 May 2011 17:04, Corinna Vinschen wrote:
> On May 23 11:33, Charles Wilson wrote:
>> Uhm, maybe? :-)
>>
>> Here's the deal: run the following program from the ncurses-demo package:
>> /usr/lib/ncurses/test/lrtest.exe
>> in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG
>> settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW,
>> TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox.
>>
>> In the former, I see pseudo-line drawing characters (e.g hyphens and
>> plus signs, etc), but in the latter I see real line draw characters.
>>
>> Why?
>>
>> I suspect the reason is the terminfo settings for mintty (e.g. for
>> xterm-256color) specifies
>> acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
>> (inherited via terminfo 'use' statements from xterm-basic), while the
>> terminfo settings for cygwin specify
>>
>> acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
>>
>> 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.
Mintty does support that already. The feature was introduced by a
certain three-letter PC Unix company, and the Linux console supports
it too.
The DEC vtXXX series did not have that, however, which is why xterm
doesn't either. Instead, they have the "DEC Special Character and Line
Drawing Set". When activated, character codes 0x60 to 0x7E map to
those special characters, as shown here:
http://vt100.net/docs/vt102-ug/table5-13.html. Mintty supports that
one too.
>> 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.
Chuck, what font are you using in mintty? It could just be that it
doesn't have glyphs for the relevant codepoints, in which case mintty
falls back to ASCII replacements. The default Lucida Console does have
the linedrawing glyphs needed for the vt100 set.
If it's not that, then the xterm terminfo entry would indeed need a closer look.
You can test support for the CP437 alternate charset, the vt100
graphics, and also direct Unicode line drawing by catting the attached
file created by Thomas Wolff.
Andy
xgraphics
Description: Binary data
Re: setup and mintty (was Re: New setup.exe release?)
On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote:
>On May 23 13:25, Christopher Faylor wrote:
>> On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
>> >On May 23 11:33, Charles Wilson wrote:
>> >> 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.
>>
>> I agree, except for people who "need" to set the CYGWIN environment
>> variable for some reason. You have to do that before running bash.
>>
>> Maybe we should be looking into introducing a way to set the CYGWIN
>> environment variable in the global environment and adding c:\cygwin\bin
>> (or whatever) to the global PATH as well.
>
>I would really like to avoid that. The question is, which CYGWIN
>settings are really needed before an application starts? Apart from the
>"debugging the Cygwin DLL" scenario, the only one I can think of is the
>"tty" setting, and that's about to go away.
>
>IMHO it would be quite helpful if a setenv ("CYGWIN", ...) or putenv
>("CYGWIN=...") would change the CYGWIN settings for the calling process
>as well.
Well, unless you make that change, all of the other Cygwin environment
variables (not just "tty") need to be set before the first Cygwin
process in a tree is started. Parsing the CYGWIN environment variable
on the fly is trivial but I don't know for sure if there are some
settings which only work right when set during program initialization.
cgf
Re: setup and mintty (was Re: New setup.exe release?)
On Mon, May 23, 2011 at 02:16:42PM -0400, Charles Wilson wrote: >On 5/23/2011 1:25 PM, Christopher Faylor wrote: >> Maybe we should be looking into introducing a way to set the CYGWIN >> environment variable in the global environment and adding c:\cygwin\bin >> (or whatever) to the global PATH as well. > >I disagree. I deliberately keep cygwin paths out of my global PATH, so >that I can switch between various separate cygwin installs, and various >MinGW/MSYS installs, without them all conflicting with each other. > >If we DO change setup to muck with global %PATH%, then we need another >checkbox to opt out. That's what I mean by "a way". I know that people will complain if you can't opt out but I think most people would like to be able to type "bash" in their "Search programs and files" box and have bash start automatically. This would also help squash the myth that you have to start some sort of magical Cygwin environment to use a Cygwin program like "grep". >(BTW, whatever happened to that 'check box persistence' patch?) I think I volunteered to make the final check boxes persistent but it is of such little importance to me that it will probably never get done. I don't think there has been another patch presented otherwise. >> And, I can just imagine the blog entries now: "Cygwin finally offers an >> intelligent terminal interface - after ten years!" > >Yep, that + unicode support is the most obvious user-visible improvement >in the 'new user experience' in a long time. Maybe even since the >hallowed B19 -> B20.1 transition . > >Most of the other great improvements aren't immediately obvious to the >new user... The one thing that isn't clear is how this will affect the putty* users whose blog entries claim this as the only solution to the problem of "the cygwin terminal". Will this impact them? I sure hope so. >> The only downside that I see is that Andy may ask to renegotiate his >> contract. I wouldn't be surprised if he asked to be paid double what >> he's getting now, in fact. > >Andy needs a tipjar -- and a plug on this page: >http://cygwin.com/donations.html I'd be thrilled to add Andy to that page if he wants. The same goes for any maintainer. cgf
Re: setup and mintty (was Re: New setup.exe release?)
On Mon, May 23, 2011 at 8:21 PM, Corinna Vinschen wrote:
> On May 23 13:25, Christopher Faylor wrote:
>> On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
>> >On May 23 11:33, Charles Wilson wrote:
>> >> 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.
>>
>> I agree, except for people who "need" to set the CYGWIN environment
>> variable for some reason. You have to do that before running bash.
>>
>> Maybe we should be looking into introducing a way to set the CYGWIN
>> environment variable in the global environment and adding c:\cygwin\bin
>> (or whatever) to the global PATH as well.
>
> I would really like to avoid that.
same. Different PATHS make me sane and I run cygwin from an external drive
not always connected.
> The question is, which CYGWIN
> settings are really needed before an application starts? Apart from the
> "debugging the Cygwin DLL" scenario, the only one I can think of is the
> "tty" setting, and that's about to go away.
>
> IMHO it would be quite helpful if a setenv ("CYGWIN", ...) or putenv
> ("CYGWIN=...") would change the CYGWIN settings for the calling process
> as well.
>
> Apart from that, maybe mintty could provide a CYGWIN environment
> variable settings edit text in the properties dialog.
>
>> The only downside that I see is that Andy may ask to renegotiate his
>> contract. I wouldn't be surprised if he asked to be paid double what
>> he's getting now, in fact.
>
> Uh oh.
>
>
> Corinna
mintty as standard console will simplify a lot our life in supporting users,
so this proposal takes also my vote
Regards
Marco
Re: setup and mintty (was Re: New setup.exe release?)
On May 23 13:25, Christopher Faylor wrote:
> On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
> >On May 23 11:33, Charles Wilson wrote:
> >> 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.
>
> I agree, except for people who "need" to set the CYGWIN environment
> variable for some reason. You have to do that before running bash.
>
> Maybe we should be looking into introducing a way to set the CYGWIN
> environment variable in the global environment and adding c:\cygwin\bin
> (or whatever) to the global PATH as well.
I would really like to avoid that. The question is, which CYGWIN
settings are really needed before an application starts? Apart from the
"debugging the Cygwin DLL" scenario, the only one I can think of is the
"tty" setting, and that's about to go away.
IMHO it would be quite helpful if a setenv ("CYGWIN", ...) or putenv
("CYGWIN=...") would change the CYGWIN settings for the calling process
as well.
Apart from that, maybe mintty could provide a CYGWIN environment
variable settings edit text in the properties dialog.
> The only downside that I see is that Andy may ask to renegotiate his
> contract. I wouldn't be surprised if he asked to be paid double what
> he's getting now, in fact.
Uh oh.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: setup and mintty (was Re: New setup.exe release?)
On 5/23/2011 1:25 PM, Christopher Faylor wrote: > Maybe we should be looking into introducing a way to set the CYGWIN > environment variable in the global environment and adding c:\cygwin\bin > (or whatever) to the global PATH as well. I disagree. I deliberately keep cygwin paths out of my global PATH, so that I can switch between various separate cygwin installs, and various MinGW/MSYS installs, without them all conflicting with each other. If we DO change setup to muck with global %PATH%, then we need another checkbox to opt out. (BTW, whatever happened to that 'check box persistence' patch?) > But, I am extemely in favor of making mintty the default terminal. It > would present a much nicer end-user experience out-of-the-box even if > some pty stuff doesn't work quite right. Oh, sure, I'm not against that. I specifically said #5 was fine with me: 5) or punt. Who needs linedraw anyway. which was my way of saying: sure, go ahead and make mintty the default. If we really care about linedraw, we can fix it later -- and I wonder if we really DO care about it. It sounds like the consensus here is: we don't care /much/, but PTC... And that's fine. > And, I can just imagine the blog entries now: "Cygwin finally offers an > intelligent terminal interface - after ten years!" Yep, that + unicode support is the most obvious user-visible improvement in the 'new user experience' in a long time. Maybe even since the hallowed B19 -> B20.1 transition . Most of the other great improvements aren't immediately obvious to the new user... > The only downside that I see is that Andy may ask to renegotiate his > contract. I wouldn't be surprised if he asked to be paid double what > he's getting now, in fact. Andy needs a tipjar -- and a plug on this page: http://cygwin.com/donations.html -- Chuck
Re: setup and mintty (was Re: New setup.exe release?)
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. Agree. >> 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, but...wow. 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 C: 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
Re: setup and mintty (was Re: New setup.exe release?)
On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote: >On May 23 11:33, Charles Wilson wrote: >> 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. I agree, except for people who "need" to set the CYGWIN environment variable for some reason. You have to do that before running bash. Maybe we should be looking into introducing a way to set the CYGWIN environment variable in the global environment and adding c:\cygwin\bin (or whatever) to the global PATH as well. But, I am extemely in favor of making mintty the default terminal. It would present a much nicer end-user experience out-of-the-box even if some pty stuff doesn't work quite right. And, I can just imagine the blog entries now: "Cygwin finally offers an intelligent terminal interface - after ten years!" The only downside that I see is that Andy may ask to renegotiate his contract. I wouldn't be surprised if he asked to be paid double what he's getting now, in fact. cgf
Re: setup and mintty (was Re: New setup.exe release?)
On May 23 11:33, Charles Wilson wrote:
> On 5/23/2011 7:50 AM, Corinna Vinschen wrote:
> > On May 20 17:09, Yaakov (Cygwin/X) wrote:
> >> The setup.exe download is still 2.738. Could it be updated to 2.749
> >> to include jturney's recent bug fixes?
> >
> > I'd like to fix the mintty issue first.
> >
> > So, do we swtch to mintty as default terminal, yes or no?
>
> Uhm, maybe? :-)
>
> Here's the deal: run the following program from the ncurses-demo package:
> /usr/lib/ncurses/test/lrtest.exe
> in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG
> settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW,
> TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox.
>
> In the former, I see pseudo-line drawing characters (e.g hyphens and
> plus signs, etc), but in the latter I see real line draw characters.
>
> Why?
>
> I suspect the reason is the terminfo settings for mintty (e.g. for
> xterm-256color) specifies
> acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
> (inherited via terminfo 'use' statements from xterm-basic), while the
> terminfo settings for cygwin specify
>
> acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
>
> 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.
> 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? 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.
> 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.
> 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.
> > 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.
> > 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.
> > 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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Lead
Re: setup and mintty (was Re: New setup.exe release?)
On 5/23/2011 7:50 AM, Corinna Vinschen wrote:
> On May 20 17:09, Yaakov (Cygwin/X) wrote:
>> The setup.exe download is still 2.738. Could it be updated to 2.749
>> to include jturney's recent bug fixes?
>
> I'd like to fix the mintty issue first.
>
> So, do we swtch to mintty as default terminal, yes or no?
Uhm, maybe? :-)
Here's the deal: run the following program from the ncurses-demo package:
/usr/lib/ncurses/test/lrtest.exe
in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG
settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW,
TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox.
In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.
Why?
I suspect the reason is the terminfo settings for mintty (e.g. for
xterm-256color) specifies
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
(inherited via terminfo 'use' statements from xterm-basic), while the
terminfo settings for cygwin specify
acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
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?)
Now, according to a post from 2004 by T.E. Dickey (ncurses/terminfo
maintainer):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256446
non-wide ncurses relies on the acsc,
wide-curses has a kludge to recognize UTF-8 locales and an internal
table for line-drawing characters.
...which also has a suggested patch for putty, but it's not clear it was
ever adopted.
So...trying the wide variant
/usr/lib/ncursesw/test/lrtest.exe
I get the same behavior as before in mintty (e.g. no linedraw
chars)...so there goes that idea (maybe the 'kludge' has been removed
from libncursesw between 2004 and now).
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.
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.)
2) do we need an explicit mintty terminfo entry, with a 'better' acsc
entry -- OTOH, it is *NOT* possible to put unicode values in the
terminfo src string, so that's probably a nonstarter, unless combined
with (1). (also: ugh. must propagate the entry to all server OSs to
which you want to ssh...push upstream to ncurses...wait years for
RHEL7.0 to adopt it...)
3) Maybe there is some magic combination of envvar TERM/LANG,
settings, mintty options, font choices, etc, that will make linedraw work?
4) bug (or misconfiguration) in cygwin ncurses- or ncursesw- ?
5) or punt. Who needs linedraw anyway.
I'm ok with #5...but just wanted to bring up the issue so the decision
is an informed one.
> 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.
> 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.
> 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.
--
Chuck
setup and mintty (was Re: New setup.exe release?)
On May 20 17:09, Yaakov (Cygwin/X) wrote: > The setup.exe download is still 2.738. Could it be updated to 2.749 > to include jturney's recent bug fixes? I'd like to fix the mintty issue first. So, do we swtch to mintty as default terminal, yes or no? 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? If so, should we stick to the content of Cygwin.bat as is, or should we change it to call mintty, too? And who's going to create the patches? Last but not least, shouldn't we add mintty to the Base package anyway, independently of what we do to setup? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
