Bug#223926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=223926

[Thomas Dickey]

>   Debian Bug report logs - #223926
>uxterm still runs when "-help" option specified

this is a simple script fix (will be in my next patch, e.g., #183).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#200857: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200857

[Thomas Dickey]

>   Debian Bug report logs - #200857
> xterm fails to honour dtterm sequence ESC[21t
...

>I think it might be better to do something like this [see patch]:
>The iscntrl() test can be replaced easily if more/less paranoia is
>required - it's not really fair to expect apps to figure out the
>escape sequence is just gone, as afaict there's no way to ask if
>a term supports many of them other than checking TERM and going by
>what you know/expect that terminal to support.

not exactly - the label doesn't have control characters - see this chunk
in misc.c:

default:
if (ansi_table[CharOf(*cp)] != CASE_PRINT)
return;
}

The complaint is that someone could be misled into pressing return after
a bogus title was sent to the host, e.g., as part of cat'ing a core-dump
to the terminal.  (Why anyone would want to do this is another story).
Or doing tail -f on a so-called logfile (no different ;-).

This is in patch #174 (would allow someone to use these features if they're
inclined to read the manpage):

   allowWindowOps (class AllowWindowOps)
   Specifies   whether   extended   windowcontrol
   sequences  (as  used  in  dtterm)  for  should  be
   allowed.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#200857: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200857

[Thomas Dickey]

>   Debian Bug report logs - #200857
> xterm fails to honour dtterm sequence ESC[21t
...
>   allowWindowOps (class AllowWindowOps)
>   Specifies   whether   extended   windowcontrol
>   sequences  (as  used  in  dtterm)  for  should  be
>   allowed.
...
>From: Vivek <[EMAIL PROTECTED]>
...
>Ok then: assuming this defaults/will default to "false", there's no
>real need to stomp on the sequence handling completely, then, right?

That's my viewpoint - if Brendan adds a "false" to the system app-defaults
file, it would still allow a user to override it and get the features.

Making it return an empty string would be incorrect behavior - if it's
not implemented, it should be parsed & ignored.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#208493: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208493

[Thomas Dickey]

On Wed, Sep 03, 2003 at 04:17:41PM -0500, Branden Robinson wrote:
> tag 208493 + wontfix
> thanks
> 
> On Wed, Sep 03, 2003 at 03:55:56PM -0400, [EMAIL PROTECTED] wrote:
> >Debian Bug report logs - #208493
> > > xterm: openi18n patch
> > I'm afraid that I don't regard that as "clean".  The reverse.
> 
> Tagging this bug as "wontfix" pending further discussion, then.  I do
> not want to fork from Mr. Dickey's xterm too badly.

There's a lot of discussion that could be made - the patch is based on X11R6.1
xterm.  So one would have to study it to see how to add whatever features it
provides that XFree86 xterm does not.  I reviewed it last year, found that it
added bugs that I could demonstrate with vttest.  (And rather than fix some of
the problems that I noticed with X11R6.3 xterm, the resulting Solaris 9 xterm
has a bad memory leak in resizing).  Some of the symbol names in the patch
demonstrate to me that the patch's author was moderately familiar with XFree86
xterm.

Studying the patch itself, I noticed more than one place where it did not do
error-checking.  The documentation doesn't state _what_ it does, only that it
does something better.  Code Set Independence, as I found by reading mailing
list is not actually implemented in this patch (it's not well-defined, but from
the author's discussion, this patch cannot achieve it - he had, as I recall,
more ambitious plans which are not reflected in the patch).

This is not to say that there's nothing there - but making a good job
of it will take more work by me than was done by the patch's author.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#205255: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205255

[Thomas Dickey]

>  Debian Bug report logs - [1]#205255
> xterm: fails on intensity specifications rgbi:

This fails because of the X11 library rather than xterm.

I considered whether it was due to delaying the lookup of colors (and possibly
using a different method), but restoring the "original" way resources were
found, there's no change (so I'm certain that it is not due to a change in
xterm).  However, I am not able to see where X11 has changed either.

Reading through Xlib I see the issue is that in de_DE locale, a "," is used for
a decimal separator rather than ".".  The XcmsLRGB_RGBi_ParseString() function
uses sscanf, which (given the locale) expects a comma.  That particular part
of the code hasn't changed since XFree86 3.3.6.  The available documentation
does not mention whether this string should be interpreted in a locale-specific
manner, only an oblique reference to its character set.

>xterm does not recognise intensity specifications like
>
>XTerm*VT100*color1:  rgbi:0.4/0.0/0.0
>
>Error message:
>
> xterm: Cannot allocate color rgbi:0.4/0.0/0.0
>
>It did definitively work in earlier versions.

more information about the earlier versions would be helpful, but in any
case this bug is not related to xterm.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#205255: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205255

[Thomas Dickey]

On Fri, 19 Sep 2003, Branden Robinson wrote:

> reassign 205255 xlibs
> retitle 205255 xlibs: [libX11] XcmsLRGB_RGBi_ParseString() uses sscanf() to parse 
> floats but is not locale-aware
> tag 205255 = upstream
> severity 205255 normal
> thanks
>
> Thanks for your analysis, Thomas.

no problem

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#198910: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198910

[Thomas Dickey]

>  Debian Bug report logs - [1]#198910
>   xterm(1) confuses ampersand and @ symbol

I just committed a fix for this in XFree86 CVS.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#10445: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10445

[Thomas Dickey]

>  Debian Bug report logs - [1]#10445
> xterm: using -e with -ls fails to open a login shell

This should be closed since the documentation fixes requested were made.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#179846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179846

[Thomas Dickey]

>   Debian Bug report logs - #179846
> xterm: not documented that xterm squelches ${TMPDIR}

xterm doesn't; it is a feature of the system to remove various environment
variables.

>I myself will probably look into the sources to see whether xterm is deleting
>any other envariables.  They should be listed in the documentation for everyone
>to notice.

I assume he's going to document it - if/when he reads the code -
but it doesn't belong in xterm's manpage.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#37517: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37517

[Thomas Dickey]

>Debian Bug report logs - #37517
>  xterm: binary files can cause xterm to hang and dump into the printer queue
>  with printerCommand

this one should be closed, since it was addressed in patch #167.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#179929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179929

[Thomas Dickey]

>   Debian Bug report logs - #179929
>   xterm: uxterm's regexp doesn't catch modifiers in locale settings

the attached script is incorrect (i.e., is specific to GNU sed),
I'll have a workable version in patch #175.

>--- uxterm.orig 2003-02-05 10:40:04.0 +0100
>+++ uxterm  2003-02-05 18:43:52.0 +0100
>@@ -30,7 +30,7 @@
> # user's shell does not reset unknown locale specifiers, but not all shells do
>.
> if test $found != yes ; then
>if test -n "$value" ; then
>-   eval ${name}=`echo ${value} |sed -e 's/\..*//'`.UTF-8
>+   eval ${name}=`echo ${value} |sed -e 's/\(\.\|[EMAIL 
>PROTECTED]).*//'`.UTF-8
>eval export ${name}
>else
>LC_CTYPE=en_US.UTF-8
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#146210: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146210

[Thomas Dickey]

>   Debian Bug report logs - #146210
> xterm: resize race condition

Based on the information here, I looked up the change.  Here's the
corresponding comment from my rcs log:

revision 1.266
date: 2001/09/20 00:43:41;  author: tom;  state: Exp;  lines: +0 -2
remove USE_HANDSHAKE ifdef from the second chunk of ioctl(TIOCSSIZE), since
PG reports that on Solaris 2.6, apparently the first chunk is too early to
affect the pty's screen size.

If there's someone actually working on ion (not making faq's about things
that he didn't want to waste time by sending a bug-report), perhaps we can
chat and come to some agreement.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#39964: The xterm bug

[Thomas Dickey]

On Sat, Mar 08, 2003 at 03:03:25PM -0500, Branden Robinson wrote:
> On Sat, Mar 08, 2003 at 12:25:25AM +0100, Per Olofsson wrote:
> > According to the Ion [0]FAQ and [1]Wiki this is a bug in xterm, not
> > Ion. I am therefore reassigning it to xterm and merging it with bug
> > #39964 which I think is the same problem. I have verified that this
> > bug still exists in xterm 4.2.1-6. See the links below for more
> > information.
> > 
> > [0] http://modeemi.cs.tut.fi/~tuomov/ion/faq.htm
> 
> This link is a 404, BTW.
> 
> > [1] http://wiki.ael.be/ion/index.php/FrequentlyAskedQuestions
> 
> Okay, I see.  I'll apply this patch since Debian doesn't care about
> Solaris 2.6.  :)

...and I've a to-do item to determine a better fix.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#190939: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190939

[Thomas Dickey]

>   Debian Bug report logs - #190939
>broken colors in xterm

I don't see a point in changing this: the colors as given in the report do
match the ones I used for xterm, but do not (except accidentally) match those
in the console.  I installed a copy of Debian 3.0r1 last week, and like the
choice for the blue color.  The drawback to using it in the upstream package
is that the name isn't standard across all X versions.  (I chose the colors
several years ago based on running in a white-background screen, limiting
the choice to colors in both X11R5 & X11R6 rgb.txt files - should have used
an rgb constant, but that would have been an issue with the locale support -
a different bug).

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#197580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197580

[Thomas Dickey]

>   Debian Bug report logs - #197580
>  xterm: not able to start uxterm (xterm -class UXTerm) ; just hangs

A quick check on my system running Debian 3.0r1 doesn't show a problem.
I did
xterm -class UXTerm
and got a workable terminal.  (Also, from uxterm, I did the same).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: X Strike Force SVN commit: rev 248 - in trunk/debian: . patches

[Thomas Dickey]

In article <[EMAIL PROTECTED]> you wrote:
> Author: branden
> Date: 2003-06-26 13:01:11 -0500 (Thu, 26 Jun 2003)
> New Revision: 248

> Added:
>trunk/debian/patches/093_SECURITY_xterm_window_title_reporting_fix.diff
>trunk/debian/patches/094_SECURITY_xterm_DEC_UDK_sequence_DoS_fix.diff
> Modified:
>trunk/debian/changelog
> Log:
> add two security patches to xterm

> debian/patches/093_SECURITY_xterm_window_title_reporting_fix.diff:
>   SECURITY: disable window title reporting to work around potentially
>   malicious text being spewed to terminal window
>   

For #177, I assume you did see the allowWindowOps resource.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#167495: marked as done (xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources)

[Thomas Dickey]

In article <[EMAIL PROTECTED]> you wrote:

the problem that he cited was that Debian's package sets the classnames
which would tend to interfere with the user's ability to set the resources.

> On Sat, Nov 02, 2002 at 10:19:20PM +0100, Vincent Lefevre wrote:
>> /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary
>> resources, like how the scrollbar looks like, as the user can't
>> always override them.

> You are mistaken.  The user can always override them with X resource
> settings.

> XTerm*autoWrap:   true
> XTerm*curses: true
> XTerm*loginShell: true
> XTerm*reverseWrap:true
> XTerm*scrollBar:  true
> XTerm*saveLines:  5000
> XTerm*scrollTtyOutput:false
> XTerm*trimSelection:  true
> XTerm*visualBell: true
> XTerm*activeIcon: true
> XTerm.VT100.background:   gray30
> XTerm.VT100.foreground:   gray90
> XTerm.VT100.geometry: 200x55-0+20
> XTerm.VT100.color4: DodgerBlue1
> XTerm.VT100.color8: gray50
> XTerm.VT100.color12: SteelBlue1
> XTerm.VT100.scrollbar.background: white
> XTerm.VT100.scrollbar.foreground: blue

> --=20
> G. Branden Robinson|You can have my PGP passphrase when
> Debian GNU/Linux   |you pry it from my cold, dead
> [EMAIL PROTECTED] |brain.
> http://people.debian.org/~branden/ |-- Adam Thornton

> --KFztAG8eRSV9hGtP
> Content-Type: application/pgp-signature
> Content-Disposition: inline

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.1 (GNU/Linux)

> iEYEARECAAYFAj3Fi4MACgkQ6kxmHytGonyU7gCeJpX2VpF0SvQ0hkWlZLSIrvtr
> gSMAnAqemcYvif2jZHXepQPWibqaJUbM
> =WgVJ
> -END PGP SIGNATURE-

> --KFztAG8eRSV9hGtP--


> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com

Bug#179846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179846

[Thomas Dickey]

>   Debian Bug report logs - #179846
> xterm: not documented that xterm squelches ${TMPDIR}

xterm doesn't; it is a feature of the system to remove various environment
variables.

>I myself will probably look into the sources to see whether xterm is deleting
>any other envariables.  They should be listed in the documentation for everyone
>to notice.

I assume he's going to document it - if/when he reads the code -
but it doesn't belong in xterm's manpage.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#37517: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37517

[Thomas Dickey]

>Debian Bug report logs - #37517
>  xterm: binary files can cause xterm to hang and dump into the printer queue
>  with printerCommand

this one should be closed, since it was addressed in patch #167.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#179929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179929

[Thomas Dickey]

>   Debian Bug report logs - #179929
>   xterm: uxterm's regexp doesn't catch modifiers in locale settings

the attached script is incorrect (i.e., is specific to GNU sed),
I'll have a workable version in patch #175.

>--- uxterm.orig 2003-02-05 10:40:04.0 +0100
>+++ uxterm  2003-02-05 18:43:52.0 +0100
>@@ -30,7 +30,7 @@
> # user's shell does not reset unknown locale specifiers, but not all shells do
>.
> if test $found != yes ; then
>if test -n "$value" ; then
>-   eval ${name}=`echo ${value} |sed -e 's/\..*//'`.UTF-8
>+   eval ${name}=`echo ${value} |sed -e 's/\(\.\|[EMAIL 
>PROTECTED]).*//'`.UTF-8
>eval export ${name}
>else
>LC_CTYPE=en_US.UTF-8
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#146210: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146210

[Thomas Dickey]

>   Debian Bug report logs - #146210
> xterm: resize race condition

Based on the information here, I looked up the change.  Here's the
corresponding comment from my rcs log:

revision 1.266
date: 2001/09/20 00:43:41;  author: tom;  state: Exp;  lines: +0 -2
remove USE_HANDSHAKE ifdef from the second chunk of ioctl(TIOCSSIZE), since
PG reports that on Solaris 2.6, apparently the first chunk is too early to
affect the pty's screen size.

If there's someone actually working on ion (not making faq's about things
that he didn't want to waste time by sending a bug-report), perhaps we can
chat and come to some agreement.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#39964: The xterm bug

[Thomas Dickey]

On Sat, Mar 08, 2003 at 03:03:25PM -0500, Branden Robinson wrote:
> On Sat, Mar 08, 2003 at 12:25:25AM +0100, Per Olofsson wrote:
> > According to the Ion [0]FAQ and [1]Wiki this is a bug in xterm, not
> > Ion. I am therefore reassigning it to xterm and merging it with bug
> > #39964 which I think is the same problem. I have verified that this
> > bug still exists in xterm 4.2.1-6. See the links below for more
> > information.
> > 
> > [0] http://modeemi.cs.tut.fi/~tuomov/ion/faq.htm
> 
> This link is a 404, BTW.
> 
> > [1] http://wiki.ael.be/ion/index.php/FrequentlyAskedQuestions
> 
> Okay, I see.  I'll apply this patch since Debian doesn't care about
> Solaris 2.6.  :)

...and I've a to-do item to determine a better fix.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#189956: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189956

[Thomas Dickey]

>   Debian Bug report logs - #189956
>xterm: Non-ASCII chars omitted in window title
...
>-- System Information
>Debian Release: testing/unstable
>Architecture: i386
>Kernel: Linux glaux 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

something is missing from the report:  window title is set with an ISO-8859-1
string.  In a UTF-8 locale, echo will use UTF-8, which does not give the
expected behavior.  vim (and other applications) take this into account.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#190939: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190939

[Thomas Dickey]

>   Debian Bug report logs - #190939
>broken colors in xterm

I don't see a point in changing this: the colors as given in the report do
match the ones I used for xterm, but do not (except accidentally) match those
in the console.  I installed a copy of Debian 3.0r1 last week, and like the
choice for the blue color.  The drawback to using it in the upstream package
is that the name isn't standard across all X versions.  (I chose the colors
several years ago based on running in a white-background screen, limiting
the choice to colors in both X11R5 & X11R6 rgb.txt files - should have used
an rgb constant, but that would have been an issue with the locale support -
a different bug).

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#197580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197580

[Thomas Dickey]

>   Debian Bug report logs - #197580
>  xterm: not able to start uxterm (xterm -class UXTerm) ; just hangs

A quick check on my system running Debian 3.0r1 doesn't show a problem.
I did
xterm -class UXTerm
and got a workable terminal.  (Also, from uxterm, I did the same).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Re: X Strike Force SVN commit: rev 248 - in trunk/debian: . patches

[Thomas Dickey]

In article <[EMAIL PROTECTED]> you wrote:
> Author: branden
> Date: 2003-06-26 13:01:11 -0500 (Thu, 26 Jun 2003)
> New Revision: 248

> Added:
>trunk/debian/patches/093_SECURITY_xterm_window_title_reporting_fix.diff
>trunk/debian/patches/094_SECURITY_xterm_DEC_UDK_sequence_DoS_fix.diff
> Modified:
>trunk/debian/changelog
> Log:
> add two security patches to xterm

> debian/patches/093_SECURITY_xterm_window_title_reporting_fix.diff:
>   SECURITY: disable window title reporting to work around potentially
>   malicious text being spewed to terminal window
>   

For #177, I assume you did see the allowWindowOps resource.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com

Bug#200857: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200857

[Thomas Dickey]

>   Debian Bug report logs - #200857
> xterm fails to honour dtterm sequence ESC[21t
...

>I think it might be better to do something like this [see patch]:
>The iscntrl() test can be replaced easily if more/less paranoia is
>required - it's not really fair to expect apps to figure out the
>escape sequence is just gone, as afaict there's no way to ask if
>a term supports many of them other than checking TERM and going by
>what you know/expect that terminal to support.

not exactly - the label doesn't have control characters - see this chunk
in misc.c:

default:
if (ansi_table[CharOf(*cp)] != CASE_PRINT)
return;
}

The complaint is that someone could be misled into pressing return after
a bogus title was sent to the host, e.g., as part of cat'ing a core-dump
to the terminal.  (Why anyone would want to do this is another story).
Or doing tail -f on a so-called logfile (no different ;-).

This is in patch #174 (would allow someone to use these features if they're
inclined to read the manpage):

   allowWindowOps (class AllowWindowOps)
   Specifies   whether   extended   windowcontrol
   sequences  (as  used  in  dtterm)  for  should  be
   allowed.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#200857: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200857

[Thomas Dickey]

>   Debian Bug report logs - #200857
> xterm fails to honour dtterm sequence ESC[21t
...
>   allowWindowOps (class AllowWindowOps)
>   Specifies   whether   extended   windowcontrol
>   sequences  (as  used  in  dtterm)  for  should  be
>   allowed.
...
>From: Vivek <[EMAIL PROTECTED]>
...
>Ok then: assuming this defaults/will default to "false", there's no
>real need to stomp on the sequence handling completely, then, right?

That's my viewpoint - if Brendan adds a "false" to the system app-defaults
file, it would still allow a user to override it and get the features.

Making it return an empty string would be incorrect behavior - if it's
not implemented, it should be parsed & ignored.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#208493: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208493

[Thomas Dickey]

On Wed, Sep 03, 2003 at 04:17:41PM -0500, Branden Robinson wrote:
> tag 208493 + wontfix
> thanks
> 
> On Wed, Sep 03, 2003 at 03:55:56PM -0400, [EMAIL PROTECTED] wrote:
> >Debian Bug report logs - #208493
> > > xterm: openi18n patch
> > I'm afraid that I don't regard that as "clean".  The reverse.
> 
> Tagging this bug as "wontfix" pending further discussion, then.  I do
> not want to fork from Mr. Dickey's xterm too badly.

There's a lot of discussion that could be made - the patch is based on X11R6.1
xterm.  So one would have to study it to see how to add whatever features it
provides that XFree86 xterm does not.  I reviewed it last year, found that it
added bugs that I could demonstrate with vttest.  (And rather than fix some of
the problems that I noticed with X11R6.3 xterm, the resulting Solaris 9 xterm
has a bad memory leak in resizing).  Some of the symbol names in the patch
demonstrate to me that the patch's author was moderately familiar with XFree86
xterm.

Studying the patch itself, I noticed more than one place where it did not do
error-checking.  The documentation doesn't state _what_ it does, only that it
does something better.  Code Set Independence, as I found by reading mailing
list is not actually implemented in this patch (it's not well-defined, but from
the author's discussion, this patch cannot achieve it - he had, as I recall,
more ambitious plans which are not reflected in the patch).

This is not to say that there's nothing there - but making a good job
of it will take more work by me than was done by the patch's author.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com

Bug#205255: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205255

[Thomas Dickey]

>  Debian Bug report logs - [1]#205255
> xterm: fails on intensity specifications rgbi:

This fails because of the X11 library rather than xterm.

I considered whether it was due to delaying the lookup of colors (and possibly
using a different method), but restoring the "original" way resources were
found, there's no change (so I'm certain that it is not due to a change in
xterm).  However, I am not able to see where X11 has changed either.

Reading through Xlib I see the issue is that in de_DE locale, a "," is used for
a decimal separator rather than ".".  The XcmsLRGB_RGBi_ParseString() function
uses sscanf, which (given the locale) expects a comma.  That particular part
of the code hasn't changed since XFree86 3.3.6.  The available documentation
does not mention whether this string should be interpreted in a locale-specific
manner, only an oblique reference to its character set.

>xterm does not recognise intensity specifications like
>
>XTerm*VT100*color1:  rgbi:0.4/0.0/0.0
>
>Error message:
>
> xterm: Cannot allocate color rgbi:0.4/0.0/0.0
>
>It did definitively work in earlier versions.

more information about the earlier versions would be helpful, but in any
case this bug is not related to xterm.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#205255: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205255

[Thomas Dickey]

On Fri, 19 Sep 2003, Branden Robinson wrote:

> reassign 205255 xlibs
> retitle 205255 xlibs: [libX11] XcmsLRGB_RGBi_ParseString() uses sscanf() to 
> parse floats but is not locale-aware
> tag 205255 = upstream
> severity 205255 normal
> thanks
>
> Thanks for your analysis, Thomas.

no problem

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Bug#198910: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198910

[Thomas Dickey]

>  Debian Bug report logs - [1]#198910
>   xterm(1) confuses ampersand and @ symbol

I just committed a fix for this in XFree86 CVS.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#10445: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10445

[Thomas Dickey]

>  Debian Bug report logs - [1]#10445
> xterm: using -e with -ls fails to open a login shell

This should be closed since the documentation fixes requested were made.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#178812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178812

[Thomas Dickey]

>   Debian Bug report logs - #178812
> xterm: resource-based keybindings don't work when mouse cursor over scrollbar

Perhaps more information would help (such as a copy of whatever customization
he was making to test this with).  There aren't any xterm-specific default
resource settings that map the keystrokes to scrollbar actions.  (This applies
to XFree86 xterm and X11R5, X11R6 xterms).  The scrollbar, by the way, happens
to be a child of the widget that displays text.  So keystrokes that are not
handled by the scrollbar end up being processed by the text (VT100) widget.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#178812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178812

[Thomas Dickey]

>   Debian Bug report logs - #178812
> xterm: resource-based keybindings don't work when mouse cursor over scrollbar

never mind - I found a nicer solution which will be in patch #181
(see patch #158 for reference).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#179407: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179407

[Thomas Dickey]

>   Debian Bug report logs - #179407
>  xterm: bold fonts do not work with widechars (and consequently utf-8 mode)

I believe this is fixed in xterm patch #180 (last week).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215828: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215828

[Thomas Dickey]

>   Debian Bug report logs - #215828
> xterm: pixel garbage in line-drawing characters in UTF-8 mode

I see the dots in the attached picture, however I don't see an indication
of which font was used.  That sort of thing could happen if the bounding
box of the font isn't consistent with the ascent/descent values (a defective
font, in other words - there are several in XFree86).  But knowing the font
I could verify this.

>I'm using various sizes of the fixed font, with mutt-utf8, with

The ISO8859 fixed font, or the ISO10646 font?
(or even Freetype fonts ;-)
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#107769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107769

[Thomas Dickey]

>   Debian Bug report logs - #107769
> xterm: bold font selection and redraw problem

revisiting this - perhaps there is a problem, but the report doesn't
show it.  (I suggest it be cancelled).

>The following font aliases exist in the xfonts-base package:
>
>  8x13 -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1
>  7x14bold -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1
>  8x13bold -misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-1
>
>When using the 8x13 font, the bold font selection is done with the
>following pattern (I compiled xterm with --enable-trace):
>
>  -misc-fixed-medium-r-normal--13-120-75-75-c-*-iso8859-1
>
>which matches 7x14bold.  This looks fairly awful, and has some issues
>with redraws.

no, it matches 8x13bold.  Here's what fonts.alias shows:

7x14 -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1
7x14bold -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1
8x13 -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1
8x13bold -misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-1
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#178812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178812

[Thomas Dickey]

>   Debian Bug report logs - #178812
> xterm: resource-based keybindings don't work when mouse cursor over scrollbar

I made a fix for this in patch #181.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#179407: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179407

[Thomas Dickey]

>   Debian Bug report logs - #179407
>  xterm: bold fonts do not work with widechars (and consequently utf-8 mode)

I believe this is fixed in patch #181.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#198910: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198910

[Thomas Dickey]

>   Debian Bug report logs - #198910
>  xterm: manpage confuses ampersand (&) and commercial at (@) symbols
lost in the spam, I did complete this one (it was in patch #180).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#189764: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189764

[Thomas Dickey]

>   Debian Bug report logs - #189764
> xterm: terminfo documents shifted keypad confusingly

I believe I addressed all of the points in this report in patch #178:

   Patch #178 - 2003/5/18 - XFree86 4.3.99.5

 * correct  comment  in terminfo file regarding modifier used for kDC
   (Debian #189764, report by Henning Makholm).
 * correct/extend  some  of  the  keypad  description  in  ctlseqs.ms
   (report by Henning Makholm).
 * correct  keypad-mapping  table  in  input.c  so  XK_KP_Equal works
   (report by Henning Makholm <[EMAIL PROTECTED]>).
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#212581: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=212581

[Thomas Dickey]

>   Debian Bug report logs - #212581
>emacs21: emacs -nw: display problem with (column-number-mode 1)

I'm reading this one as cannot-reproduce-effect (can we close it, or are
we awaiting some further action?)
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215647

[Thomas Dickey]

>   Debian Bug report logs - #215647
>  xterm: change the encoding according to the current LC_CTYPE locale

I made some changes in patch #181 which would make this simpler to
incorporate.  No font changes are needed, only this line is relevant
now:

*VT100*locale: true

I'm not sure offhand of the impact on Debian to incorporate that (will have
to think about it).  It wouldn't work for upstream since the conditions it
assumes are not true of all platforms.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#107769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107769

[Thomas Dickey]

On Tue, 28 Oct 2003, Brendan O'Dea wrote:

> Here's what matches the pattern generated by bold_font_name() on my
> system when 8x13 is given:
>
>   $ xlsfonts -fn '-misc-fixed-bold-r-normal--13-120-75-75-c-*-iso8859-1'
>   -misc-fixed-bold-r-normal--13-120-75-75-c-0-iso8859-1
>   -misc-fixed-bold-r-normal--13-120-75-75-c-0-iso8859-1
>   -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-1
>   -misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-1
>
> I'm not sure what the first two matches are (derived scalable fonts?)
> although the two following entries match 7x13bold (average width 70) and
> 8x13bold (80).
>
> The effect is as described, specifying only "-fn 8x13" is equivalent to
> "-fn 8x13 -fb 7x13bold".

ok - I guess the problem is that I'm passing an "*" in the column where
70/75/80 appear, and font server is giving me 75 rather than the 80
that would be more correct:

xtermLoadFont normal 8x13
...derived bold -Misc-Fixed-bold-R-Normal--13-120-75-75-C-*-ISO8859-1
same_font_size height 13/13, min 8/7 max 8/7
...got a matching bold font
same_font_size height 13/13, min 8/7 max 8/7
Proportional font! normal 8/8, bold 7/7

(The "/7" parts would be "/8" if it had matched 8x13bold).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215647

[Thomas Dickey]

On Tue, 28 Oct 2003, Branden Robinson wrote:

> On Mon, Oct 27, 2003 at 05:29:55PM -0500, Thomas Dickey wrote:
> > >   Debian Bug report logs - #215647
> > >  xterm: change the encoding according to the current LC_CTYPE locale
> >
> > I made some changes in patch #181 which would make this simpler to
> > incorporate.  No font changes are needed, only this line is relevant
> > now:
> >
> > *VT100*locale: true
> >
> > I'm not sure offhand of the impact on Debian to incorporate that (will have
> > to think about it).  It wouldn't work for upstream since the conditions it
> > assumes are not true of all platforms.
>
> Can you elaborate on that?  What assumptions does it make?

setting the locale resource tends to force xterm to use luit and Unicode
fonts.  If luit's not configured into the executable it doesn't make that
much difference, I guess, but I'll have to think about this some more -
there are a number of small incompatibilities built into the resource
usage when luit is compiled-in/activated, and some unnecesary changes
of interface to luit.

at the moment I'm only interested in bug-fixes (not changing configuration
around).  As it's setup now, I think that a user can easily turn on the
locale feature and experiment with it.  (I just got some negative feedback
regarding the blue/Dodger blue resource change - have to keep things from
getting out of hand ;-)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#107769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107769

[Thomas Dickey]

On Tue, 28 Oct 2003, Branden Robinson wrote:

> On Mon, Oct 27, 2003 at 09:31:29PM -0500, Thomas Dickey wrote:
> > On Tue, 28 Oct 2003, Brendan O'Dea wrote:
> > > The effect is as described, specifying only "-fn 8x13" is equivalent to
> > > "-fn 8x13 -fb 7x13bold".
> >
> > ok - I guess the problem is that I'm passing an "*" in the column where
> > 70/75/80 appear, and font server is giving me 75 rather than the 80
> > that would be more correct:
> >
> > xtermLoadFont normal 8x13
> > ...derived bold -Misc-Fixed-bold-R-Normal--13-120-75-75-C-*-ISO8859-1
> > same_font_size height 13/13, min 8/7 max 8/7
> > ...got a matching bold font
> > same_font_size height 13/13, min 8/7 max 8/7
> > Proportional font! normal 8/8, bold 7/7
> >
> > (The "/7" parts would be "/8" if it had matched 8x13bold).
>
> Should this bug be re-opened, then?

yes - I'll be working on it this evening.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#107769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107769

[Thomas Dickey]

>   Debian Bug report logs - #107769
> xterm: bold font selection and redraw problem

I just checked in a fix for this, to XFree86 CVS.
-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215647

[Thomas Dickey]

On Wed, 29 Oct 2003, Branden Robinson wrote:

> On Tue, Oct 28, 2003 at 03:04:21PM -0500, Thomas Dickey wrote:
> > setting the locale resource tends to force xterm to use luit and Unicode
> > fonts.  If luit's not configured into the executable it doesn't make that
> > much difference, I guess, but I'll have to think about this some more -
> > there are a number of small incompatibilities built into the resource
> > usage when luit is compiled-in/activated, and some unnecesary changes
> > of interface to luit.
>
> I'll probably leave it off in Debian as well, then.

ok.  I think there's something to appease everyone right now - I'd rather
let it go as is, to see what problems arise.

> > at the moment I'm only interested in bug-fixes (not changing configuration
> > around).  As it's setup now, I think that a user can easily turn on the
> > locale feature and experiment with it.  (I just got some negative feedback
> > regarding the blue/Dodger blue resource change - have to keep things from
> > getting out of hand ;-)
>
> Yeah, people yelled at me about that too, but I stood my ground.

it would be nice if I could (somehow) make the color map adapt dynamically
to make everything get good contrast.  Even the example that I got in
feedback was still more readable than the darker blue on black.  (Bear in
mind that when I setup color resources in 1996/1997, the choice was for
names that were present in X11R5 and X11R6 rgb.txt, since I didn't trust
the numeric specifiers - and I was usually making white backgrounds).

> It might be a good idea to get rid of that Xaw7 display list stuff,
> though.  It was just an experiment on my part, and I haven't been happy
> with it.  There's no way to have the gradient's size calculated at the
> time the widget is realized, among other cosmetic problems.

yes - I did notice that, but since it didn't break it badly enough to make
it unreadable, I just put up with it.  It did puzzle me what was going on
until I looked at the resources.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#215647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215647

[Thomas Dickey]

On Thu, 30 Oct 2003, Branden Robinson wrote:

> On Wed, Oct 29, 2003 at 03:19:17PM -0500, Thomas Dickey wrote:
> > > > at the moment I'm only interested in bug-fixes (not changing configuration
> > > > around).  As it's setup now, I think that a user can easily turn on the
> > > > locale feature and experiment with it.  (I just got some negative feedback
> > > > regarding the blue/Dodger blue resource change - have to keep things from
> > > > getting out of hand ;-)
> > >
> > > Yeah, people yelled at me about that too, but I stood my ground.
> >
> > it would be nice if I could (somehow) make the color map adapt dynamically
> > to make everything get good contrast.  Even the example that I got in
> > feedback was still more readable than the darker blue on black.  (Bear in
> > mind that when I setup color resources in 1996/1997, the choice was for
> > names that were present in X11R5 and X11R6 rgb.txt, since I didn't trust
> > the numeric specifiers - and I was usually making white backgrounds).
>
> I don't know much about colorspace stuff, but I wonder if the text color
> values could be converted to HVC (Hue/Value/Chroma) internally, compared
> to the HVC value of the background, a useful adjustment made in that
> space, and the text colors remapped.
>
> I am wondering if it is this simple:

It might be.  When I added the code to (attempt to) keep the cursor color
distinct from the background, I didn't notice anything that I could have
used.  But revisiting it, might see something to exploit.  Anyway, right
now my changes to xterm til XFree86 4.4 is out will be only essential
fixes...

> The background color is likely to have a V of close to 0 or close to 1.
> (Most people have either very light or very dark backgrounds.)
>
> For each text color,
>   If background V is close to 0:
>   If text color V is < 0.5, set it to 1.0 - V.
>   If text color V is > 0.5, leave it alone.
>   If background V is close to 1:
>   If text color V is < 0.5, leave it alone.
>   If text color V is > 0.5, set it to 1.0 - V.
>
> A computer graphics professional, or anyone who actually understands
> colorspaces, should be able to see any awful flaws in this immediately.

;-)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#178812: [dickey@his.com: Bug#178812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178812]

[Thomas Dickey]

On Sat, 1 Nov 2003, Anders Hammarquist wrote:

> In a message of Sat, 01 Nov 2003 10:56:24 EST, Thomas Dickey writes:
> >I think I did fix this last week.  The part that confuses me is "anymore".
> >See my comment about xtermAddInput() in
> > http://invisible-island.net/xterm/xterm.log.html#xterm_181
>
> Strange. I know it stopped working at some point; IIRC at the same time
> as xterm got colour support. It definitely works in the xterm distributed
> with Solaris (2.)8, which, if memory serves, is X11R6.1 (just tested it
> there).

As I said, I'm confused.  Last week I tested the X11R5 and X11R6 xterm's
that I have on my Linux box for comparison - neither of those handles
the keyboard translations in the scrollbar.  So I think it's not simply
xterm that changed.  (I recall looking at Sun's app-defaults file for
xterm and not seeing any reason for a difference there - but it's been
a while).  If it were working in the X11R6 code, I'd spend the time to
see if one of my changes broke this, but it doesn't seem to be the case.

The fix I made was to apply the vt100 widget's default translations to
the scrollbar.  In patch #158, I had added just the ones that I thought
would be useful (and since the vt100 widget has a lot of translations)
limited to avoid conflicts.  Since the scrollbars seem to work with the
full set of translations, I think it's fixed now.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#178812: [dickey@his.com: Bug#178812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178812]

[Thomas Dickey]

On Sat, 1 Nov 2003, Anders Hammarquist wrote:

> Except that they don't, anymore. When the mouse cursor is over the scrollbar
> hitting Shift-Prior sends the escape sequence bound, rather than scrolling.
> If the mouse cursor is outside the scrollbar, it works as expected. The
> other bindings behave similarly.

I think I did fix this last week.  The part that confuses me is "anymore".
See my comment about xtermAddInput() in
http://invisible-island.net/xterm/xterm.log.html#xterm_181

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#277832: still not fixed...

[Thomas Dickey]

On Tue, Jan 11, 2005 at 11:30:20AM +0100, Branden Robinson wrote:
> On Fri, Dec 31, 2004 at 01:06:36PM +0100, Vincent Lefevre wrote:
> > On 2004-12-31 04:34:13 -0500, Branden Robinson wrote:
> > > Well, let's call this bug what it is, then.
> > 
> > Note that gnome-terminal isn't the only application that keeps the
> > primary selection when it is no longer highlighted. Mozilla, Opera
> > and Emacs all have the same behavior.
> > 
> > And I don't think this is a wishlist since there's a big and
> > unacceptable inconsistency: xterm throws the primary selection,
> > but doesn't clear the cut buffer. This leads to confusion, and
> > possible data corruption (for this reason, I would see it as an
> > important bug at least).
> 
> I still want to hear what Thomas Dickey as to say about this.  I'm also not
> sure the semantics of selections vs. cut buffers are as you describe.

The description above doesn't look right (perhaps I'm not reading it as it
was intended).  It appears to state that if xterm processes the primary
selection, it will ignore the cutbuffers.  I don't see that in the code
(cannot test right now).  If there's a bug in that, Vincent should write
a different bug report.

The default translations process both primary and cut-buffer 0.
I added an example in the manpage showing how to override that to
use the clipboard and cut-buffer 1 when using the shifted mouse clicks.

Because most users have been accustomed to the default translations,
it wouldn't make much sense to change those.  Perhaps that's what
Vincent is talking about.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgppiuMbJsGsD.pgp
Description: PGP signature

Bug#277832: still not fixed...

[Thomas Dickey]

On Tue, Jan 11, 2005 at 02:00:08PM +0100, Vincent Lefevre wrote:
> On 2005-01-11 05:15:09 -0500, Branden Robinson wrote:
> > I still want to hear what Thomas Dickey as to say about this. I'm
> > also not sure the semantics of selections vs. cut buffers are as you
> > describe.
> 
> I don't think the end user should be exposed to differences between
> implementations (e.g. primary selection vs cut buffer), at least with
> a default configuration.

Then that's a separate issue.

I already have a to-do item to modify xterm to be able to supply the primary
selection independent of the highlighting.  Let's not combine all of the
diverse issues into one bug report.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp06YNrZgl9D.pgp
Description: PGP signature

Bug#286068: #286068 - xterm "iconFont" and faceName

[Thomas Dickey]

This is fixed in patch #198.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#291787: xterm: selection is cleared by scrolling

[Thomas Dickey]

On Sun, Jan 23, 2005 at 07:40:08AM +0100, Andrew Pimlott wrote:
> Package: xterm
> Version: 4.1.0-16woody5
> Severity: normal
> 
> First, I want to say I couldn't be more pleased by the recent effort
> (bug 277832) to improve selection handling.  The new behavior is
> generally quite pleasant.  However, there appears to be a significant
> regression.  Any time the terminal scrolls (by which I mean, a newline
> is received when the cursor is at the bottom, not scrolling of the view
> with shift-pgup), the selection is cleared.  To reproduce:

hmm - that's right.  It's unintended behavior (will fix).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpqFkBKvQXws.pgp
Description: PGP signature

Bug#291115: #291115 xterm has locale problem

[Thomas Dickey]

This is a duplicate of #279252

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#289381: #289381 - xterm: [uxterm] Does not start if locale is not generated

[Thomas Dickey]

#279252 addresses the last point (this one should be merged with it).

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#294878: reproduce?

[Thomas Dickey]

On Sat, Feb 12, 2005 at 09:30:13AM +0100, Justin Pryzby wrote:
> I just compiled xterm, version "XFree86 4.2.99.903(174)" and can't
> reproduce it with that.
> 
> The version that crashes is "XTerm(197)".
> 
> The me-compiled version is not stripped.
> 
> Instead of crashing, the me-compiled version DOES pop up an TEK
> window.

that sounds like what I fixed in #198:

fix bugs in patch #191 and in SRM changes from patch #197 that broke
DECSET 38: switch to Tek4014 emulation (report by Dave Bodenstab).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpCUKHt1qAOl.pgp
Description: PGP signature

Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1

[Thomas Dickey]

This is the same as #229566

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpO2jx4CkWE8.pgp
Description: PGP signature

Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1

[Thomas Dickey]

On Tue, Mar 08, 2005 at 03:46:56PM +, Jochen Voss wrote:
> Hello Thomas,
> 
> On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote:
> > thanks.  Actually I had forgotten the TCSETA detail, but noticed the
> > hardware platform which seems to be relevant as well.
> Is the TCSETA ioctl documented in some publicly accessible place?

For instance Solaris' termio manpage says this:

 TCSETA
   The argument is a  pointer  to  a   termio  structure.
   Those terminal parameters that can be stored in a ter-
   mio structure are set from the values stored  in  that
   structure. The change is immediate.

Changing it to TCSETAF might change the behavior (mentioning this not to fix
the problem, but to get more information about it).

 TCSETAF
   The argument is a pointer to a termio structure.
Those terminal parameters that can  be  stored  in  a
   termio  structure  are  set  from the values stored in
   that structure. The change occurs after all characters
   queued  for  output have been transmitted; all charac-
   ters queued for  input  are  discarded  and  then  the
   change occurs.

I have a hunch that TCSETAF is used in more applications, so a bug in
the former might be overlooked.

> Maybe its a kernel or libc bug after all?

I suspect that, but don't have an easy way to prove it.  There are a couple of
things that are related:

Some time ago there were comments to the effect that the PowerPC port had
changed some of the I/O structs incompatibly, causing some isolated failures. 
I mentioned that to Brandon when this bug came up, but his opinion was that
those problems had been dealt with.

The other is whether the connection is remote or local (I don't have the other
report at hand, but seem to recall that this problem happens on local
connections).
 
> All the best,
> Jochen
> 
> 
> PS.: I was unsure which bug report entry I should forward this
> information to.  I choose "my" copy of the bug report.  Hope that this
> is ok.

that's fine (Brandon may merge them as he needs to).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp7MsAN3itYQ.pgp
Description: PGP signature

Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1

[Thomas Dickey]

On Sat, Mar 12, 2005 at 03:42:33PM +, Jochen Voss wrote:
> Hello Thomas,
> 
> On Tue, Mar 08, 2005 at 11:06:03AM -0500, Thomas Dickey wrote:
> > On Tue, Mar 08, 2005 at 03:46:56PM +, Jochen Voss wrote:
> > > Hello Thomas,
> > > 
> > > On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote:
> > > > thanks.  Actually I had forgotten the TCSETA detail, but noticed the
> > > > hardware platform which seems to be relevant as well.
> > > Is the TCSETA ioctl documented in some publicly accessible place?
> > 
> > For instance Solaris' termio manpage says this:
> > 
> >  TCSETA
> >The argument is a  pointer  to  a   termio  structure.
> >Those terminal parameters that can be stored in a ter-
> >mio structure are set from the values stored  in  that
> >structure. The change is immediate.
> And do you know what it means to set the CS7 flag in c_cflags?

The 8th bit can be ignored in that case.  By itself, that doesn't make it
zero.  Checking the termio manpage on Solaris (which is more complete than
Linux's), we see

 If  ISTRIP is set, valid input characters are first stripped
 to seven bits, otherwise all eight bits are processed.

> The libc manual just sais "This specifies seven bits per byte",
> which sounds like it should never be set on todays hardware?
> Maybe the call is perfectly right to return an error code for
> this setting?

Not exactly:  it is redundant for xterm to set it in this case, but since the
header files define it, it should be supported by the terminal driver (which is
independent of the hardware).

It's been a while since I noticed, but it used to be the case that 8-bit paths
for telnet weren't guaranteed.  For instance SunOS 4.x's telnet didn't do that.

However, that's not the reason why I didn't change it.   It was because the
single resource setting eightBitInput does two functions (adding an ESC versus
mapping meta+key to 128+key), so changing the CS7/CS8 setting wouldn't have
affected the result.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpFAwTehSo5f.pgp
Description: PGP signature

Bug#299439: xterm: Request for underline cursor.

[Thomas Dickey]

On Mon, Mar 14, 2005 at 05:30:12AM +0100, Mariano Alvira wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-10
> Severity: wishlist
> Tags: patch
> 
> 
> I'd like an option for xterm to use a underline cursor instead of the
> block.
> 
> The attached patch is included as proof-of-concept and is not intended
> for actual use.

I understand that.  Someone asked about this a while back, and I seem to
recall that it also requires (besides the simple change to charproc.c)
some tinking in util.c (which didn't look as simple).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpaSxVWoRzj7.pgp
Description: PGP signature

Bug#299669: xterm: select alternative font at startup

[Thomas Dickey]

On Tue, Mar 15, 2005 at 08:40:12PM +0100, Carlos wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-12.0.1
> Severity: wishlist
> 
> I want to select an alternative font at startup. Now I have to do
> Shift-KP_Add twice every time I open an xterm or uxterm. I would want one of
> these (or similar):
> 
> xterm -xrm '*vt100*defaultFont: 5'
> or  xterm -xrm '*vt100*initialFont: 5'
> or  xterm --send-event 'set-vt-font(5)'

But you can certainly modify your personal resource file to do this.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgptXjsoKD8si.pgp
Description: PGP signature

Bug#299439: xterm: Request for underline cursor.

[Thomas Dickey]

On Tue, Mar 15, 2005 at 08:20:10PM +0100, Mariano Alvira wrote:
 
> One thing that would also change is xtermSetCursorBox in fontutils.c,
> right now it still draws the hollow block around the underline and
> looks a little strange when I lose focus. Not too sure what to make it
> though, maybe a vertical bar?

I think this one is what I had in mind.

Perhaps it should simply draw the same empty box that the normal cursor does
when it loses focus.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpSDMZvSZ66O.pgp
Description: PGP signature

Bug#299669: xterm: select alternative font at startup

[Thomas Dickey]

On Tue, Mar 15, 2005 at 11:20:03PM +0100, Carlos wrote:
> [Thomas Dickey <[EMAIL PROTECTED]>, 2005-03-15 21.26 CET]
> > On Tue, Mar 15, 2005 at 08:40:12PM +0100, Carlos wrote:
> > > Package: xterm
> > > Version: 4.3.0.dfsg.1-12.0.1
> > > Severity: wishlist
> > > 
> > > I want to select an alternative font at startup. Now I have to do
> > > Shift-KP_Add twice every time I open an xterm or uxterm. I would want one 
> > > of
> > > these (or similar):
> > > 
> > > xterm -xrm '*vt100*defaultFont: 5'
> > > or  xterm -xrm '*vt100*initialFont: 5'
> > > or  xterm --send-event 'set-vt-font(5)'
> > 
> > But you can certainly modify your personal resource file to do this.
> 
> Yes, I can change *vt100*font and *vt100*font2-6. But can't specify, without
> changing them, which one to use at startup. (Or do I? I found nothing in the
> docs.)
> 
> (Note that the resource strings mentioned in my original message, or the
> parameter, don't exist.)

I understood that, but did not focus on the 'initialFont' part, since
xterm's default font is one of 6 fonts it has available.  On startup,
xterm -xrm '*VT100.font:9x15'
specifies the default font, which is the initial font.  A little script
starting with
appres XTerm |fgrep '*VT100*font'
would retrieve the font settings for the various font resources.
 
> There is a feature, the resource string "*tex4014*initialFont", which
> (according to the documentation) does what I want, but to some mysterious
> 'Tektronix window'. I would like to have the same feature in the VT100
> window.

I see now (I suppose something like that could be added for the VT100 widget).
 
> Thanks for your attention.

no problem

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpwkmzPqpEIq.pgp
Description: PGP signature

Bug#299439: xterm: Request for underline cursor.

[Thomas Dickey]

On Tue, Mar 15, 2005 at 10:40:12PM +0100, Mariano Alvira wrote:
 
> Yeah, I'm using that right now and it looks fine, except, I think a
> HideCursor needs to be added somewhere b/c I get a box _and_ a
> underline when I loose focus.

But unselectwindow() is calling ShowCursor/HideCursor as needed.  I think that
it's just necessary to refine the drawing of the cursor via ShowCursor -
perhaps some tinkering in drawXtermText is needed.
 
> For normal and below font sizes the box overwrites the underline and
> looks fine, but for large and above the underline is inside the box.

I had the impression (from before) that some modification would be
needed in drawXtermText - these comments sound as if they're in that
area.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpxY86jLXcpW.pgp
Description: PGP signature

Bug#300123: xterm: alt-. gives wrong signal to zsh

[Thomas Dickey]

On Thu, Mar 17, 2005 at 09:00:16PM +0100, Nick Croft wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-8
> Severity: important

this is a repeat of #280118, noting that none of the requested information
under that report was provided.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpu4jpQxKwPC.pgp
Description: PGP signature

Bug#305540: xterm: compile with --enable-256-color

[Thomas Dickey]

On Wed, Apr 20, 2005 at 07:00:13PM +0200, Miernik wrote:
> If there is a reason not to do it, could another package be provided
> with xterm with 236 color enabled, or can someone recommend another
> terminal emulatr which can do this?

I don't know of any reason why it wouldn't work.  However, that increases
the memory used for each cell (including the scrollback).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpe7HsJnA5v3.pgp
Description: PGP signature

Bug#305723: xterm: Odd behavior in Ctrl-click menu invocation

[Thomas Dickey]

On Thu, Apr 21, 2005 at 09:00:12PM +0200, Benjamin A. Okopnik wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-12.0.1
> Severity: normal
> 
> 
> This is actually a long-standing bug (several years, at least) that I'm
> just now reporting... I guess I'm getting more picky as time goes on. :)

The text of this report sounds like

http://invisible-island.net/xterm/xterm.faq.html#tiny_menus

which is not a bug (in xterm, that is).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp34I8rcGZnv.pgp
Description: PGP signature

Bug#305849: xterm: Xterm sends broken Ctrl-Left/Right/Up/Down sequences

[Thomas Dickey]

On Fri, Apr 22, 2005 at 06:53:20PM +0100, Paul Evans wrote:
> On Fri, 22 Apr 2005 13:29:35 -0400
> Thomas Dickey <[EMAIL PROTECTED]> wrote:
> 
> > Reverting xterm's configuration to the old behavior wouldn't be a bug fix.
> > The reason for changing was one of the emacs people pointed out why the
> > original encoding was not a good idea.  (We're talking about a change to
> > xterm from August 2002, btw).
> 
> Yes... I've been reading the information online about the problem. I
> see why the new behaviour is desirable... but I'm wondering if it
> justifies modifying the default behaviour which makes everything else
> break.

From what I know, there are only a handful of applications that use the
feature.
 
> > I haven't looked to see where vim's storing this information.
> > Oddly, terminfo only defines two of the four shifted arrow keys.
> > Otherwise I would have added it there (and vim would then be expected
> > to obtain it there).
> 
> Yes, I have been looking in the terminfo details, and it is indeed
> missing.
> 
> Maybe what's required is an update to terminfo itself; code-wise, to
> enable it to deal with all these settings. Are you aware of any such
> project around that would encompass that? The idea of terminfo seems
> sensible enough; keep a database of sequence => logic key mappings, and
> use a standard library to access it.

no (I maintain ncurses as well as xterm).
ncurses' terminfo can define extra data (i.e., not defined by X/Open),
but I use that feature sparingly.

Even if I were to add it to xterm's terminfo, that wouldn't help the
gnome-terminal (which has had more serious bugs against its xterm
compatibility for more than a year).
 
> Maybe if there's no real input from anywhere else, I might take a look
> at expanding libterminfo, so it could use a new database storing this
> extra info, and provide extra functions to be able to translate the
> keys properly. This would be done in a careful way so as not to break
> existing apps if the new library is installed, then one at a time, fix
> the apps to use the new library instead.
> 
> New behaviour would be to report the pair (base key, modifier); in a
> similar way to the XKeyEvents; so e.g. vim would automatically know
> it's a Control-Left, or a Shift-Meta-Home, or whatever...

ugh - that would be a lot of work (and would be never completed)
 
> It strikes me; if terminfo doesn't currently store these extra
> sequences, does Vim et al. have a hard-coded string internally to
> recognise it? How oddly broken

vim has some tables to fill in for missing/incomplete termcap entries.

 
> I make no mistake about it; I know just how massive a change this would
> be; updating the code that implements the key-reading part of _every_
> console app in existence. But what I propose will be forward-
> compatible. By the magic of dynamic libraries, existing binaries will
> work with the new library; existing code will compile against a new
> library, and existing behaviour will be unchanged. Simply, new
> functionality will be added.
> 
> Does that sound like a workable solution..?

It's not (should not be) a change to the code, but to the data stored
in initialization files.

> 
> > Most of the comments have been from people who have the literal
> > strings in their bash .inputrc file (the same for normal/application
> > mode keys).
> 
> Yeah, I have been pondering that. I can fix vim and readline this way..
> but what about irssi,  The only proper solution is to fix
> libterminfo.

irissi needs a lot of work (its problems with terminfo are relatively minor).
So I'd rather not bring it into the discussion.
 
> > As I recall it, there are two parts of the change - perhaps readline
> > is tripping over one of them (in its own changes):
> > 
> > a) the control sequence beginning could be "ESC [" (CSI) or "ESC O"
> >(SS3)
> 
> Yes; I'm noticing an odd tendency to use one or the other.. Aren't
> standards wonderful..? :)

One's the normal, and the other the application cursor key initial part.
 
> > b) the parameter could be first, e.g,. \E[2A, or after a dummy
> >parameter (to avoid confusing applications that use it as a
> >repeat count), e.g., \E[1;2A
> > 
> > Since bash is using literal strings, while vim is actually parsing the
> > escape sequences, it's also possible that vim's just doing the right
> > thing (as well as it can, given no information).
> 
> Yes; see above re: terminfo.

But if it's not in an externally-editable file (and compiled in), that's
not a good solution.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpUsDS2609i3.pgp
Description: PGP signature

Bug#305849: xterm: Xterm sends broken Ctrl-Left/Right/Up/Down sequences

[Thomas Dickey]

On Fri, Apr 22, 2005 at 04:00:19PM +0200, Paul Evans wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-12
> Severity: normal
> 
> 
> Since nearly a year ago now, Ctrl-arrow keys have not sent a control
> sequence that vim / bash / etc... can properly recognise as such.
> 
> E.g. in bash/vim, Ctrl+Left/Right is supposed to move a whole word in

"supposed to" sounds like a user configuration issue (in this case it is).

> the indicated direction. Running this from a Linux VC works, as does
> gnome-terminal. But running it in a real xterm causes bash(readline) to
> print ;5D rather than move the cursor, and causes vim all variety of
> bugs, depending on what sort of machine is running that vim. Linux's
> vim simply returns to normal mode. Solaris' vim deletes the line above
> the current one.

See xterm's manpage where it documents modifyCursorKeys.

(ignoring the misleading comment about Linux console, the
issue with gnome-terminal is that it copied xterm's behavior some
time ago and did not incorporate this particular fix).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpHu79TKmgQf.pgp
Description: PGP signature

Bug#305849: xterm: Xterm sends broken Ctrl-Left/Right/Up/Down sequences

[Thomas Dickey]

On Fri, Apr 22, 2005 at 05:20:35PM +0100, Paul Evans wrote:
> On Fri, 22 Apr 2005 11:52:24 -0400
> Thomas Dickey <[EMAIL PROTECTED]> wrote:
> 
> > "supposed to" sounds like a user configuration issue (in this case it is).
> 
> Well, I've not changed any local settings to do this. This is a
> standard stock install of debian, no customisations to xterm or vim.
> Many other people can confirm the same behaviour, both running debian,
> and other distributions (e.g. gentoo).
> 
> There may well be a configuration setting combination required to get
> this all working correctly; in which case my bug report becomes
> "standard install configuation is wrong". But either way, a bug
> persists. A default install does not behave as expected.

Reverting xterm's configuration to the old behavior wouldn't be a bug fix.
The reason for changing was one of the emacs people pointed out why the
original encoding was not a good idea.  (We're talking about a change to
xterm from August 2002, btw).

I haven't looked to see where vim's storing this information.
Oddly, terminfo only defines two of the four shifted arrow keys.
Otherwise I would have added it there (and vim would then be expected
to obtain it there).

Most of the comments have been from people who have the literal
strings in their bash .inputrc file (the same for normal/application
mode keys).

> 
> > See xterm's manpage where it documents modifyCursorKeys.
> > 
> > (ignoring the misleading comment about Linux console, the
> > issue with gnome-terminal is that it copied xterm's behavior some
> > time ago and did not incorporate this particular fix).
> 
> Right. I've looked at that, and tried each of the values 0 to 3:
> 
> 0:works in vimfails in readline
> 1:fails in vimfails in readline
> 2(default):   fails in vimfails in readline
> 3:fails in vimfails in readline
> 
> I.e. I cannot find any value that makes bash work. Each setting
> produces different output, yet none of them is correct.

As I recall it, there are two parts of the change - perhaps readline
is tripping over one of them (in its own changes):

a) the control sequence beginning could be "ESC [" (CSI) or "ESC O"
   (SS3)

b) the parameter could be first, e.g,. \E[2A, or after a dummy
   parameter (to avoid confusing applications that use it as a
   repeat count), e.g., \E[1;2A

Since bash is using literal strings, while vim is actually parsing the
escape sequences, it's also possible that vim's just doing the right
thing (as well as it can, given no information).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpdQ2yQ9mfTj.pgp
Description: PGP signature

Bug#305723: xterm: Odd behavior in Ctrl-click menu invocation

[Thomas Dickey]

On Fri, Apr 22, 2005 at 06:57:03PM -0400, Benjamin A. Okopnik wrote:
...
> The xterm that's spawned above does not have the 'tiny menu' behavior.
> However, running something like 
> 
> xterm -xrm 'XTerm*VT100*geometry: 80x24+0+21'
> 
> without flushing the xrdb cache _does_ have it. Does the stuff in xrdb
> perhaps override the '-xrm' setting in some odd way? The size of the
> terminal does change when set with '-xrm', but the 'tiny menu' behavior
> does not change unless the cache is flushed.

It could.  Just because you give an -xrm option doesn't mean that it is
going to determine the final result.  Resource values accumulate.  A
very general pattern can be easily overridden, but more specific patterns
are harder to override.  So you could for instance have some resource
conflict via xrdb.  xterm's command-line options are implemented by applying
less-general resource settings than normally appear in the app-defaults
file.  But (this is the way X resources work), those could be overridden
by an app-defaults file with specific patterns.

"*" is general
"." is specific

Normally I stay away from xrdb (it is abused by people designing desktops).
But "xrdb -query -all" is useful.  Usually "appres XTerm" is enough for me
to see where a problem lies.
 
> The problem sounds as if it may or may not be in 'xterm'... but if it
> isn't, I'm puzzled as to where else it could be.
> 
> 
> Regards,
> * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpiWR9Yx1ue1.pgp
Description: PGP signature

Bug#311066: SEGV when resizing to 1x1

[Thomas Dickey]

On Sat, May 28, 2005 at 12:30:17PM +0200, oli wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-13
> Severity: important
> 
> 
> Xterm and also uXterm dies when I resize the window to a size of 1x1
> characters. I tried this under xfce and fluxbox with the same result. As
> I do not have a version compiled with debugging symbols the only thing I 
> get from gdb is:

This sounds like a bug I fixed recently (seems to be in patch #198).  The cause
was an inconsistent limit check for the scrolling region after another
relatively recent change.  Since legal scrolling regions have to be 2 lines,
the case for a single line was special.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpk4iPem8ul4.pgp
Description: PGP signature

Re: XTerm 4.0.1b(144) segfault with ssh -v and sudo

[Thomas Dickey]

On Thu, Sep 07, 2000 at 08:25:39PM +0300, Tommi Virtanen wrote:
>   I can make xterm segfault reproducibly 
>   on Debian GNU/Linux woody (unstable).

I stumbled over one cause today (it's dependent on the keystrokes, and just
doesn't break on this host ;-).  A couple of places in the code I integrated in
#140 aren't checked if the terminal is running in UTF-8 mode before going off
and doing things.  Your traceback is one of the two.  (I'll put together a
short patch tonight - #146).
 
> [tv@hq ~/tmp/x]$ ./xterm -version
> XFree86 4.0.1b(144)
> 
>   If I start an xterm, ssh -v remotehost,
>   and run sudo there, so that sudo prompts
>   for a password, the local xterm segfaults.
>   This only happens with ssh -v, which is
>   weird, and needs a specific version of 
>   _something_ in the remote end -- a bit
>   under-updated Debian 2.2 (potato) seems
>   to cause it, the newer unstable woody 
>   doesn't.
> 
> crashes:
> sudo 1.6.2p2
> OpenSSH 1.2.3
> 
> doesn't crash:
> sudo 1.6.3p5
> OpenSSH 2.1.1p4
> 
>   Here's the end of strace
> 
> select(4, [3], [], [], {0, 0})  = 0 (Timeout)
> read(4, "Password:\0", 4096)= 10
> --- SIGSEGV (Segmentation fault) ---
> 
>   And ltrace:
> 
> memcpy(0x40302548, "Password:", 9)= 0x40302548
> memset(0x40302598, '\200', 9) = 0x40302598
> memset(0x403025e8, '\000', 9) = 0x403025e8
> memset(0x40302638, '\000', 9) = 0x40302638
> --- SIGSEGV (Segmentation fault) ---
> 
>   Here's a backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x8066076 in addXtermCombining ()
> (gdb) bt
> #0  0x8066076 in addXtermCombining ()
> #1  0x804fa3d in VTparse ()
> #2  0x8053b5e in VTRun ()
> #3  0x80697d8 in main ()
> #4  0x40225a52 in __libc_start_main () from /lib/libc.so.6
> (gdb) 
> 
>   Do tell if I can help you any more. I speak
>   C well enough and can manage my way with the
>   debugger.
> 
> -- 
> tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
> unix, linux, debian, networks, security, | Error messages
> kernel, TCP/IP, C, perl, free software,  | cannot completely convey.
> mail, www, sw devel, unix admin, hacks.  | We now know shared loss.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#167495: marked as done (xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources)

[Thomas Dickey]

In article  you wrote:

the problem that he cited was that Debian's package sets the classnames
which would tend to interfere with the user's ability to set the resources.

> On Sat, Nov 02, 2002 at 10:19:20PM +0100, Vincent Lefevre wrote:
>> /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary
>> resources, like how the scrollbar looks like, as the user can't
>> always override them.

> You are mistaken.  The user can always override them with X resource
> settings.

> XTerm*autoWrap:   true
> XTerm*curses: true
> XTerm*loginShell: true
> XTerm*reverseWrap:true
> XTerm*scrollBar:  true
> XTerm*saveLines:  5000
> XTerm*scrollTtyOutput:false
> XTerm*trimSelection:  true
> XTerm*visualBell: true
> XTerm*activeIcon: true
> XTerm.VT100.background:   gray30
> XTerm.VT100.foreground:   gray90
> XTerm.VT100.geometry: 200x55-0+20
> XTerm.VT100.color4: DodgerBlue1
> XTerm.VT100.color8: gray50
> XTerm.VT100.color12: SteelBlue1
> XTerm.VT100.scrollbar.background: white
> XTerm.VT100.scrollbar.foreground: blue

> --=20
> G. Branden Robinson|You can have my PGP passphrase when
> Debian GNU/Linux   |you pry it from my cold, dead
> [EMAIL PROTECTED] |brain.
> http://people.debian.org/~branden/ |-- Adam Thornton

> --KFztAG8eRSV9hGtP
> Content-Type: application/pgp-signature
> Content-Disposition: inline

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.1 (GNU/Linux)

> iEYEARECAAYFAj3Fi4MACgkQ6kxmHytGonyU7gCeJpX2VpF0SvQ0hkWlZLSIrvtr
> gSMAnAqemcYvif2jZHXepQPWibqaJUbM
> =WgVJ
> -END PGP SIGNATURE-

> --KFztAG8eRSV9hGtP--


> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312718: xterm pasting of 8-bit characters from X clipboard interacts poorly with emacs

[Thomas Dickey]

On Thu, Jun 09, 2005 at 10:30:34PM +0200, Frederik Eaton wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-13
> Severity: normal
> 
> Often when I paste text from a web browser or PDF document into my
> terminal, and the terminal is running an 'emacs' process, the
> clipboard text contains special characters which are interpreted as
> control-key or meta-key commands by emacs. For instance, a bullet
> character from xpdf turns into M-b, "backward-word". Obviously, this

That depends.  There's a lot of information here, but not necessarily
what's needed.  You're reporting against xterm, but using a UTF-8 locale.

Is xterm setup to run in that locale?
(normally one would use uxterm)

Is emacs also setup to run in that locale?

What is the code for a "bullet" character?

What is actually pasted?

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpYjrDFZIaQ9.pgp
Description: PGP signature

Bug#312718: xterm pasting of 8-bit characters from X clipboard interacts poorly with emacs

[Thomas Dickey]

On Thu, Jun 09, 2005 at 07:36:58PM -0700, Frederik Eaton wrote:
> On Thu, Jun 09, 2005 at 07:53:05PM -0400, Thomas Dickey wrote:
> Huh. I guess I'd thought that reproducing wouldn't be a problem.
> 
> - When I run
> 
> perl -le 'print "\x{c2}\x{b7}"'

Offhand, that looks like the UTF-8 encoding for the Latin-1 bullet.
Codes from 0x80 to 0xff are mapped to something like 0xc2 followed
by the original value (a little more complicated than that, but enough
for reading).

> I get a bullet. When I paste an xpdf bullet into hexdump it is the
> same byte sequence.

That much sounds consistent - when setup for a UTF-8 locale, xterm/uxterm
knows how to select/paste data encoded for UTF-8.  The original Latin-1
stuff gets passed around in that form.
 
> - I tried running emacs in uxterm, same results.
> 
> - Emacs thinks that the bullet is M-b M-7.

(I don't use emacs): perhaps emacs needs some adjustment to accept UTF-8
input.  I'm guessing that 0xb7 gets entered as M-7, and 0cx2 as M-b.
On my home machine (I'm not at home), I do occasionally enter text using
the meta key, for testing, but don't recall what key combinations make
up the keys I see on the keyboard.  Just checking now, xfd shows me a ^/A
for 0xc2 (which doesn't seem to be a "b"), and 0xb7 is a bullet character.

So far that sounds like a configuration problem (not an xterm bug).
There are limitations on select/paste - but ASCII and Latin-1 "should"
work as long as the applications know to accept UTF-8 input.
 
> Thanks,
> 
> Frederik

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpmDxOsPBIvy.pgp
Description: PGP signature

Bug#313503: xterm -T string doen not work

[Thomas Dickey]

On Tue, Jun 14, 2005 at 06:30:11AM +0200, LeRoy Cressy wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Package: xterm
> Version: 4.3.0.dfsg.1-14
> 
> With the new upgrade from testing I have been using .xsession with
> multiple xterms to open various desktops using fvwm2.
> 
> For instance a system named honey is opened on desk3
> xterm -xrm "*Desk:3" -T Honey -n Honey -sl 300 -bg navy -fg "gold" &
> 
> Now when I start X all of my xterms have the same title and not the
> titles specified in .xsession.
> 
> Each one has [EMAIL PROTECTED]:/home/uid/ and not the title specified.

That's done by your shell initialization - xterm doesn't do this by itself.
Since it's done by the shell, it's done after any command-line option, and
will override.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xterm.deb build from Thomas E. Dickey's tree directly

[Thomas Dickey]

Daniel Stone <[EMAIL PROTECTED]> wrote:

> IIRC  'resize' is also provided by curses or something.  I packaged it
> for Ubuntu and we ran into collisions there.

Well, since 'resize' is part of xterm's source, and not part of ncurses,
that doesn't make much sense.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: patch audit - 099*.diff

[Thomas Dickey]

Daniel Stone <[EMAIL PROTECTED]> wrote:

>> rediffed patches attached for all of these.

>> $Id: 099d_Imake.rules_fix_RawCppFileTarget.diff 1703 2004-07-29 09:52:03Z=
>  branden $
>>=20

> Do not apply this patch.  It breaks all UTF-8 locales, because it also
> modifies the way locale data is processed.  If you look in
> changelog.Ubuntu, it explicitly mentions that this patch was removed
> because it not only broke locales, but also still left the manpages
> broken in the same way.

actually my understanding (from a parallel change) was that the compiler
behavior changed, making the patch obsolete last year.  I noted a random
comment in another quarter regarding locale, but found no reliable information
regarding this.  Perhaps you can point to some discussion on it.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: XTerm 4.0.1b(144) segfault with ssh -v and sudo

[Thomas Dickey]

On Thu, Sep 07, 2000 at 08:25:39PM +0300, Tommi Virtanen wrote:
>   I can make xterm segfault reproducibly 
>   on Debian GNU/Linux woody (unstable).

I stumbled over one cause today (it's dependent on the keystrokes, and just
doesn't break on this host ;-).  A couple of places in the code I integrated in
#140 aren't checked if the terminal is running in UTF-8 mode before going off
and doing things.  Your traceback is one of the two.  (I'll put together a
short patch tonight - #146).
 
> [EMAIL PROTECTED] ~/tmp/x]$ ./xterm -version
> XFree86 4.0.1b(144)
> 
>   If I start an xterm, ssh -v remotehost,
>   and run sudo there, so that sudo prompts
>   for a password, the local xterm segfaults.
>   This only happens with ssh -v, which is
>   weird, and needs a specific version of 
>   _something_ in the remote end -- a bit
>   under-updated Debian 2.2 (potato) seems
>   to cause it, the newer unstable woody 
>   doesn't.
> 
> crashes:
> sudo 1.6.2p2
> OpenSSH 1.2.3
> 
> doesn't crash:
> sudo 1.6.3p5
> OpenSSH 2.1.1p4
> 
>   Here's the end of strace
> 
> select(4, [3], [], [], {0, 0})  = 0 (Timeout)
> read(4, "Password:\0", 4096)= 10
> --- SIGSEGV (Segmentation fault) ---
> 
>   And ltrace:
> 
> memcpy(0x40302548, "Password:", 9)= 0x40302548
> memset(0x40302598, '\200', 9) = 0x40302598
> memset(0x403025e8, '\000', 9) = 0x403025e8
> memset(0x40302638, '\000', 9) = 0x40302638
> --- SIGSEGV (Segmentation fault) ---
> 
>   Here's a backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x8066076 in addXtermCombining ()
> (gdb) bt
> #0  0x8066076 in addXtermCombining ()
> #1  0x804fa3d in VTparse ()
> #2  0x8053b5e in VTRun ()
> #3  0x80697d8 in main ()
> #4  0x40225a52 in __libc_start_main () from /lib/libc.so.6
> (gdb) 
> 
>   Do tell if I can help you any more. I speak
>   C well enough and can manage my way with the
>   debugger.
> 
> -- 
> [EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
> unix, linux, debian, networks, security, | Error messages
> kernel, TCP/IP, C, perl, free software,  | cannot completely convey.
> mail, www, sw devel, unix admin, hacks.  | We now know shared loss.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com

Bug#276234: xterm lost $HOME/bin and $TMPDIR

[Thomas Dickey]

On Tue, Oct 12, 2004 at 10:20:10PM +0200, Michelle Konzack wrote:
> Package: xterm
> Version: 4.1.0-16woody3
> Severity: normal
> 
> Error description:
> 
> I have in my ~/.bash_profile and in ~/.xsession the line 
> 
> export PATH=$HOME/bin/:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R5/bin

perhaps xterm isn't being run as a login shell:

 ~/.bash_profile
  The personal initialization file,  executed  for  login
  shells

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpOKWNo5SVIU.pgp
Description: PGP signature

Bug#276234: xterm lost $HOME/bin and $TMPDIR

[Thomas Dickey]

On Wed, Oct 13, 2004 at 12:30:20PM +0200, Michelle Konzack wrote:
> Am 2004-10-13 05:41:37, schrieb Thomas Dickey:
> > On Tue, Oct 12, 2004 at 10:20:10PM +0200, Michelle Konzack wrote:
> > > Package: xterm
> > > Version: 4.1.0-16woody3
> > > Severity: normal
> > > 
> > > Error description:
> > > 
> > > I have in my ~/.bash_profile and in ~/.xsession the line 
> > > 
> > > export PATH=$HOME/bin/:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R5/bin
> > 
> > perhaps xterm isn't being run as a login shell:
> 
> It was every time working...
> Since the last update I can not use my ~/bin anymore.

But if xterm is not run as a login shell, it won't read the ~/.bash_profile,
and also (for a few years) setuid processes (xterm is one) will have their
environment mashed to exclude customizations such as this.
 
> The Error above is only in '(u)xterm' and not in 'mlterm' or 'eterm'

xterm runs setuid to update utmp.
Some of the other terminals don't do this.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpEwcFWxL8TZ.pgp
Description: PGP signature

Bug#276234: xterm lost $HOME/bin and $TMPDIR

[Thomas Dickey]

> > perhaps xterm isn't being run as a login shell:

by the way -

Changing xterm's behaviour doesn't rely upon scripting

man xterm (resource setting)

 loginShell (class LoginShell)
 Specifies whether or not the shell to be run in  the
 window  should  be  started  as  a login shell.  The
 default is ``false.''
-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpBujICRwUQ6.pgp
Description: PGP signature

Bug#276234: xterm lost $HOME/bin and $TMPDIR

[Thomas Dickey]

On Wed, Oct 13, 2004 at 07:20:00PM +0200, Michelle Konzack wrote:
> Am 2004-10-13 08:20:16, schrieb Thomas Dickey:
> > > > perhaps xterm isn't being run as a login shell:
> > 
> > by the way -
> > 
> > Changing xterm's behaviour doesn't rely upon scripting
> 
> And 'mutt' ? 
> I can not use 'mutt' under in xterm anymore since this upgrade.

I'm assuming you're doing something like
xterm -e mutt
which can't be a login shell, of course.
 
> It was working for years since 03/1999 (SLINK)...
> My fvwm2rc has not changed for more then one year.

fvwm changed its configuration though (different topic).
 
> So there was something changed in xterm since
> 4.1.0-16woody1 because this Version works fine. 

I think it's more likely that someone changed the scope of environment
variable trimming on setuid programs.  That would show up in xterm,
but is unrelated to anything that might have been changed in xterm.

(I'm the upstream maintainer for xterm, cannot say what interesting things
might occur in Debian's packages).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgphpH8OuMeta.pgp
Description: PGP signature

Bug#276234: xterm lost $HOME/bin and $TMPDIR

[Thomas Dickey]

On Wed, Oct 13, 2004 at 08:09:06PM +0200, Michelle Konzack wrote:
> But what I do not understand is, that it was working up to the UPGRADE.

I'm running Debian/testing, and see that about half the contents of /lib
was changed when I updated in mid-September (file dates are a month
earlier, but ctimes show me when the files got there).  I'd expect
environment-variable tinkering to be done in libc.
 
> If i login onto the console, I have my $HOME "/home/michelle" AND 
> $PATH "/home/michelle/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin"
> which are set by my ~/.bash_profile

generally I use tcsh (and set my path in .cshrc).  Aside from (a few years
ago) noticing that shared libraries in /usr/local/lib wouldn't get loaded
nicely (because of the environment-variable trimming), I haven't seen any
recent changes that would add variables to be trimmed.

A quick check (now that I'm home) with

xterm -e sh
or
SHELL=/bin/sh xterm

doesn't show a loss of variables.  So perhaps that's not the problem.
I'm not sure what is.
 
> Please can you check it out with the package Maintainer ?
> I am not the only person with this problem...

I think that's Branden Robinson - who'll be reading this (soon, perhaps).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp3Ufmt0rH46.pgp
Description: PGP signature

Bug#276447: xterm sometimes leaves some of the highlighted selection out of the X selection

[Thomas Dickey]

On Fri, Oct 15, 2004 at 12:00:20AM +0200, Andrew Pimlott wrote:
> > 2.  cat a file that fills a few screens and has tabs (attached)
> 
> right...

was that a 24x80 screen?  (it helps to know how large it was).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp1wHMcT4Dsq.pgp
Description: PGP signature

Bug#275473: xterm's cursor appears as black rectangle when positioned on EOL

[Thomas Dickey]

On Fri, Oct 08, 2004 at 01:50:08PM +0200, Alexey 'Snake' Nezhdanov wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-8
> Severity: normal
> 
> Another color-related bug that appeared after my upgrade to dfsg.1-8
> (I'm sorry - I cannot say which version I used before but probably
> non-dfsg at all).

I can reproduce something like this with #194, but not with #193.
I'm guessing it was something that was uncovered by this change:

   Patch #194 - 2004/7/27 - XFree86 4.4.99.11
   
 * change  clearing  operations  so  foreground color attribute is not
   set.  Usually  this  is  benign,  but in some cases when the cursor
   color  is  not  set  explicitly,  the  cursor would show this color
   (Debian #252873, #260471).

(If the cursor color is set explicitly, no problem is seen - I usually
have my cursor set to lime green).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpJ4sz0sNI4e.pgp
Description: PGP signature

Bug#276234: xterm lost $HOME/bin and $TMPDIR

[Thomas Dickey]

On Mon, Oct 18, 2004 at 03:50:06PM +0200, Branden Robinson wrote:
> On Wed, Oct 13, 2004 at 08:09:06PM +0200, Michelle Konzack wrote:
> > Maybe they have changed something in 4.1.0-16woody2 or 4.1.0-16woody3
> 
> This is a ludicrous assertion.  Diff the unpacked source packages.

I'm guessing that the original configuration had the setgid bit for xterm
removed (for whatever reason) by whoever's in charge of the machine.

xterm doesn't strip environment variables, and it's been a while since
I noticed comments about changes to the runtime doing that - so I'm
assuming the set of variables removed hasn't changed much over the past
couple of years.  google reminds me that this was done and discussed
3-4 years ago, so it's certainly not a new thing.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpu80hCsA35B.pgp
Description: PGP signature

Bug#277832: copy-paste of non-ISO-8859-1 characters between uxterm's is broken

[Thomas Dickey]

On Fri, Oct 22, 2004 at 08:10:11PM +0200, Vincent Lefevre wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-8
> Severity: normal
> 
> I open two uxterm's. In the first one, I type from zsh:
> 
>   echo \\u20ac
> 
> to get a Euro symbol. I double-click on this Euro symbol and paste it
> (with the middle button) to the second uxterm. No problem: I get the
> Euro symbol.
> 
> Now, I click in the first uxterm; the Euro symbol no longer appears
> as selected (this is normal). I click with the middle button in the
> second uxterm. But instead of getting the Euro symbol, I get a hash
> (#).

I noticed this earlier this week, and don't recall seeing it before
except when the xterm owning the selection had lost focus (no need
to beat that dead horse).

The particular case I noticed involved a single instance of uxterm -
in one scenario the paste works properly, but in the other I get a '#'
on the second try at pasting.

I was testing some locale improvements for vile, with the screen split
into two parts.  One shows the printable characters, and the other is
a buffer into which I was inserting.  Using select/paste from the
character list shows the bug (I got one instance of the expected character
and then a '#').  Selecting from the edit-buffer shows no problem.

I don't know the cause, but have it on my to-do list to investigate.
But it does appear to be something that I can fix.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpT2BmGSBNDm.pgp
Description: PGP signature

Bug#276345: copy-paste troubles with the first line of a less

[Thomas Dickey]

On Fri, Oct 22, 2004 at 08:20:04PM +0200, Vincent Lefevre wrote:
> On 2004-10-13 16:34:42 +0200, Lo?c Minier wrote:
> >  It's been some months now that I repeatedly get a strange problem with
> >  a less in xterm:  if I select the first line of the xterm window, being
> >  the first line of the less dump too, I am pasting some sort of buffered
> >  data too, coming from previous lines of output.
> 
> FYI, I reported this bug to Thomas on 2002-03-08.

It might only be a similar bug.  Here are two that are in the same general
area:

  Patch #183 - 2003/12/26 - XFree86 4.3.99.903

 * add a limit check to ScrnTstWrapped() (XFree86 Bugzilla #981).

 Patch #167 - 2002/8/24 - XFree86 4.2.0

 * correct limit-checking in ComputeSelect() to handle selections that
   extend  off  the visible area; rather than modify the parameters to
   TrackText(),  use  ScrollSelection()  to  update  the  highlighting
   limits. (reported by Yegappan Lakshmanan and Nelson Beebe, patch by
   Alexander V Lukyanov).


-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpSbaLMUSHP5.pgp
Description: PGP signature

Bug#276345: copy-paste troubles with the first line of a less

[Thomas Dickey]

On Sat, Oct 23, 2004 at 09:42:10PM +0200, Loc Minier wrote:
> Thomas Dickey <[EMAIL PROTECTED]> - Fri, Oct 22, 2004:
> 
> > On Fri, Oct 22, 2004 at 08:20:04PM +0200, Vincent Lefevre wrote:
> > > On 2004-10-13 16:34:42 +0200, Lo?c Minier wrote:
> > > >  [...]
> > > FYI, I reported this bug to Thomas on 2002-03-08.
> 
>  Vincent Lefevre reported on 2002-03-08, and I reported on 2004-10-13,
>  and you're quoting:
> 
> > It might only be a similar bug.  Here are two that are in the same general
> > area:
> >   Patch #183 - 2003/12/26 - XFree86 4.3.99.903
> >  Patch #167 - 2002/8/24 - XFree86 4.2.0
> 
>  I don't how this couls relate to the first of the second patch, I still

The symptoms sound similar - in the fixes there were places where data was
referenced outside the screen buffer.

>  get the problem randomly anyway.  Are you suggesting you might reverse
>  these patches?  Or do you want someone to look at the patches and check
>  wether they introduced new bugs?

no - I was just pointing out that the particular bug Vincent was talking about
might have been fixed.  Reviewing patches doesn't help much unless you know
exactly what you're looking for (I mainly do that to see when a change was
made and what the corresponding log comments are).

It's likely that it only appears "randomly" because the conditions for
reproducing the bug are not well understood.  Talking about something that
appears when less is run (is this using xterm's alternate screen?  Probably). 
The alternate screen buffer is only as large as the terminal window.  The
normal (with scrollback) is much larger.  So bugs that hit a boundary are more
likely to happen with the alternate screen buffer.  (I don't use the alternate
screen much, so it's mainly other people who would notice a problem with it).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpSNxRSMD6It.pgp
Description: PGP signature

Bug#278897: xterm: insert-selection(...) action breaks selection insertion

[Thomas Dickey]

On Sat, Oct 30, 2004 at 10:40:09AM +0200, Vincent Lefevre wrote:
> On 2004-10-30 08:38:36 +0200, Vincent Lefevre wrote:
> > *VT100.translations:#override \n\
> > Up:   scroll-back(1, line) \n\
> > Down: scroll-forw(1, line) \n\
> > :select-end(PRIMARY, CLIPBOARD) \n\
> > ~Ctrl ~Meta :   insert-selection(PRIMARY, CLIPBOARD)
> 
> Well, perhaps not a bug in Xterm, since if I swap these two lines,
> inserting selection works (as long as there is a primary selection).
> If the behavior depends on the order of the bindings, this should be
> documented (I couldn't find anything about that in the man page).

It should be documented perhaps, but that's an issue with the way X resources
work - the manpage would be several times longer if I included all of the
relevant documentation within it.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpGp9N0F5ynp.pgp
Description: PGP signature

Bug#278897: xterm: insert-selection(...) action breaks selection insertion

[Thomas Dickey]

On Sat, Oct 30, 2004 at 06:17:14PM +0200, Vincent Lefevre wrote:
> I don't think all of the relevant documentation should be included,
> but it wasn't clear (for someone who doesn't know the internals of
> X) if these translations were specific to XTerm or were general to
> X resources. In the latter case, the man page could still point to
> the relevant documentation (which should be written if it doesn't
> exist yet).

The translations resource is a feature of Xt (X Toolkits Intrinsics),
and is also used in other code such as the Athena widgets.

apropos "Translations" shows a place to start:

XtAugmentTranslations   XtParseTranslationTable (3) - manage 
translation tables

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpzPiLmLdIeT.pgp
Description: PGP signature

Re: Bug#229566: xterm fails to start with EINVAL

[Thomas Dickey]

Branden Robinson <[EMAIL PROTECTED]> wrote:

>> | XTerm*eightBitInput:   true
>> | *VT100*eightBitInput: true
>>=20
>> somwehre in ~/.Xresources. Unfortunately, this breaks an application I
>> have to work with for my company.

> Hmm.  I am not sure why setting eightBitInput would rectify an EINVAL
> error attempting to open a device in /dev/pts.

I noticed in the original report that this is for the powerpc.
There're occasional odd reports that make me suspect there's a compiler
bug (or some platform-dependent bug in the termio/termios code).

I can't reproduce this on my Intel box (and don't think I could test
it remotely - firewall & proxy issues).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Bug#229566: xterm fails to start with EINVAL

[Thomas Dickey]

On Wed, Jan 28, 2004 at 11:37:39PM -0500, Branden Robinson wrote:
 
> Don Armstrong and I both have PowerPC machines, but he experiences the
> problem, and I don't.
> 
> I prepared an unstripped, unoptimized, trace-enabled xterm binary for
> PowerPC and Don and I each produced xterm Traces and system call
> straces.
> 
> Hopefully these will be of some use in tracking down the bug.

They seem to give some hints.  Your trace shows the process-ids, no timestamps
and Don's doesn't show process-ids.  But stripping away that column, I can see
that his process is (I'm guessing) running on a network connection while yours
is local machine (that's guessing by looking at some of the calls they make). 
His is getting occasional EAGAIN errno's reading from the pty (perhaps because
it's slower).  I don't see any detail from the subprocess on his - perhaps it
doesn't use the -f option of strace.  Anyway, it seems that the failure is
on the child process, since I don't see a call on the parent side that fails.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net

Bug#229566: xterm fails to start with EINVAL

[Thomas Dickey]

On Fri, 30 Jan 2004, Branden Robinson wrote:

> On Thu, Jan 29, 2004 at 08:58:25PM -0500, Thomas Dickey wrote:
> > On Wed, Jan 28, 2004 at 11:37:39PM -0500, Branden Robinson wrote:
> >
> > > Don Armstrong and I both have PowerPC machines, but he experiences the
> > > problem, and I don't.
> > >
> > > I prepared an unstripped, unoptimized, trace-enabled xterm binary for
> > > PowerPC and Don and I each produced xterm Traces and system call
> > > straces.
> > >
> > > Hopefully these will be of some use in tracking down the bug.
> >
> > They seem to give some hints.  Your trace shows the process-ids, no 
> > timestamps
> > and Don's doesn't show process-ids.  But stripping away that column, I can 
> > see
> > that his process is (I'm guessing) running on a network connection while 
> > yours
> > is local machine (that's guessing by looking at some of the calls they 
> > make).
> > His is getting occasional EAGAIN errno's reading from the pty (perhaps 
> > because
> > it's slower).  I don't see any detail from the subprocess on his - perhaps 
> > it
> > doesn't use the -f option of strace.  Anyway, it seems that the failure is
> > on the child process, since I don't see a call on the parent side that 
> > fails.
>
> Don was running across a network connection, but he said he experienced
> the exact same problem locally.

So it's not that (network delay).  But a little more information might
help.  From the original report, I think this chunk in main.c is where
it's failing - but no idea why (around line 3415):

#ifndef USE_POSIX_TERMIOS
if (ioctl(tty, TCSETA, &tio) == -1)
HsSysError(cp_pipe[1], ERROR_TIOCSETP);
#else /* USE_POSIX_TERMIOS */
if (tcsetattr(tty, TCSANOW, &tio) == -1)
HsSysError(cp_pipe[1], ERROR_TIOCSETP);
#endif /* USE_POSIX_TERMIOS */

Since the '23' would be ERROR_TIOCSETP.  There're several calls before
that in the child process, and I can only guess what's going on.  (This
one looks hard enough even if I could reproduce it).  I generally do
something like
strace -tfo foo.out ./xterm
for this sort of thing...

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Bug#438646: xterm: [manual] move pages from *.1 to *.1x

[Thomas Dickey]

On Sat, 18 Aug 2007, Jari Aalto wrote:


Package: xterm
Version: 229-1
Severity: minor

Debian includes the manual pages:

   /usr/share/man/man1/lxterm.1.gz
   /usr/share/man/man1/uxterm.1.gz
   /usr/share/man/man1/xterm.1.gz
   /usr/share/man/man1/koi8rxterm.1.gz
   /usr/share/man/man1/resize.1.gz

I believe the X-programs should be listed in section

   *.1x.gz


Most of the X-programs are currently *.1.gz

(is this a new issue?)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]