[gentoo-dev] Fixing the TERM mess

[gentoo-dev] Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 8430 bytes --]

[ Please excuse the length... I'm making a proposal related to an issue
which isn't widely understood, and I think it's better to provide an
explanation straight off rather than watch this thread descend into
irrelevant arguments by people who don't have a clue about what's being
discussed. ]

First, some background. Different terminal emulators have different
capabilities.  Some can report their width and height to applications,
some can't. Some can do 8 colours, some can do 8 colours + bold, some
can do 16 colours, some can do 16 colours + bold, some can do 88 or 256
colours + bold and italic. Some terminals have problems writing to the
last character on the screen, some have strange erase bugs, some allow
programs to resize the terminal. Different terminals use different magic
sequences to do these things. Keyboard handling is also different
between different terminals -- some terminals don't support the meta /
alt key, some don't distinguish between escape and control, and handling
of keys like home, end and the function and arrow keys varies
considerably.

All modern terminals will set the TERM environment variable. This allows
applications to:

* support optional capabilities (eg colour) on terminals where it is
  available.

* work around bugs or limiting features in terminals, for example by
  never writing to the bottom right character on terminals that don't
  support it properly.

* know which escape sequences to use when reading or writing from the
  terminal.

Obviously, making each application have its own list of TERM values and
settings isn't a very good solution -- it's a lot of duplicated
information, and makes it hard to update things when new terminals are
released. A centralised database and library makes much more sense.

Historically, there have been two widely used implementations of said
database. These are usually known as 'termcap' and 'terminfo'.

The termcap method is provided by libtermcap-compat. Most applications
which use this method only do so as an option for systems where terminfo
is not available -- for example, for Vim, terminfo vs termcap is a
compile-time option. The termcap database is limited, generally out of
date and mostly unmaintained. It will likely not remain in the tree for
much longer (bug #103105).

The terminfo method is provided by ncurses. It is considerably more
powerful and has far fewer arbitrary restrictions upon database entry
lengths. It is also less unmaintained than termcap. In simple terms,
ncurses provides two things -- a standardised way for applications to
look up terminal capabilities, and a set of library functions which
simplify various terminal-related tasks. Some applications use both of
these, whilst others only use the former and implement their own more
powerful screen handling. Both approaches are valid, depending upon
application needs.

Now, there's a slight problem. If you have TERM=shinynewterm, and you
ssh to a box with an old terminfo database, you'll get a warning or
error that your terminal isn't recognised when you try to use an
ncurses-based application. You can either ask the sysadmin to upgrade,
or you can install the relevant terminfo files into ~/.terminfo. This
isn't a major problem, but the local terminfo thing isn't very well
known, so some people have this silly misconception that you're either
screwed or have to export a fake TERM if the box you're on doesn't
recognise your terminal.

Unfortunately, some of the people who have this silly misconception also
happen to write terminal emulators.

See, certain terminal emulators lie about their TERM setting. Usually
it's things that aren't xterm pretending to be an xterm, although rxvt
sometimes crops up too. Examples of things pretending to be xterm
include Konsole, Gnome Terminal.

The logic behind it goes like this:

* We don't understand this 'terminfo' thing, but we want our terminal to
  work with programs which use ncurses.

* We've implemented xterm-style colour sequences and some basic cursor
  movement.

* Therefore, we shall set TERM=xterm.

This is not a good idea. See, real xterm supports a hell of a lot of
fancy voodoo. It and rxvt-unicode are two of the most fully featured
terminal emulators (from a terminal capability point of view) out there.
None of these cheap knockoffs that claim to be xterm come anywhere near
close to supporting full xterm capabilities.

Right now we have two sets of workarounds in place to avoid problems
with these lying apps. The first is that the xterm terminfo entry is
utterly crippled. The second is that apps which make full use of all the
fancy terminal sequences will often include additional checks and
restrictions when running on an 'xterm' (for example, Vim will disable
most of its mouse capabilities on an xterm to avoid breaking Gnome
Terminal).

This is bad.

It screws over xterm users, because their terminal is not being used to
full effect. Applications which should support 256 colours, full mouse
support, background detection, terminal titles etc have to disable
support for those things in case they break fake xterms.

It also screws over users of those things that pretend to be xterm. Both
Konsole and Gnome Terminal implement a few extras beyond the 'crippled'
xterm definition, but these can't be turned on for fear of breaking both
other "pretend to be xterm" terminals and real xterms.

For some apps, this doesn't really make much difference. For others it
does. As it stands, applications such as powerful text editors and
terminal multiplexers (screen) can't be used properly on anything that
claims TERM="xterm".

At this point, there's at least one person who's going to whine "but I
use vim and screen on $whatever just fine!". Which is true, for
sufficiently small values of fine. As soon as you try to do 256 colour
support (`:set t_Co=256 | colorscheme inkpot` in vim, for example), or
anything mouse related, you're stuffed. You'll also be experiencing
considerable screen redraw slowdowns because some wannabe-xterms don't
do screen refresh voodoo properly.

Not satisfied, and still think your crappy Gnome Terminal is a full
xterm? Install xtermcontrol, run `xtermcontrol --get-bg` and watch your
terminal get very very upset. This is a frickin' nuisance, because
there's a long standing issue to do with Vim and making the default
colour scheme readable on both light and dark backgrounds. It would be
easy to fix if we could count upon anything claiming to be an xterm
supporting xterm colour reporting, but this is not the case.

Now the proposal. This isn't something that can happen immediately, but
it's something I'd like to see us working towards:

* Make everything that isn't xterm set its own TERM value. Possibly the
  same for things pretending to be rxvt, although this is less of an
  issue since I think everything that pretends to be rxvt is "rxvt plus
  some patches".

* Install, either with the terminal (as is done by rxvt-unicode
  currently), or as part of ncurses, proper terminfo definitions for
  these terminals.

* De-cripple the standard xterm definition and remove restrictions from
  programs which can make full use of xterm's capabilities.

* Provide a short FAQ explaining what I said above in a more
  newbie-friendly way, along with a description of how to generate and
  use terminfo files under a user's home directory for compatibility
  with legacy systems and a note that users sshing from legacy systems
  to Gentoo may need to switch their TERM value.

* Include TERM stuff in policy so that the problem doesn't crop up again
  a few months later.

* Putty? Since I consider sshing from insecure systems irresponsible, I
  don't know much about this one, other than that it's another dirty
  liar and that said lying has caused various bugs in the past. Perhaps
  someone could clarify with details of what it pretends to support and
  what it really supports?

Before I go any further with this, does anyone have a really really good
reason why we should continue to make lots of users suffer because a few
upstreams don't know what they're doing?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fixing the TERM mess

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

On Sun, 2005-08-21 at 22:05 +0100, Ciaran McCreesh wrote:
[snip good description of problem]
> Now the proposal. This isn't something that can happen immediately, but
> it's something I'd like to see us working towards:
> 
> * Make everything that isn't xterm set its own TERM value. Possibly the
>   same for things pretending to be rxvt, although this is less of an
>   issue since I think everything that pretends to be rxvt is "rxvt plus
>   some patches".

Hear hear! I've been bothered with this in past as well - especially
when using screen over ssh from other unix flavors.

We might even convince a few upstream vendors to "do the right thing" if
we force this through on our side.

> * Install, either with the terminal (as is done by rxvt-unicode
>   currently), or as part of ncurses, proper terminfo definitions for
>   these terminals.

One could argue for both solutions here: it would make sense to install
it along with the offending terminal, since this is where we change the
value of the $TERM variable.

But once upstream has acknowledged the problem and corrected their $TERM
value, a patch should be submitted to ncurses anyway.

Perhaps we should just once-and-for-all submit a patch to ncurses which
includes these new terminfo definitions? We will then patch our
foo-terminal ebuilds to set a proper value of $TERM. Then when upstream
(hopefully) decides to change their $TERM value to something sane,
ncurses will already have the support, and we can remove the local patch
along with the version bump of foo-terminal.

> * De-cripple the standard xterm definition and remove restrictions from
>   programs which can make full use of xterm's capabilities.
>
> * Provide a short FAQ explaining what I said above in a more
>   newbie-friendly way, along with a description of how to generate and
>   use terminfo files under a user's home directory for compatibility
>   with legacy systems and a note that users sshing from legacy systems
>   to Gentoo may need to switch their TERM value.

A FAQ might also help convince upstream of the existence of a problem -
and help them understand why it is a problem.

> * Include TERM stuff in policy so that the problem doesn't crop up again
>   a few months later.

I'm not sure what you mean by "policy"?

> * Putty? Since I consider sshing from insecure systems irresponsible, I
>   don't know much about this one, other than that it's another dirty
>   liar and that said lying has caused various bugs in the past. Perhaps
>   someone could clarify with details of what it pretends to support and
>   what it really supports?

I generally only use PuTTY as a emergency solution - haven't looked into
its capabilities.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

On Mon, 22 Aug 2005 00:00:26 +0200 Henrik Brix Andersen
<brix@gentoo.org> wrote:
| > * Install, either with the terminal (as is done by rxvt-unicode
| >   currently), or as part of ncurses, proper terminfo definitions for
| >   these terminals.
| 
| One could argue for both solutions here: it would make sense to
| install it along with the offending terminal, since this is where we
| change the value of the $TERM variable.

The problem with this is that non-X boxes will be missing the terminfo
descriptions.

| Perhaps we should just once-and-for-all submit a patch to ncurses
| which includes these new terminfo definitions? We will then patch our
| foo-terminal ebuilds to set a proper value of $TERM. Then when
| upstream (hopefully) decides to change their $TERM value to something
| sane, ncurses will already have the support, and we can remove the
| local patch along with the version bump of foo-terminal.

The problem with this is that some terminals gain new capabilities
fairly regularly. One example is rxvt-unicode, which is still putting
out regular releases.

A third possibility is to split out the terminfo db from ncurses. This
will let us do frequent updates if necessary. It may also help the
embedded people -- we could add a USE=minimal which only installs
'common' definitions and leaves out support for obscure 1950s line
printers. There may be a gaping hole in this idea. I haven't thought it
through much...

| > * Include TERM stuff in policy so that the problem doesn't crop up
| > again a few months later.
| 
| I'm not sure what you mean by "policy"?

That thing we don't have yet.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fixing the TERM mess

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Sun, 2005-08-21 at 23:13 +0100, Ciaran McCreesh wrote:
> The problem with this is that non-X boxes will be missing the terminfo
> descriptions.

Right.

> The problem with this is that some terminals gain new capabilities
> fairly regularly. One example is rxvt-unicode, which is still putting
> out regular releases.

I see...

> A third possibility is to split out the terminfo db from ncurses. This
> will let us do frequent updates if necessary. It may also help the
> embedded people -- we could add a USE=minimal which only installs
> 'common' definitions and leaves out support for obscure 1950s line
> printers. There may be a gaping hole in this idea. I haven't thought it
> through much...

Ripping out /etc/terminfo/ and /usr/share/terminfo from ncurses and
installing it as, say, ncurses-terminfo would make sense. I don't see
any obvious problems with this approach...

> That thing we don't have yet.

Aha.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Fixing the TERM mess

[Dan Meltzer]

putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
can test other things if you need.. just give me some idea :)



On 8/21/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Mon, 22 Aug 2005 00:00:26 +0200 Henrik Brix Andersen
> <brix@gentoo.org> wrote:
> | > * Install, either with the terminal (as is done by rxvt-unicode
> | >   currently), or as part of ncurses, proper terminfo definitions for
> | >   these terminals.
> | 
> | One could argue for both solutions here: it would make sense to
> | install it along with the offending terminal, since this is where we
> | change the value of the $TERM variable.
> 
> The problem with this is that non-X boxes will be missing the terminfo
> descriptions.
> 
> | Perhaps we should just once-and-for-all submit a patch to ncurses
> | which includes these new terminfo definitions? We will then patch our
> | foo-terminal ebuilds to set a proper value of $TERM. Then when
> | upstream (hopefully) decides to change their $TERM value to something
> | sane, ncurses will already have the support, and we can remove the
> | local patch along with the version bump of foo-terminal.
> 
> The problem with this is that some terminals gain new capabilities
> fairly regularly. One example is rxvt-unicode, which is still putting
> out regular releases.
> 
> A third possibility is to split out the terminfo db from ncurses. This
> will let us do frequent updates if necessary. It may also help the
> embedded people -- we could add a USE=minimal which only installs
> 'common' definitions and leaves out support for obscure 1950s line
> printers. There may be a gaping hole in this idea. I haven't thought it
> through much...
> 
> | > * Include TERM stuff in policy so that the problem doesn't crop up
> | > again a few months later.
> | 
> | I'm not sure what you mean by "policy"?
> 
> That thing we don't have yet.
> 
> -- 
> Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
> 
> 
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Sun, 21 Aug 2005 18:43:54 -0400 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
| can test other things if you need.. just give me some idea :)

Thanks. The other useful one is to see whether it does 256 colours
properly like real xterm does. The following bash script, when run with
'256' as its argument, should look the same as it does when run under
a real xterm.


#!/usr/bin/env bash
# vim: set sw=4 sts=4 et :

[[ -z "${1}" ]] && cat <<END && exit 1
Usage: ${0} [count]

count should usually be either 88 (rxvt-based terminals) or 256
(xterm-based terminals).
END

echo -n "  0: "
for (( a = 0 ; a < ${1} ; a++ )) ; do
    echo -n -e "\e[38;5;${a#0}m#\e[48;5;${a#0}mX\e[0;0m "
    [[ -z "${a##*9}" ]] && echo -n -e "\n\e[0;0m$(printf '%3d' ${a} ): "
done
echo -e "\e[0;0m" ; echo


-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[Renat Lumpau]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Mon, Aug 22, 2005 at 12:08:00AM +0100, Ciaran McCreesh wrote:
> Thanks. The other useful one is to see whether it does 256 colours
> properly like real xterm does. The following bash script, when run with
> '256' as its argument, should look the same as it does when run under
> a real xterm.

Not even close here.

-- 
Renat Lumpau
all things web-apps
GPG key id #C6A838DA on http://pgp.mit.edu
Key fingerprint = 04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[Tavis Ormandy]

--On Monday, August 22, 2005 00:21:16 +0000 Renat Lumpau <rl03@gentoo.org>
wrote:

> On Mon, Aug 22, 2005 at 12:08:00AM +0100, Ciaran McCreesh wrote:
>> Thanks. The other useful one is to see whether it does 256 colours
>> properly like real xterm does. The following bash script, when run with
>> '256' as its argument, should look the same as it does when run under
>> a real xterm.
> 
> Not even close here.

I maintain the putty ebuild, but never really use it outside of testing.
However, I know it supports 256 colours.

Your script produces 256 different colours here, the shades dont match
xterm's exactly, but there are definitely 256 distinct colours.

If you emerge putty and start pterm, then ctrl-right click, select "Change
Settings" and choose "Colour" from the dialog, you can disable 256 colours,
perhaps this is what you've done?

Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Tavis Ormandy]

--On Monday, August 22, 2005 08:18:42 +0100 Tavis Ormandy
<taviso@gentoo.org> wrote:

> 
> 
> --On Monday, August 22, 2005 00:21:16 +0000 Renat Lumpau <rl03@gentoo.org>
> wrote:
> 
>> On Mon, Aug 22, 2005 at 12:08:00AM +0100, Ciaran McCreesh wrote:
>>> Thanks. The other useful one is to see whether it does 256 colours
>>> properly like real xterm does. The following bash script, when run with
>>> '256' as its argument, should look the same as it does when run under
>>> a real xterm.
>> 
>> Not even close here.
>
> Your script produces 256 different colours here, the shades dont match
> xterm's exactly, but there are definitely 256 distinct colours.

<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/256-colours-match-xterm.html>

Ahh, apparently it matches an old version, but they plan to update it.

Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Fixing the TERM mess

[Dan Meltzer]

mine ended up spitting out large amounts of gibberish....  and ruining
the readability of the terminal... why would it be so different?

On 8/22/05, Tavis Ormandy <taviso@gentoo.org> wrote:
> 
> 
> --On Monday, August 22, 2005 08:18:42 +0100 Tavis Ormandy
> <taviso@gentoo.org> wrote:
> 
> > 
> > 
> > --On Monday, August 22, 2005 00:21:16 +0000 Renat Lumpau
> <rl03@gentoo.org>
> > wrote:
> > 
> >> On Mon, Aug 22, 2005 at 12:08:00AM +0100, Ciaran McCreesh wrote:
> >>> Thanks. The other useful one is to see whether it does 256 colours
> >>> properly like real xterm does. The following bash script, when run with
> >>> '256' as its argument, should look the same as it does when run under
> >>> a real xterm.
> >> 
> >> Not even close here.
> >
> > Your script produces 256 different colours here, the shades dont match
> > xterm's exactly, but there are definitely 256 distinct colours.
> 
> <http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/256-colours-match-xterm.html>
> 
> Ahh, apparently it matches an old version, but they plan to update it.
> 
> Tavis.
> 
> -- 
> -------------------------------------
> taviso@sdf.lonestar.org | finger me for my gpg key.
> -------------------------------------------------------
> 
> -- 
> gentoo-dev@gentoo.org mailing list
> 
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Francesco R]

Ciaran McCreesh wrote:

>On Sun, 21 Aug 2005 18:43:54 -0400 Dan Meltzer
><parallelgrapefruit@gmail.com> wrote:
>| putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
>| can test other things if you need.. just give me some idea :)
>
>Thanks. The other useful one is to see whether it does 256 colours
>properly like real xterm does. The following bash script, when run with
>'256' as its argument, should look the same as it does when run under
>a real xterm.
>
>
>#!/usr/bin/env bash
># vim: set sw=4 sts=4 et :
>
>[[ -z "${1}" ]] && cat <<END && exit 1
>Usage: ${0} [count]
>
>count should usually be either 88 (rxvt-based terminals) or 256
>(xterm-based terminals).
>END
>
>echo -n "  0: "
>for (( a = 0 ; a < ${1} ; a++ )) ; do
>    echo -n -e "\e[38;5;${a#0}m#\e[48;5;${a#0}mX\e[0;0m "
>    [[ -z "${a##*9}" ]] && echo -n -e "\n\e[0;0m$(printf '%3d' ${a} ): "
>done
>echo -e "\e[0;0m" ; echo
>
>  
>
Probably putty use "xterm" as default instead to be usable on most
configurations.
I've found that putty is the best (free on windows) "linux" term
emulator around.
As a consequence all my win boxes use it with the following settings:

Terminal -> Keyboard -> The Functions keys and keypad -> Linux
Connection -> Data -> Terminal-type string -> "linux"

with this settings the "xtermcontrol --get-bg" output this:
xtermcontrol: TERM=linux: probably not xterm variant

The script you posted here has good results for $1 = 256 for putty
version 0.58 .
For version 0.56 of putty the for loop need to start from "13" instead
of "0" or it screwed up things at the extend that a "reset" need to be
run. Additionally  the color support is limited to 16 .

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fixing the TERM mess

[Mike Frysinger]

On Sunday 21 August 2005 05:05 pm, Ciaran McCreesh wrote:
> The terminfo method is provided by ncurses. It is considerably more
> powerful and has far fewer arbitrary restrictions upon database entry
> lengths. It is also less unmaintained than termcap.

actually it's actively maintained and the upstream author is a cool guy :)

> * Make everything that isn't xterm set its own TERM value. Possibly the
>   same for things pretending to be rxvt, although this is less of an
>   issue since I think everything that pretends to be rxvt is "rxvt plus
>   some patches".

actually, latest ncurses + gnome-terminal break because gnome-terminal sets 
TERM=xterm ... people proposed we revert some changes to ncurses but i denied 
that in favor of making gnome-terminal export TERM=gnome
http://bugs.gentoo.org/show_bug.cgi?id=91055

i think the gnome team is just ignoring this though ;)

> * Putty? Since I consider sshing from insecure systems irresponsible, I
>   don't know much about this one, other than that it's another dirty
>   liar and that said lying has caused various bugs in the past. Perhaps
>   someone could clarify with details of what it pretends to support and
>   what it really supports?

there is a TERM=putty setting isnt there ?

> Before I go any further with this, does anyone have a really really good
> reason why we should continue to make lots of users suffer because a few
> upstreams don't know what they're doing?

sounds like a good proactive step to me
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fixing the TERM mess

[Kevin F. Quinn]

On 21/8/2005 23:05:05, Ciaran McCreesh (ciaranm@gentoo.org) wrote:

> Now the proposal. This isn't something that can happen immediately, but
> it's something I'd like to see us working towards:
> 
> [...]
> 
> * De-cripple the standard xterm definition and remove restrictions from
>   programs which can make full use of xterm's capabilities.

This bit, obviously, has to wait until at least the more common packages have
been adjusted for their own TERM value.  In the interim, how about creating a
'xtermstd' entry with the de-crippled definition, and altering the (presumably
few) packages that supply fully-compatible xterms to use that, with a view to
changing them back to 'xterm' later once the rest of the world is in line.

I think it's also worth considering leaving the existing xterm entry crippled,
and just accept that abuse of it is too entrenched and widespread to fix.  

> * Putty? Since I consider sshing from insecure systems irresponsible, I
>   don't know much about this one, other than that it's another dirty
>   liar and that said lying has caused various bugs in the past. Perhaps
>   someone could clarify with details of what it pretends to support and
>   what it really supports?

I use PuTTY when I have to use Windows; it's also available for Unix.

PuTTY has a configuration setting to set the terminal type string; by default
this is set to "xterm" but it's easy to change to something else.  This is a per-session
configuration option (under Connection->Data for anyone interested), so it's easy
to set it to (say) "putty" for connections to some boxes and "xterm" for others.
Which means creating a "putty" terminfo definition would be workable.

BTW re. colours - PuTTY seems to do 256 colours the same as a standard
xterm, as far as I can tell.  However that's comparing PuTTY 0.58beta with
xterm-1.96 built with Cygwin on Windows from xorg-6.8.1, so it may just be
they're deriving their colours from the same (Windows) palette.  The only
difference is that the first colour block shows up as 'X' in the cygwin xterm,
but as a black block in PuTTY.  The first 16 colours are black, red, green,
yellow, blue, magenta, cyan and white (8 x dim then 8 x bright), followed by
a 6x6x6 colour cube with black at #16, green at #46, blue at #21, red at
#196 and white at #231), then a 24 step greyscale black -> white.




-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Tue, 23 Aug 2005 8:52:13 +0200 "Kevin F. Quinn"
<kevquinn@gentoo.org> wrote:
| On 21/8/2005 23:05:05, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
| > Now the proposal. This isn't something that can happen immediately,
| > but it's something I'd like to see us working towards:
| > 
| > [...]
| > 
| > * De-cripple the standard xterm definition and remove restrictions
| > from programs which can make full use of xterm's capabilities.
| 
| This bit, obviously, has to wait until at least the more common
| packages have been adjusted for their own TERM value.  In the
| interim, how about creating a 'xtermstd' entry with the de-crippled
| definition, and altering the (presumably few) packages that supply
| fully-compatible xterms to use that, with a view to changing them
| back to 'xterm' later once the rest of the world is in line.
| 
| I think it's also worth considering leaving the existing xterm entry
| crippled, and just accept that abuse of it is too entrenched and
| widespread to fix.  

Hrm, I'd really rather not do that, on the grounds that it's a nasty
hack and that it encourages people to carry on abusing TERM. By leaving
xterm crippled in the long term, we're in effect saying "it's ok to
pretend to be an xterm", which it isn't.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fixing the TERM mess

[Olivier Crete]

On Tue, 2005-23-08 at 21:27 +0100, Ciaran McCreesh wrote:
> On Tue, 23 Aug 2005 8:52:13 +0200 "Kevin F. Quinn"
> <kevquinn@gentoo.org> wrote:
> | On 21/8/2005 23:05:05, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
> | > Now the proposal. This isn't something that can happen immediately,
> | > but it's something I'd like to see us working towards:
> | > 
> | > [...]
> | > 
> | > * De-cripple the standard xterm definition and remove restrictions
> | > from programs which can make full use of xterm's capabilities.
> | 
> | This bit, obviously, has to wait until at least the more common
> | packages have been adjusted for their own TERM value.  In the
> | interim, how about creating a 'xtermstd' entry with the de-crippled
> | definition, and altering the (presumably few) packages that supply
> | fully-compatible xterms to use that, with a view to changing them
> | back to 'xterm' later once the rest of the world is in line.
> | 
> | I think it's also worth considering leaving the existing xterm entry
> | crippled, and just accept that abuse of it is too entrenched and
> | widespread to fix.  
> 
> Hrm, I'd really rather not do that, on the grounds that it's a nasty
> hack and that it encourages people to carry on abusing TERM. By leaving
> xterm crippled in the long term, we're in effect saying "it's ok to
> pretend to be an xterm", which it isn't.

I though about this thing last night, and frankly, I think its a lost
cause. I remember that during the Gnome 1.x era, gnome-terminal used to
set TERM=gnome (at least it did on Red Hat) and they had the proper
termcap/terminfo entries. But they ended up going back to TERM=xterm,
probably because it caused problems for their users, like login into
anything else and being reduced to the lowest possible common
denominator (like logging into a Solaris system and being reduced to
non-visual mode by vi). And by the way, Solaris 2.8 still does not know
about rxvt.

As a gnome-terminal user, I've never had problems with anything that
tried to use advanced xterm crap... probably because no uses them. If
you want X stuff, just use a real X application (like gvim...). I'm
strictly opposed to crippling my terminal use in the most common cases
(such a logging into a non-Gentoo system) for one or two legacy
applications.

In the era of massive sshing, we have to forget terminfo and new
terminal types. We should understand xterm to mean a basic x terminal
and not the application from X.org. 


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Tue, 23 Aug 2005 16:57:28 -0400 Olivier Crete <tester@gentoo.org>
wrote:
| As a gnome-terminal user, I've never had problems with anything that
| tried to use advanced xterm crap... probably because no uses them. If
| you want X stuff, just use a real X application (like gvim...). I'm
| strictly opposed to crippling my terminal use in the most common cases
| (such a logging into a non-Gentoo system) for one or two legacy
| applications.

Ok, to put this into perspective: the next major release of vim will
almost certainly not work on anything that calls itself an xterm unless
it really is an xterm. You will likely encounter a hard locked terminal
that you can't unlock. The latest ncurses release will also break
various things (irssi comes to mind) on Gnome Terminal.

Crippling xterm is no longer considered a suitable workaround. 

| In the era of massive sshing, we have to forget terminfo and new
| terminal types. We should understand xterm to mean a basic x terminal
| and not the application from X.org. 

Uh, no, a basic x terminal would be TERM=vt100. If an application
claims TERM=xterm, it is expected to support full xterm capabilities.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Fixing the TERM mess

[Georgi Georgiev]

maillog: 23/08/2005-16:57:28(-0400): Olivier Crete types
> I though about this thing last night, and frankly, I think its a lost
> cause. I remember that during the Gnome 1.x era, gnome-terminal used to
> set TERM=gnome (at least it did on Red Hat) and they had the proper
> termcap/terminfo entries. But they ended up going back to TERM=xterm,
> probably because it caused problems for their users, like login into
> anything else and being reduced to the lowest possible common
> denominator (like logging into a Solaris system and being reduced to
> non-visual mode by vi). And by the way, Solaris 2.8 still does not know
> about rxvt.
> 
> As a gnome-terminal user, I've never had problems with anything that
> tried to use advanced xterm crap... probably because no uses them. If
> you want X stuff, just use a real X application (like gvim...). I'm
> strictly opposed to crippling my terminal use in the most common cases
> (such a logging into a non-Gentoo system) for one or two legacy
> applications.
> 
> In the era of massive sshing, we have to forget terminfo and new
> terminal types. We should understand xterm to mean a basic x terminal
> and not the application from X.org. 

Oh, come-on, just do "TERM=xterm ssh your.solaris.box" when you really
need to.  Or, recalling Ciaran's opening post to this thread, put your
terminfo in ~/.terminfo (was it?) on those few machines.

-- 
()   Georgi Georgiev   () Paprika Measure: 2 dashes == 1smidgen 2      ()
()    chutz@gg3.net    () smidgens == 1 pinch 3 pinches == 1 soupcon   ()
()  +81(90)2877-8845   () 2 soupcons == 2 much paprika                 ()
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Fixing the TERM mess

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

> The termcap method is provided by libtermcap-compat. Most applications
> which use this method only do so as an option for systems where terminfo
> is not available -- for example, for Vim, terminfo vs termcap is a
> compile-time option. The termcap database is limited, generally out of
> date and mostly unmaintained. It will likely not remain in the tree for
> much longer (bug #103105).

Take a look at ncurses. ncurses even comes with a termcap.h in
/usr/include. I think ncurses is source-compatible with termcap and
offers the features needed to acces different terminal types.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Wed, 2005-08-24 at 01:56 +0200, Sven Köhler wrote:
> > The termcap method is provided by libtermcap-compat. Most applications
> > which use this method only do so as an option for systems where terminfo
> > is not available -- for example, for Vim, terminfo vs termcap is a
> > compile-time option. The termcap database is limited, generally out of
> > date and mostly unmaintained. It will likely not remain in the tree for
> > much longer (bug #103105).
> 
> Take a look at ncurses. ncurses even comes with a termcap.h in
> /usr/include. I think ncurses is source-compatible with termcap and
> offers the features needed to acces different terminal types.

Its supposed to be, but not always .. we never used to have
libtermcap-compat, but I was forced to add that after the minimal vi
implementation we had at a time did not work with ncurses ...

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Fixing the TERM mess

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

> See, certain terminal emulators lie about their TERM setting. Usually
> it's things that aren't xterm pretending to be an xterm, although rxvt
> sometimes crops up too. Examples of things pretending to be xterm
> include Konsole, Gnome Terminal.
> 
> The logic behind it goes like this:
> 
> * We don't understand this 'terminfo' thing, but we want our terminal to
>   work with programs which use ncurses.
> 
> * We've implemented xterm-style colour sequences and some basic cursor
>   movement.
> 
> * Therefore, we shall set TERM=xterm.
> 
> This is not a good idea. See, real xterm supports a hell of a lot of
> fancy voodoo. It and rxvt-unicode are two of the most fully featured
> terminal emulators (from a terminal capability point of view) out there.
> None of these cheap knockoffs that claim to be xterm come anywhere near
> close to supporting full xterm capabilities.

I fully agree with you, but ... did xterm support the full feature-set
right from the start? So what happens if i've got a box running an old
xterm and then do an ssh-session to a newer box where the application
thinks that xterm support some fency new feature?

After the all, the whole mess can IMHO only be cleared up, if there's
something like a universal terminal-type, and the application could ask
the terminal for it's feature-set. So i'm not aware if this is possible,
but this seems to be the only _really_ reliable extensible way to do
this. I don't see the point in define lots of all new terminal-types.

Of course this isn't and a short-term sollution and would have to be
implemented by all the terminal-emulators that lie about their
terminal-type.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 735 bytes --]

On Wed, 24 Aug 2005 02:10:04 +0200 Sven Köhler <skoehler@upb.de> wrote:
| After the all, the whole mess can IMHO only be cleared up, if there's
| something like a universal terminal-type, and the application could
| ask the terminal for it's feature-set. So i'm not aware if this is
| possible, but this seems to be the only _really_ reliable extensible
| way to do this. I don't see the point in define lots of all new
| terminal-types.

There is none. Even if such a thing existed, it wouldn't solve the
"does this terminal have any weird bugs" issue.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #1.2: . --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[ivan vadovič]

On Wed, Aug 24, 2005 at 01:07:42PM +0100, Ciaran McCreesh wrote:
> On Wed, 24 Aug 2005 02:10:04 +0200 Sven Köhler <skoehler@upb.de> wrote:
> | After the all, the whole mess can IMHO only be cleared up, if there's
> | something like a universal terminal-type, and the application could
> | ask the terminal for it's feature-set. So i'm not aware if this is
> | possible, but this seems to be the only _really_ reliable extensible
> | way to do this. I don't see the point in define lots of all new
> | terminal-types.
> 
> There is none. Even if such a thing existed, it wouldn't solve the
> "does this terminal have any weird bugs" issue.

I think the key thing here is that the application should be able to ask the
terminal for its feature set. That'd also solve the cases where a terminal
changes right beneath a running application. That happens during attaching a
screen session. Would it be possible/hard for a terminal to have a
'gimme_your_terminfo' capability? Or, alternatively, the capability could be
'gimme_your_TERM' and this would solve problems with buggy terminals as well.
For me the biggest obstacle with terminals is that TERM environment variable
can't change during an application runtime, while the terminal can change and,
when using screen, often does.
Well, I don't know much about this and you seem to be very knowledgeable, so I
ask :).

Ivan
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Mon, 29 Aug 2005 09:28:28 +0200 "ivan vadovič" <pifko@szm.sk> wrote:
| I think the key thing here is that the application should be able to
| ask the terminal for its feature set.

Should and can are two entirely different things. We're dealing with
reality here and trying to cope with fifty years or so of differing
terminal designs.

| That'd also solve the cases where a terminal changes right beneath a
| running application. That
| happens during attaching a screen session.

No it doesn't. Screen provides a virtual terminal with lots and lots of
capabilities. It then reduces them itself internally to what it thinks
the underlying term supports -- again, this is done via terminfo, so if
you're running screen on xterm you're running a crippled screen.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[ivan]

> | That'd also solve the cases where a terminal changes right beneath a
> | running application. That
> | happens during attaching a screen session.
> 
> No it doesn't. Screen provides a virtual terminal with lots and lots of
> capabilities. It then reduces them itself internally to what it thinks
> the underlying term supports -- again, this is done via terminfo, so if
> you're running screen on xterm you're running a crippled screen.

So, screen advertises the same capabilities to the starting apps regardless the
terminal the screen is being run on?

Or it advertises reduced capabilities according the terminal it's currently
attached to?

As for the former, I don't think that would work. If an app chooses a multi
color style cuz screen is able to handle it, but then screen tries to reduce it
to mono.

And for the later, it'd work much better if terminal could pump its capabilities
to the app at runtime, that is during reattachment. Would it be that hard to
extend window resize or something?

Ivan
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Thu, 8 Sep 2005 18:50:10 +0200 ivan <pifko@szm.sk> wrote:
| > | That'd also solve the cases where a terminal changes right
| > | beneath a running application. That
| > | happens during attaching a screen session.
| > 
| > No it doesn't. Screen provides a virtual terminal with lots and
| > lots of capabilities. It then reduces them itself internally to
| > what it thinks the underlying term supports -- again, this is done
| > via terminfo, so if you're running screen on xterm you're running a
| > crippled screen.
| 
| So, screen advertises the same capabilities to the starting apps
| regardless the terminal the screen is being run on?

Yes.

| Or it advertises reduced capabilities according the terminal it's
| currently attached to?

No.

| As for the former, I don't think that would work. If an app chooses a
| multi color style cuz screen is able to handle it, but then screen
| tries to reduce it to mono.

That's exactly what happens.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Fixing the TERM mess

[Joe Wells]

Ciaran McCreesh <ciaranm <at> gentoo.org> writes:

> Now, there's a slight problem. If you have TERM=shinynewterm, and
> you ssh to a box with an old terminfo database, you'll get a warning
> or error that your terminal isn't recognised when you try to use an
> ncurses-based application. You can either ask the sysadmin to
> upgrade, or you can install the relevant terminfo files into
> ~/.terminfo. This isn't a major problem, but the local terminfo
> thing isn't very well known, so some people have this silly
> misconception that you're either screwed or have to export a fake
> TERM if the box you're on doesn't recognise your terminal.

The best solution to this that I can think of is to extend OpenSSH
with the capability to copy terminfo information to ~/.terminfo on the
remote system.

This solution would have these advantages:

* The actual TERM name "xterm" or "gnome" or "rxvt" would no longer
  matter at all.  Applications could lie all they like and we would
  not be bothered.  All that is necessary is that on your home system
  things would be set up so that the TERM value determines the right
  information in the local terminfo database or your own ~/.terminfo.
  When OpenSSH copies the information to the remote system, it would
  check in the remote terminfo information (both the system database
  and your ~/.terminfo) for an exact match on the specifications and
  if so reuse the name with the matching data; otherwise it would pick
  a fresh name following a specific convention (e.g.,
  "xterm-via-ssh-3" where "-via-ssh-3" is added just to be different)
  and insert the data in your remote ~/.terminfo.

* The correct information would always be available.  No terminal
  application would ever have to be used with crippled specifications.

* When terminal applications start up, they could choose their own
  name (and bump it with each revision that adds features or removes
  bugs) and ensure that the correct information was stored in
  ~/.terminfo.  This would avoid the problem of stale information in
  the terminfo database.  (Well, some cruft would accumulated in the
  personal ~/.terminfo area, but the entire directory could safely be
  deleted whenever you have no programs running on the system, e.g.,
  at boot time.)

* The terminfo database could eventually no longer matter.  It would
  be needed only for legacy terminal applications that don't supply
  their own information and for terminal applications whose authors
  supply the wrong information (and in both cases the information
  would only be needed on the system the application starts on,
  because OpenSSH would copy the correct values to where they were
  needed).

* The extension to OpenSSH seems not too hard to implement.  OpenSSH
  can run "infocmp" to get a terminfo description as a big string.
  OpenSSH already has support (at least in SSH protocol version 2) for
  copying the values of some environment variables like TERM, so it
  could just reuse this same mechanism to copy the data to the remote
  system.  On the remote machine, "tic" can be used to insert the
  terminfo description into ~/.terminfo.

* Only the OpenSSH package needs to be modified.  Although the various
  terminal applications would benefit from installing accurate
  self-descriptions in ~/terminfo when they start up, this is not
  needed.

* The solution is 100% backward compatible.  Existing usage remains
  exactly the same.  No programs have to be changed other than
  OpenSSH.  Old versions of OpenSSH would still work just as they do
  now; they would just be missing the new advantage.

* If OpenSSH fails in copying the terminfo data into ~/.terminfo on
  the remote system, it can fall back to the old approach just by
  stripping off any "-via-ssh-*" suffix from the TERM value.  (This
  means the convention for picking fresh names needs to be
  reversible.)

* The solution would be automatically deployed worldwide through the
  regular updating of OpenSSH.  People will tend to update OpenSSH
  more quickly than other packages due to the desire to keep their
  security up-to-date.  Anyway, this solution would be another
  motivation for everyone to stay upgraded to the latest version of
  OpenSSH, which is always a good thing.

* Maybe some more people would dump proprietary SSH if they don't add
  the feature quickly enough.  :-)

-- 
Joe Wells

P.S.  I don't normally read this forum at all, so if you want me to
see any replies please e-mail a copy to me.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Joe Wells wrote:
> The best solution to this that I can think of is to extend OpenSSH
> with the capability to copy terminfo information to ~/.terminfo on the
> remote system.

IMHO automated overwriting files in $HOME on every login is a *very* bad
thing. And if you wanted to remove those "-via-ssh-#" lines after
logout, what will happen if your connection hungs?

-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Re: Fixing the TERM mess

[YoYo Siska]

On Tue, Sep 06, 2005 at 09:19:51PM +0200, Jan Kundrát wrote:
> Joe Wells wrote:
> > The best solution to this that I can think of is to extend OpenSSH
> > with the capability to copy terminfo information to ~/.terminfo on the
> > remote system.
> 
> IMHO automated overwriting files in $HOME on every login is a *very* bad
> thing. And if you wanted to remove those "-via-ssh-#" lines after
> logout, what will happen if your connection hungs?
> 
> -jkt

As said ssh can transport environment variables to the other system.
Usualy people use it to transfer $TERM.. why not make a variable
$TERMINFO_DESC ($TERMINFO is allready used by curses for the path to
local terminfo) and put the hole terminfo description into it, mark it
for export via ssh, and write a few commands in your bashrc on the other
side to put $TERMINFO_DESC into a file say ~/.terminfo/${TERM:0:1}/$TERM
if it does not exist... (or do the new-uniqe-name stuff Joe suggested)

Or just simpler, put a termcap descritption into $TERMCAP, and mark that
for ssh export. Downside is that you would have to change TERM to
something that isn't in the other systems terminfo database, or
the $TERMCAP won't be used.

Or better, hack curses to use $TERMINFO_DESC from environment to
override the system terminfo databes, and just export that variable...
Downside is that applications that don't use ncurses won't use it...

But best way  is to clear the mess as suggested and persuade konsole,
gnome-terminal and others to use their own terminal type.

-- 
      _
      |
YoYo () Siska

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Fixing the TERM mess

[Joe Wells (reverse mailbox letters only for non-public replies)]

[ This is my second try because the first time my e-mail address was
  not the subscribed address due to a bug.  This means that Jan
  Kundrát's reply to this message may get threaded strangely or be
  missing. ]

Jan Kundrát <jkt@gentoo.org> writes:

> Joe Wells wrote:
>> The best solution to this that I can think of is to extend OpenSSH
>> with the capability to copy terminfo information to ~/.terminfo on the
>> remote system.
>
> IMHO automated overwriting files in $HOME on every login is a *very* bad
> thing.

Hi, Jan!

In reply, my first question is:  What makes you think files would be
overwritten?  These would be new files.  Look at how the terminfo
database is structured.  Adding a new terminal description is done by
adding a new file (possibly in a new directory, if there are no other
descriptions whose name begins with the same character).

My second question is:  What would be wrong with overwriting files in
$HOME on every login?  I currently have a bunch of files/directories
in $HOME (e.g., .history, .gconfd, .fonts.cache-1, .bash_history,
.recently-used, .Xauthority, .macromedia, .adobe, .subversion, .nvu,
.gnome, .mozilla, .java, etc.), that regularly get overwritten by
various random programs, without my asking, and things continue to
work.  Some of these changes even automatically happen every time I
log in.  The SSH program regularly rewrites files (e.g.,
~/.ssh/known_hosts) successfully.

> And if you wanted to remove those "-via-ssh-#" lines after
> logout, what will happen if your connection hungs?

I'm sorry, but I don't understand the question at all.  What
"-via-ssh-#" lines?  There are no such lines in my proposal.

-- 
Joe

P.S.  As I do not get this mailing list (I'm subscribed, but to the
no-mail version), if anyone wants me to see any replies, it would help
to send a copy of the e-mail to me, as I probably won't have time to
check the forum.

-- 
gentoo-dev@gentoo.org mailing list