[ANNOUNCEMENT] xterm 348-1

[ANNOUNCEMENT] xterm 348-1

[Yaakov Selkowitz]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Katsumi Yamaoka]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Takashi Yano]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Brian Inglis]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Takashi Yano]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Brian Inglis]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Takashi Yano]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Thomas Wolff]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Takashi Yano]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Brian Inglis]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Brian Inglis]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Brian Inglis]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Katsumi Yamaoka]

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

Re: [ANNOUNCEMENT] xterm 348-1

[Brian Inglis]

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