* [ANNOUNCEMENT] xterm 348-1 @ 2019-09-11 22:43 Yaakov Selkowitz 2019-11-01 1:36 ` Katsumi Yamaoka 0 siblings, 1 reply; 14+ messages in thread From: Yaakov Selkowitz @ 2019-09-11 22:43 UTC (permalink / raw) To: cygwin The following packages have been uploaded to the Cygwin distribution: * xterm-348-1 The xterm program is a terminal emulator for the X Window System. It provides DEC VT102 and Tektronix 4014 compatible terminals for programs that can't use the window system directly. This version implements ISO/ANSI colors using the 'new' color model (i.e., background color erase). It also implements most of the control sequences for VT220. This is an update to the latest upstream release. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-09-11 22:43 [ANNOUNCEMENT] xterm 348-1 Yaakov Selkowitz @ 2019-11-01 1:36 ` Katsumi Yamaoka 2019-11-06 12:13 ` Takashi Yano 0 siblings, 1 reply; 14+ messages in thread From: Katsumi Yamaoka @ 2019-11-01 1:36 UTC (permalink / raw) To: cygwin Hi, On Wed, 11 Sep 2019 18:24:37 -0400, Yaakov Selkowitz wrote: > The following packages have been uploaded to the Cygwin distribution: > * xterm-348-1 First of all, reverting it to XTerm(330) solved my problem. When copying non-ASCII text from another window to XTerm(348), it will be shown as a combination of ASCII and control characters, not the original human readable representation. I usually use Japanese text, これは日本語です for example. AFAICT, only the copy and paste is bad; `less' shows Japanese text and `ls' shows Japanese file names correctly. Is there a way to fix this problem? $ locale LANG=C LC_CTYPE="ja_JP.UTF-8" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= Thanks. Regards, -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-01 1:36 ` Katsumi Yamaoka @ 2019-11-06 12:13 ` Takashi Yano 2019-11-06 14:11 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Takashi Yano @ 2019-11-06 12:13 UTC (permalink / raw) To: cygwin On Fri, 01 Nov 2019 10:36:06 +0900 Katsumi Yamaoka wrote: > Hi, > > On Wed, 11 Sep 2019 18:24:37 -0400, Yaakov Selkowitz wrote: > > The following packages have been uploaded to the Cygwin distribution: > > > * xterm-348-1 > > First of all, reverting it to XTerm(330) solved my problem. > When copying non-ASCII text from another window to XTerm(348), it > will be shown as a combination of ASCII and control characters, > not the original human readable representation. > > I usually use Japanese text, これは日本語です for example. AFAICT, > only the copy and paste is bad; `less' shows Japanese text and > `ls' shows Japanese file names correctly. > > Is there a way to fix this problem? > > $ locale > LANG=C > LC_CTYPE="ja_JP.UTF-8" > LC_NUMERIC="C" > LC_TIME="C" > LC_COLLATE="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_ALL= I confirmed this occurs only if shell is tcsh. If shell is bash, zsh or fish, pasting Japanese string works as expected. It works in cat, od, etc as well. The cause is unknown. -- Takashi Yano <takashi.yano@nifty.ne.jp> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-06 12:13 ` Takashi Yano @ 2019-11-06 14:11 ` Brian Inglis 2019-11-06 15:48 ` Takashi Yano 0 siblings, 1 reply; 14+ messages in thread From: Brian Inglis @ 2019-11-06 14:11 UTC (permalink / raw) To: cygwin On 2019-11-06 05:13, Takashi Yano wrote: > > > On Fri, 01 Nov 2019 10:36:06 +0900 > Katsumi Yamaoka wrote: >> Hi, >> >> On Wed, 11 Sep 2019 18:24:37 -0400, Yaakov Selkowitz wrote: >>> The following packages have been uploaded to the Cygwin distribution: >> >>> * xterm-348-1 >> >> First of all, reverting it to XTerm(330) solved my problem. >> When copying non-ASCII text from another window to XTerm(348), it >> will be shown as a combination of ASCII and control characters, >> not the original human readable representation. >> >> I usually use Japanese text, ããã¯æ¥æ¬èªã§ã for example. AFAICT, >> only the copy and paste is bad; `less' shows Japanese text and >> `ls' shows Japanese file names correctly. >> >> Is there a way to fix this problem? >> >> $ locale >> LANG=C >> LC_CTYPE="ja_JP.UTF-8" >> LC_NUMERIC="C" >> LC_TIME="C" >> LC_COLLATE="C" >> LC_MONETARY="C" >> LC_MESSAGES="C" >> LC_ALL= > > I confirmed this occurs only if shell is tcsh. If shell is bash, zsh > or fish, pasting Japanese string works as expected. It works in cat, > od, etc as well. > > The cause is unknown. Does it work properly if LANG="ja_JP.UTF-8" under tcsh? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-06 14:11 ` Brian Inglis @ 2019-11-06 15:48 ` Takashi Yano 2019-11-06 17:24 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Takashi Yano @ 2019-11-06 15:48 UTC (permalink / raw) To: cygwin; +Cc: Brian.Inglis On Wed, 6 Nov 2019 07:11:14 -0700 Brian Inglis wrote: > On 2019-11-06 05:13, Takashi Yano wrote: > > > > > > On Fri, 01 Nov 2019 10:36:06 +0900 > > Katsumi Yamaoka wrote: > >> Hi, > >> > >> On Wed, 11 Sep 2019 18:24:37 -0400, Yaakov Selkowitz wrote: > >>> The following packages have been uploaded to the Cygwin distribution: > >> > >>> * xterm-348-1 > >> > >> First of all, reverting it to XTerm(330) solved my problem. > >> When copying non-ASCII text from another window to XTerm(348), it > >> will be shown as a combination of ASCII and control characters, > >> not the original human readable representation. > >> > >> I usually use Japanese text, これは日本語です for example. AFAICT, > >> only the copy and paste is bad; `less' shows Japanese text and > >> `ls' shows Japanese file names correctly. > >> > >> Is there a way to fix this problem? > >> > >> $ locale > >> LANG=C > >> LC_CTYPE="ja_JP.UTF-8" > >> LC_NUMERIC="C" > >> LC_TIME="C" > >> LC_COLLATE="C" > >> LC_MONETARY="C" > >> LC_MESSAGES="C" > >> LC_ALL= > > > > I confirmed this occurs only if shell is tcsh. If shell is bash, zsh > > or fish, pasting Japanese string works as expected. It works in cat, > > od, etc as well. > > > > The cause is unknown. > > Does it work properly if LANG="ja_JP.UTF-8" under tcsh? No, it does not. -- Takashi Yano <takashi.yano@nifty.ne.jp> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-06 15:48 ` Takashi Yano @ 2019-11-06 17:24 ` Brian Inglis 2019-11-07 2:40 ` Takashi Yano 0 siblings, 1 reply; 14+ messages in thread From: Brian Inglis @ 2019-11-06 17:24 UTC (permalink / raw) To: cygwin; +Cc: Takashi Yano On 2019-11-06 08:48, Takashi Yano wrote: > On Wed, 6 Nov 2019 07:11:14 -0700 Brian Inglis wrote: >> On 2019-11-06 05:13, Takashi Yano wrote: >>> On Fri, 01 Nov 2019 10:36:06 +0900 >>> Katsumi Yamaoka wrote: >>>> On Wed, 11 Sep 2019 18:24:37 -0400, Yaakov Selkowitz wrote: >>>>> The following packages have been uploaded to the Cygwin distribution: >>>>> * xterm-348-1 >>>> First of all, reverting it to XTerm(330) solved my problem. >>>> When copying non-ASCII text from another window to XTerm(348), it >>>> will be shown as a combination of ASCII and control characters, >>>> not the original human readable representation. >>>> I usually use Japanese text, ããã¯æ¥æ¬èªã§ã for example. AFAICT, >>>> only the copy and paste is bad; `less' shows Japanese text and >>>> `ls' shows Japanese file names correctly. >>>> Is there a way to fix this problem? >>>> $ locale >>>> LANG=C >>>> LC_CTYPE="ja_JP.UTF-8" >>>> LC_NUMERIC="C" >>>> LC_TIME="C" >>>> LC_COLLATE="C" >>>> LC_MONETARY="C" >>>> LC_MESSAGES="C" >>>> LC_ALL= >>> I confirmed this occurs only if shell is tcsh. If shell is bash, zsh >>> or fish, pasting Japanese string works as expected. It works in cat, >>> od, etc as well. >>> The cause is unknown. >> Does it work properly if LANG="ja_JP.UTF-8" under tcsh? > No, it does not. Does tcsh input work properly under mintty instead of xterm? How does it work in cat, od, etc.? That can not include using input via tcsh? Presumably you are using IME(s) for Japanese input - which at what input layer(s)? I noticed that xterm was updated to Unicode 10 then 11, with changes to CJK/East Asian character properties and handling; tcsh dropped libcatgets1 as a dependency; those could affect input. It sounds like an issue with either xterm or tcsh input locale handling, but both apparently handle locales well, so it may be a configuration issue caused by a recent change. It may be useful to read the FAQs (https://invisible-island.net/xterm/xterm.faq.html, https://www.tcsh.org/faq/), then open issues directly with xterm and/or tcsh upstream maintainers (https://invisible-island.net/personal/bug-reports.html, https://mailman.astron.com/mailman/listinfo/tcsh) to get more info. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-06 17:24 ` Brian Inglis @ 2019-11-07 2:40 ` Takashi Yano 2019-11-07 8:31 ` Thomas Wolff ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Takashi Yano @ 2019-11-07 2:40 UTC (permalink / raw) To: cygwin; +Cc: Brian.Inglis, Katsumi Yamaoka On Wed, 6 Nov 2019 10:24:29 -0700 Brian Inglis wrote: > Does tcsh input work properly under mintty instead of xterm? Yes, it works under mintty. > How does it work in cat, od, etc.? That can not include using input via tcsh? cat, od, etc. are works even if they are started from tcsh. > Presumably you are using IME(s) for Japanese input - which at what input layer(s)? I'm using Microsoft-made IME (MS-IME). > I noticed that xterm was updated to Unicode 10 then 11, with changes to CJK/East > Asian character properties and handling; tcsh dropped libcatgets1 as a > dependency; those could affect input. I confirmed the issue does not occur in the combination of: Debian/sid + xterm 349 + tcsh 6.21.00 Debian/buster + xterm 344 + tcsh 6.20.00 Therefore, this may be a cygwin dedicated issue. Wait. I have just found /etc/X11/app-defaults/XTerm has a entry *VT100*eightBitInput: false which is added from cygwin xterm 348-1. Removing this line or changing the value to true solves this issue. Katsumi, could you please check if this solves the issue? -- Takashi Yano <takashi.yano@nifty.ne.jp> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 2:40 ` Takashi Yano @ 2019-11-07 8:31 ` Thomas Wolff 2019-11-07 10:16 ` Takashi Yano ` (2 more replies) 2019-11-08 4:19 ` Katsumi Yamaoka 2019-11-08 13:13 ` Brian Inglis 2 siblings, 3 replies; 14+ messages in thread From: Thomas Wolff @ 2019-11-07 8:31 UTC (permalink / raw) To: cygwin, Yaakov Selkowitz Am 07.11.2019 um 03:39 schrieb Takashi Yano: > ... > Wait. I have just found /etc/X11/app-defaults/XTerm has a entry > *VT100*eightBitInput: false > which is added from cygwin xterm 348-1. > > Removing this line or changing the value to true solves this issue. > > Katsumi, could you please check if this solves the issue? The option value of eightBitInput must not be set to false nowadays, it's a relic of ASCII times. There are a number of further questionable changes in /etc/X11/app-defaults/XTerm (not checked to other XTerm default entries there):  < *backarrowKeyIsErase: true  < *metaSendsEscape: true  < *ptyInitialErase: true  > ! Cygwin Defaults  > +*backarrowKeyIsErase: true  > +*metaSendsEscape: true  > +*ptyInitialErase: true Using the obscure "+" prefix here seems to reset the option to its default, regardless of the given value. Clearer configuration would be preferrable. Changing backarrowKeyIsErase and ptyInitialErase consistently may go unnoticed for most users, but it effectively switches away from the Linux habit to use DEL for the backarrow key, just to note. Setting metaSendsEscape to false make input inconsistent. Alt+x will still enter ESC x (for whatever reason) but Alt+ö will enter only ö (again, for whatever reason). Option value true makes this consistent.  > ! Red Hat Defaults:  > *allowFontOps: false  > *allowTcapOps: false The "allow*" options are meant to provide security but I see no security problem with these two, particularly not TcapOps (which seems to be used by vim to fine-tune terminal feature usage).  > *VT100*eightBitInput: false Must be true!  > *VT100*scrollBar: true Why not, but it's a change that users may dislike.  > *VT100*utf8Title: true Probably a good idea.  > *termName: xterm-256color For applications that make a difference in colour usage depending on the TERM setting, this updates mega-legacy 16 colours to legacy 256 colours. Note that xterm also supplies a terminfo entry "xterm-direct" to reflect true colour support. Using it would require an update of the terminfo package, too, though, to get the xterm-direct entry included. ------ Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 8:31 ` Thomas Wolff @ 2019-11-07 10:16 ` Takashi Yano 2019-11-07 15:52 ` Brian Inglis 2019-11-07 15:50 ` Brian Inglis 2019-11-07 17:03 ` Brian Inglis 2 siblings, 1 reply; 14+ messages in thread From: Takashi Yano @ 2019-11-07 10:16 UTC (permalink / raw) To: cygwin On Thu, 7 Nov 2019 09:31:24 +0100 Thomas Wolff wrote: > > ! Cygwin Defaults > > +*backarrowKeyIsErase: true > > +*metaSendsEscape: true > > +*ptyInitialErase: true I guess these +'s at the beginning of the lines are just mistake, and should be: ! Cygwin Defaults *backarrowKeyIsErase: true *metaSendsEscape: true *ptyInitialErase: true as they were in 330-1. -- Takashi Yano <takashi.yano@nifty.ne.jp> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 10:16 ` Takashi Yano @ 2019-11-07 15:52 ` Brian Inglis 0 siblings, 0 replies; 14+ messages in thread From: Brian Inglis @ 2019-11-07 15:52 UTC (permalink / raw) To: cygwin On 2019-11-07 03:16, Takashi Yano wrote: > On Thu, 7 Nov 2019 09:31:24 +0100 > Thomas Wolff wrote: >> > ! Cygwin Defaults >> > +*backarrowKeyIsErase: true >> > +*metaSendsEscape: true >> > +*ptyInitialErase: true > > I guess these +'s at the beginning of the lines are just mistake, > and should be: > ! Cygwin Defaults > *backarrowKeyIsErase: true > *metaSendsEscape: true > *ptyInitialErase: true > as they were in 330-1. Could be an artifact from a diff edit to compare and update the Cygwin defaults? Oops! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 8:31 ` Thomas Wolff 2019-11-07 10:16 ` Takashi Yano @ 2019-11-07 15:50 ` Brian Inglis 2019-11-07 17:03 ` Brian Inglis 2 siblings, 0 replies; 14+ messages in thread From: Brian Inglis @ 2019-11-07 15:50 UTC (permalink / raw) To: cygwin On 2019-11-07 01:31, Thomas Wolff wrote: > Am 07.11.2019 um 03:39 schrieb Takashi Yano: >> ... >> Wait. I have just found /etc/X11/app-defaults/XTerm has a entry >> *VT100*eightBitInput: false >> which is added from cygwin xterm 348-1. >> >> Removing this line or changing the value to true solves this issue. >> >> Katsumi, could you please check if this solves the issue? > The option value of eightBitInput must not be set to false nowadays, it's a > relic of ASCII times. > There are a number of further questionable changes in /etc/X11/app-defaults/XTerm > (not checked to other XTerm default entries there): > >  < *backarrowKeyIsErase: true >  < *metaSendsEscape: true >  < *ptyInitialErase: true >  > ! Cygwin Defaults >  > +*backarrowKeyIsErase: true >  > +*metaSendsEscape: true >  > +*ptyInitialErase: true > Using the obscure "+" prefix here seems to reset the option to its default, > regardless of the given value. Clearer configuration would be preferrable. > Changing backarrowKeyIsErase and ptyInitialErase consistently may go unnoticed > for most users, but it effectively switches away from the Linux habit to use DEL > for the backarrow key, just to note. > Setting metaSendsEscape to false make input inconsistent. Alt+x will still enter > ESC x (for whatever reason) but Alt+ö will enter only ö (again, for whatever > reason). Option value true makes this consistent. > >  > ! Red Hat Defaults: >  > *allowFontOps: false >  > *allowTcapOps: false > The "allow*" options are meant to provide security but I see no security problem > with these two, particularly not TcapOps (which seems to be used by vim to > fine-tune terminal feature usage). > >  > *VT100*eightBitInput: false > Must be true! >  > *VT100*scrollBar: true > Why not, but it's a change that users may dislike. >  > *VT100*utf8Title: true > Probably a good idea. >  > *termName: xterm-256color > For applications that make a difference in colour usage depending on the TERM > setting, this updates mega-legacy 16 colours to legacy 256 colours. > Note that xterm also supplies a terminfo entry "xterm-direct" to reflect true > colour support. Using it would require an update of the terminfo package, too, > though, to get the xterm-direct entry included. Thomas E. Dickey added it with others in the prerelease for 20180127 6.1, see: $ less +/xterm /usr/share/doc/ncurses/NEWS and they are in the current Cygwin package terminfo 6.1-1.20190727, which is in Base category and always installed/upgraded (many of the xterm+* entries are in dependency terminfo-extra and disable the capabilities enabled or set by the corresponding xterm-* entry): $ l /usr/share/terminfo/78/xterm* /usr/share/terminfo/78/xterm /usr/share/terminfo/78/xterm-1003 /usr/share/terminfo/78/xterm.js@ /usr/share/terminfo/78/xterm-1005 /usr/share/terminfo/78/xterm+256color /usr/share/terminfo/78/xterm-1006 /usr/share/terminfo/78/xterm+256setaf /usr/share/terminfo/78/xterm-16color /usr/share/terminfo/78/xterm+88color /usr/share/terminfo/78/xterm-24 /usr/share/terminfo/78/xterm+alt+title /usr/share/terminfo/78/xterm-256color /usr/share/terminfo/78/xterm+alt1049 /usr/share/terminfo/78/xterm-88color /usr/share/terminfo/78/xterm+app /usr/share/terminfo/78/xterm-8bit /usr/share/terminfo/78/xterm+direct /usr/share/terminfo/78/xterm-basic /usr/share/terminfo/78/xterm+direct2 /usr/share/terminfo/78/xterm-bold /usr/share/terminfo/78/xterm+edit /usr/share/terminfo/78/xtermc /usr/share/terminfo/78/xterm+indirect /usr/share/terminfo/78/xterm-color /usr/share/terminfo/78/xterm+kbs /usr/share/terminfo/78/xterm-direct /usr/share/terminfo/78/xterm+keypad /usr/share/terminfo/78/xterm-direct2 /usr/share/terminfo/78/xterm+noalt /usr/share/terminfo/78/xterm-hp /usr/share/terminfo/78/xterm+noapp /usr/share/terminfo/78/xtermm /usr/share/terminfo/78/xterm+osc104 /usr/share/terminfo/78/xterm-new /usr/share/terminfo/78/xterm+pc+edit /usr/share/terminfo/78/xterm-nic /usr/share/terminfo/78/xterm+pcc0 /usr/share/terminfo/78/xterm-noapp /usr/share/terminfo/78/xterm+pcc1 /usr/share/terminfo/78/xterm-old /usr/share/terminfo/78/xterm+pcc2 /usr/share/terminfo/78/xterm-pcolor /usr/share/terminfo/78/xterm+pcc3 /usr/share/terminfo/78/xterm-r5 /usr/share/terminfo/78/xterm+pce2 /usr/share/terminfo/78/xterm-r6 /usr/share/terminfo/78/xterm+pcf0 /usr/share/terminfo/78/xterms@ /usr/share/terminfo/78/xterm+pcf2 /usr/share/terminfo/78/xterm-sco /usr/share/terminfo/78/xterm+pcfkeys /usr/share/terminfo/78/xterms-sun /usr/share/terminfo/78/xterm+r6f2 /usr/share/terminfo/78/xterm-sun /usr/share/terminfo/78/xterm+sl /usr/share/terminfo/78/xterm-utf8 /usr/share/terminfo/78/xterm+sl-twm /usr/share/terminfo/78/xterm-vt220 /usr/share/terminfo/78/xterm+sm+1002 /usr/share/terminfo/78/xterm-vt52 /usr/share/terminfo/78/xterm+sm+1003 /usr/share/terminfo/78/xterm-x10mouse /usr/share/terminfo/78/xterm+sm+1005 /usr/share/terminfo/78/xterm-x11hilite /usr/share/terminfo/78/xterm+sm+1006 /usr/share/terminfo/78/xterm-x11mouse /usr/share/terminfo/78/xterm+titlestack /usr/share/terminfo/78/xterm-xf86-v32 /usr/share/terminfo/78/xterm+tmux /usr/share/terminfo/78/xterm-xf86-v33 /usr/share/terminfo/78/xterm+vt+edit /usr/share/terminfo/78/xterm-xf86-v333 /usr/share/terminfo/78/xterm+x10mouse /usr/share/terminfo/78/xterm-xf86-v40 /usr/share/terminfo/78/xterm+x11hilite /usr/share/terminfo/78/xterm-xf86-v43 /usr/share/terminfo/78/xterm+x11mouse /usr/share/terminfo/78/xterm-xf86-v44 /usr/share/terminfo/78/xterm1 /usr/share/terminfo/78/xterm-xfree86 /usr/share/terminfo/78/xterm-1002 /usr/share/terminfo/78/xterm-xi -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 8:31 ` Thomas Wolff 2019-11-07 10:16 ` Takashi Yano 2019-11-07 15:50 ` Brian Inglis @ 2019-11-07 17:03 ` Brian Inglis 2 siblings, 0 replies; 14+ messages in thread From: Brian Inglis @ 2019-11-07 17:03 UTC (permalink / raw) To: cygwin On 2019-11-07 01:31, Thomas Wolff wrote: > Am 07.11.2019 um 03:39 schrieb Takashi Yano: >> ... >> Wait. I have just found /etc/X11/app-defaults/XTerm has a entry >> *VT100*eightBitInput: false >> which is added from cygwin xterm 348-1. >> >> Removing this line or changing the value to true solves this issue. >> >> Katsumi, could you please check if this solves the issue? > The option value of eightBitInput must not be set to false nowadays, it's a > relic of ASCII times. > There are a number of further questionable changes in /etc/X11/app-defaults/XTerm > (not checked to other XTerm default entries there): > >  < *backarrowKeyIsErase: true >  < *metaSendsEscape: true >  < *ptyInitialErase: true >  > ! Cygwin Defaults >  > +*backarrowKeyIsErase: true >  > +*metaSendsEscape: true >  > +*ptyInitialErase: true > Using the obscure "+" prefix here seems to reset the option to its default, > regardless of the given value. Clearer configuration would be preferrable. Normal practice is to set the default value and comment out the entry. Is this an obscure comment convention rather than !? > Changing backarrowKeyIsErase and ptyInitialErase consistently may go unnoticed > for most users, but it effectively switches away from the Linux habit to use DEL > for the backarrow key, just to note. > Setting metaSendsEscape to false make input inconsistent. Alt+x will still enter > ESC x (for whatever reason) but Alt+ö will enter only ö (again, for whatever > reason). Option value true makes this consistent. > >  > ! Red Hat Defaults: >  > *allowFontOps: false >  > *allowTcapOps: false > The "allow*" options are meant to provide security but I see no security problem > with these two, particularly not TcapOps (which seems to be used by vim to > fine-tune terminal feature usage). In a malicious script, font size could be set to tiny, text made invisible, or foreground set to match background, to hide or obscure execution of malicious commands, such as those exploited using bashdoor/shellshock vulnerabilities, plus xterm *ops exec code and shell vulnerabilities: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030? https://www.cvedetails.com/vulnerability-list/vendor_id-5838/product_id-9872/Invisible-island-Xterm.html https://www.cvedetails.com/vulnerability-list/vendor_id-88/product_id-170/X.org-Xterm.html https://www.cvedetails.com/vulnerability-list/vendor_id-7100/product_id-11978/Xterm-Xterm.html >  > *VT100*eightBitInput: false > Must be true! >  > *VT100*scrollBar: true > Why not, but it's a change that users may dislike. >  > *VT100*utf8Title: true > Probably a good idea. >  > *termName: xterm-256color > For applications that make a difference in colour usage depending on the TERM > setting, this updates mega-legacy 16 colours to legacy 256 colours. > Note that xterm also supplies a terminfo entry "xterm-direct" to reflect true > colour support. Using it would require an update of the terminfo package, too, > though, to get the xterm-direct entry included. You may submit a patch to the package/file(s) on the cygwin-apps list, and perhaps also upstream to Thomas E. Dickey, with links to the issue and discussion, if only for info. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 2:40 ` Takashi Yano 2019-11-07 8:31 ` Thomas Wolff @ 2019-11-08 4:19 ` Katsumi Yamaoka 2019-11-08 13:13 ` Brian Inglis 2 siblings, 0 replies; 14+ messages in thread From: Katsumi Yamaoka @ 2019-11-08 4:19 UTC (permalink / raw) To: cygwin On Thu, 07 Nov 2019 11:39:36 +0900, Takashi Yano wrote: > Wait. I have just found /etc/X11/app-defaults/XTerm has a entry > *VT100*eightBitInput: false > which is added from cygwin xterm 348-1. > Removing this line or changing the value to true solves this issue. > Katsumi, could you please check if this solves the issue? Oh, that's really great! I added XTerm*VT100*eightBitInput: true to the ~/.Xdefaults file (instead of changing that XTerm file) and confirmed pasting non-ASCII text came to work again on tcsh. Thanks a lot, Yano-san! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] xterm 348-1 2019-11-07 2:40 ` Takashi Yano 2019-11-07 8:31 ` Thomas Wolff 2019-11-08 4:19 ` Katsumi Yamaoka @ 2019-11-08 13:13 ` Brian Inglis 2 siblings, 0 replies; 14+ messages in thread From: Brian Inglis @ 2019-11-08 13:13 UTC (permalink / raw) To: cygwin On 2019-11-06 19:39, Takashi Yano wrote: > On Wed, 6 Nov 2019 10:24:29 -0700 > Brian Inglis wrote: >> Does tcsh input work properly under mintty instead of xterm? > > Yes, it works under mintty. > >> How does it work in cat, od, etc.? That can not include using input via tcsh? > > cat, od, etc. are works even if they are started from tcsh. > >> Presumably you are using IME(s) for Japanese input - which at what input layer(s)? > > I'm using Microsoft-made IME (MS-IME). > >> I noticed that xterm was updated to Unicode 10 then 11, with changes to CJK/East >> Asian character properties and handling; tcsh dropped libcatgets1 as a >> dependency; those could affect input. > > I confirmed the issue does not occur in the combination of: > Debian/sid + xterm 349 + tcsh 6.21.00 > Debian/buster + xterm 344 + tcsh 6.20.00 > > Therefore, this may be a cygwin dedicated issue. > > Wait. I have just found /etc/X11/app-defaults/XTerm has a entry > *VT100*eightBitInput: false > which is added from cygwin xterm 348-1. > > Removing this line or changing the value to true solves this issue. > > Katsumi, could you please check if this solves the issue? Excellent catch! Great work! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-11-08 13:13 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-11 22:43 [ANNOUNCEMENT] xterm 348-1 Yaakov Selkowitz 2019-11-01 1:36 ` Katsumi Yamaoka 2019-11-06 12:13 ` Takashi Yano 2019-11-06 14:11 ` Brian Inglis 2019-11-06 15:48 ` Takashi Yano 2019-11-06 17:24 ` Brian Inglis 2019-11-07 2:40 ` Takashi Yano 2019-11-07 8:31 ` Thomas Wolff 2019-11-07 10:16 ` Takashi Yano 2019-11-07 15:52 ` Brian Inglis 2019-11-07 15:50 ` Brian Inglis 2019-11-07 17:03 ` Brian Inglis 2019-11-08 4:19 ` Katsumi Yamaoka 2019-11-08 13:13 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).