NetBSD Problem Report #10127
Received: (qmail 28544 invoked from network); 16 May 2000 04:07:18 -0000
Message-Id: <20000516040717.3A8731E00E5@snark.piermont.com>
Date: Tue, 16 May 2000 00:07:17 -0400 (EDT)
From: perry@piermont.com
Reply-To: perry@piermont.com
To: gnats-bugs@gnats.netbsd.org
Subject: port i386 /etc/ttys says vt220 instead of wsvt25
X-Send-Pr-Version: 3.95
>Number: 10127
>Category: misc
>Synopsis: port i386 /etc/ttys says vt220 instead of wsvt25
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: misc-bug-people
>State: closed
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Tue May 16 04:08:00 +0000 2000
>Closed-Date: Tue May 13 13:31:37 +0000 2008
>Last-Modified: Sun Jun 24 18:05:02 +0000 2012
>Originator: Perry E. Metzger
>Release: NetBSD-current, May 16, 2000
>Organization:
Perry Metzger perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
>Environment:
System: NetBSD snark.piermont.com 1.4Y NetBSD 1.4Y (SNARK) #0: Sun May 7 20:48:54 EDT 2000 perry@snark.piermont.com:/usr/src/sys/arch/i386/compile/SNARK i386
>Description:
The proper termcap entry for the wscons on the i386 (and some
other ports) is wsvt25 (or wsvt25m). However, it appears that
all our /etc/ttys files say vt220 instead. This means
capabilities such as color and such are not available on the
console.
>How-To-Repeat:
Examine /etc/ttys
>Fix:
It isn't clear if we should or shouldn't change this, but we
probably should. The fix would be to (trivially) change the
default ttys files.
>Release-Note:
>Audit-Trail:
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: perry@piermont.com
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Tue, 16 May 2000 09:36:10 +0200
On Tue, May 16, 2000 at 12:07:17AM -0400, perry@piermont.com wrote:
>
> >Fix:
> It isn't clear if we should or shouldn't change this, but we
> probably should. The fix would be to (trivially) change the
> default ttys files.
The problem is that is you rlogin/telnet/ssh to another system which
doesn't know about wsvt25, you loose (I've hated the linux 'xterm-color' hack
because of this). I'd say leave vt220 which is known by most systems and
explain in the FAQ how to switch to wsvt25
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
--
From: woods@weird.com (Greg A. Woods)
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Tue, 16 May 2000 12:30:34 -0400 (EDT)
[ On Tuesday, May 16, 2000 at 09:36:10 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
>
> On Tue, May 16, 2000 at 12:07:17AM -0400, perry@piermont.com wrote:
> >
> > >Fix:
> > It isn't clear if we should or shouldn't change this, but we
> > probably should. The fix would be to (trivially) change the
> > default ttys files.
>
> The problem is that is you rlogin/telnet/ssh to another system which
> doesn't know about wsvt25, you loose (I've hated the linux 'xterm-color' hack
> because of this). I'd say leave vt220 which is known by most systems and
> explain in the FAQ how to switch to wsvt25
That's not a problem. You should copy the full terminal definition over
to the "losing" system, and use it -- you'll get the best of both worlds!
This is something that people using terminals to connect to Unix hosts
have done for many years -- only recently with the proliferation of X11
has much of this been hidden from many users courtesy the universal
applicability of a common "xterm" terminal type.
"xterm-color" isn't a hack -- it's a different kind of terminal -- the
"hack" is that it happens to support a subset of commands as described
by the "xterm" terminal type and thus it allows users of that terminal
type be able to use it when connecting to systems that don't have a full
"xterm-color" definition in their terminal capabilities database. Such
users still have to change their terminal type to "xterm" on remote
systems though (as you've discovered! ;-)....
So, alternately you could examine existing available terminal types on
the remote system to see if one is a proper subset of the NetBSD console
emulation and choose that type either before or after you connect to the
remote system. You could also use a terminal emulator, such as screen,
to mediate your terminal type with the remote system. You can do either
of these things in a "wrapper" script/alias/function.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Tue, 16 May 2000 18:41:53 +0200
On Tue, May 16, 2000 at 12:30:34PM -0400, Greg A. Woods wrote:
> That's not a problem. You should copy the full terminal definition over
> to the "losing" system, and use it -- you'll get the best of both worlds!
>
> This is something that people using terminals to connect to Unix hosts
> have done for many years -- only recently with the proliferation of X11
> has much of this been hidden from many users courtesy the universal
> applicability of a common "xterm" terminal type.
Sure, but a user that can do this can also change /etc/ttys !
There is also the termcap vs terminfo issue which may make the problem
harder (I guess you have to change both files, isn't it ?).
>
> "xterm-color" isn't a hack -- it's a different kind of terminal -- the
> "hack" is that it happens to support a subset of commands as described
> by the "xterm" terminal type and thus it allows users of that terminal
> type be able to use it when connecting to systems that don't have a full
> "xterm-color" definition in their terminal capabilities database. Such
> users still have to change their terminal type to "xterm" on remote
> systems though (as you've discovered! ;-)....
Hum, I ddin't have enouth coffe when I wrote this - I meant the 'linux'
terminal type. This one is harder because none of the standart term type seems
to work rigth.
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
--
From: Brad Spencer <brad@anduin.eldar.org>
To: bouyer@antioche.lip6.fr
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Tue, 16 May 2000 15:01:54 -0400 (EDT)
On Tue, May 16, 2000 at 12:30:34PM -0400, Greg A. Woods wrote:
> That's not a problem. You should copy the full terminal definition over
> to the "losing" system, and use it -- you'll get the best of both worlds!
>
> This is something that people using terminals to connect to Unix hosts
> have done for many years -- only recently with the proliferation of X11
> has much of this been hidden from many users courtesy the universal
> applicability of a common "xterm" terminal type.
Sure, but a user that can do this can also change /etc/ttys !
There is also the termcap vs terminfo issue which may make the problem
harder (I guess you have to change both files, isn't it ?).
[snip]
For many years, in previous worlds, I would supply my own termcap/terminfo
database in my home directories and point the TERMCAP environment variable
at that file, or the TERMINFO environment variable at my private terminfo
tree. This can all be done without the hint of sysadmin ability.
Converting between terminfo and termcap can usually be done with 'infocmp
-C' and 'captoinfo'.
Brad Spencer - brad@anduin.eldar.org http://anduin.eldar.org
[finger brad@anduin.eldar.org for PGP public key]
From: woods@weird.com (Greg A. Woods)
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Tue, 16 May 2000 15:48:13 -0400 (EDT)
[ On Tuesday, May 16, 2000 at 18:41:53 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
>
> On Tue, May 16, 2000 at 12:30:34PM -0400, Greg A. Woods wrote:
> > That's not a problem. You should copy the full terminal definition over
> > to the "losing" system, and use it -- you'll get the best of both worlds!
> >
> > This is something that people using terminals to connect to Unix hosts
> > have done for many years -- only recently with the proliferation of X11
> > has much of this been hidden from many users courtesy the universal
> > applicability of a common "xterm" terminal type.
>
> Sure, but a user that can do this can also change /etc/ttys !
Nope. Those are two different classes of users. One's at least a
junior sys-admin with the root password, the other's just a shell user.
You don't need to be a superuser to set your terminal type and to
provide the necessary terminal capabilities database entries, at least
not on any Unix or unix-like system I've ever used....
> There is also the termcap vs terminfo issue which may make the problem
> harder (I guess you have to change both files, isn't it ?).
By necessity all terminfo systems have the tool(s) necessary to do the
conversions (captoinfo, infocmp). Certainly this issue raises the bar a
bit, but nothing anyone capable of reading a manual page should have any
trouble with. It's quite likely that the remote system's administrator
would be willing to help too, though of course this is where politics
enters the picture! ;-)
Except for a few weird and site-specific exceptions I've never seen any
base vendor-supplied system software that required one to have both
terminfo and termcap databases available simultaneously (at least not
within any given "universe" -- Pyramid's dual universe system faithfully
provided termcap in the BSD universe and terminfo in the ATT universe,
but never the twain shall meet in real life!).
The only really brain-dead environment I ever had to manage was a site
running ATT-SysVr3.0 (on an NCR Tower) and using Wordperfect for Unix.
That damn Wordperfect insisted on using its own highly customised
termcap file (ignoring the system's native terminfo database). I had to
write both terminfo and WP-tcap entries for every new kind of terminal
we bought.... It also had its own printer configuration goo, but that's
another story!
> Hum, I ddin't have enouth coffe when I wrote this - I meant the 'linux'
> terminal type. This one is harder because none of the standart term type seems
> to work rigth.
Ah, well, yes then the only solution is to copy the terminal type
database entries to the remote system. It's really no different in
concept than having any unique terminal type, whether it's a console
emulation or a real terminal.... If you really don't want to copy the
terminal type entries to all the remote systems you use then the only
viable alternative (i.e. other than ditching the terminal altogether) is
to use something like "screen" that provides terminal emulation of some
really widely known terminal type on your local system where hopefully a
full terminal definition for your unique terminal is available.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Wed, 17 May 2000 09:09:12 +0200
On Tue, May 16, 2000 at 03:48:13PM -0400, Greg A. Woods wrote:
> Nope. Those are two different classes of users. One's at least a
> junior sys-admin with the root password, the other's just a shell user.
>
> You don't need to be a superuser to set your terminal type and to
> provide the necessary terminal capabilities database entries, at least
> not on any Unix or unix-like system I've ever used....
Sure, so anybody can switch from vt220 to wsvt25 if he wants the extra
features. But stay with the more general type default.
> By necessity all terminfo systems have the tool(s) necessary to do the
> conversions (captoinfo, infocmp). Certainly this issue raises the bar a
> bit, but nothing anyone capable of reading a manual page should have any
> trouble with. It's quite likely that the remote system's administrator
> would be willing to help too, though of course this is where politics
> enters the picture! ;-)
>
> Except for a few weird and site-specific exceptions I've never seen any
> base vendor-supplied system software that required one to have both
> terminfo and termcap databases available simultaneously (at least not
> within any given "universe" -- Pyramid's dual universe system faithfully
I think on a NetBSD machine with a few ncurses-dependant packages installed
you need both, don't you ?
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
--
From: woods@weird.com (Greg A. Woods)
To: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
Date: Wed, 17 May 2000 21:09:54 -0400 (EDT)
[ On Wednesday, May 17, 2000 at 09:09:12 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: misc/10127: port i386 /etc/ttys says vt220 instead of wsvt25
>
> Sure, so anybody can switch from vt220 to wsvt25 if he wants the extra
> features. But stay with the more general type default.
In this case I am indeed inclined to agree since wsvt25 is supposedly a
proper superset of vt220.
> I think on a NetBSD machine with a few ncurses-dependant packages installed
> you need both, don't you ?
Actually, no, I don't think you really do, though that may be the
default way the current package installs. In theory at least ncurses
can use /usr/share/misc/termcap, though as it says in the manual "Use of
this feature is not recommended."
Personally I'd sure like to see termcap go the way of the dodo in
NetBSD, and I don't care whether that means using ncurses as-is or
re-inventing the important parts of it (silly as the latter might be).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
State-Changed-From-To: open->closed
State-Changed-By: ad@NetBSD.org
State-Changed-When: Tue, 13 May 2008 13:31:37 +0000
State-Changed-Why:
Changing it to wsvt25 is a bad idea because that's a very local termcap entry.
vt220 is well known. vt100 would be even better, but...
From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org,
gnats-admin@netbsd.org,
Andrew Doran <ad@NetBSD.org>,
perry@piermont.com
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 14:26:02 -0400
On 13-May-08, at 9:31 AM, ad@NetBSD.org wrote:
> Synopsis: port i386 /etc/ttys says vt220 instead of wsvt25
>
> State-Changed-From-To: open->closed
> State-Changed-By: ad@NetBSD.org
> State-Changed-When: Tue, 13 May 2008 13:31:37 +0000
> State-Changed-Why:
> Changing it to wsvt25 is a bad idea because that's a very local
> termcap entry.
> vt220 is well known. vt100 would be even better, but...
That makes little or no sense whatsoever.
If someone is using the console with any curses application then they
need the proper and best possible termcap definition for it.
If that same someone then remotely connects to another system from
their console session then they can at that time either choose to use
the best possible matching termcap definition provided on the remote
system for the curses applications run on that remote system, or
better yet they can export $TERMCAP from their console session to the
remote system.
Handicapping _all_ console users by default just to support those few
who are not doing things correctly when they connect to a remote
system from their console session is just not a good idea.
--
Greg A. Woods; Planix, Inc.
<woods@planix.ca>
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
perry@piermont.com
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 21:27:59 +0200
On Tue, May 13, 2008 at 06:30:05PM +0000, Greg A. Woods; Planix, Inc. wrote:
> > Synopsis: port i386 /etc/ttys says vt220 instead of wsvt25
> >
> > State-Changed-From-To: open->closed
> > State-Changed-By: ad@NetBSD.org
> > State-Changed-When: Tue, 13 May 2008 13:31:37 +0000
> > State-Changed-Why:
> > Changing it to wsvt25 is a bad idea because that's a very local
> > termcap entry.
> > vt220 is well known. vt100 would be even better, but...
>
> That makes little or no sense whatsoever.
>
> If someone is using the console with any curses application then they
> need the proper and best possible termcap definition for it.
>
> If that same someone then remotely connects to another system from
> their console session then they can at that time either choose to use
> the best possible matching termcap definition provided on the remote
> system for the curses applications run on that remote system, or
> better yet they can export $TERMCAP from their console session to the
> remote system.
>
> Handicapping _all_ console users by default just to support those few
> who are not doing things correctly when they connect to a remote
> system from their console session is just not a good idea.
I don't know much peoples who would think about changing $TERM
when connecting to a non-NetBSD box from a NetBSD console. I think using
vt220 by default is fine (and AFAIK curses applications are perfectly happy
with vt220 on a NetBSD console ...)
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org,
misc-bug-people@NetBSD.org,
gnats-admin@NetBSD.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 15:49:43 -0400
On 13-May-08, at 3:27 PM, Manuel Bouyer wrote:
>
> I don't know much peoples who would think about changing $TERM
> when connecting to a non-NetBSD box from a NetBSD console. I think
> using
> vt220 by default is fine (and AFAIK curses applications are
> perfectly happy
> with vt220 on a NetBSD console ...)
Learning to set $TERM appropriately when accessing remote systems
should be a beginner's Unix lesson. In fact that's one of the first
things anyone should learn once they get beyond basic "ls", "cp",
"mv", etc. kinds of things. Learning about exporting $TERMCAP goes
hand in hand with that too. If the remote system actually supports
$TERMCAP (and not terminfo, for example), then pasting "tset -EQs"
output from the local session into the remote session should be an
almost automatic behaviour.
BTW, if you look at the differences between the default vt220
definition (which is itself somewhat bastardized because it's not
exactly representing a DEC VT220 terminal) and the full wsvt25
definition I think you'll find many very important differences.
Perhaps simple applications like "vi" won't show any issues, but
others definitely will. I can't remember exactly what made me annoyed
because it wasn't working right, but as soon as I learned there was a
proper complete termcap definition for the actual wscons emulation and
I began to use that definition then all of my problems disappeared.
These days I personally don't use wscons much any more as most systems
I use have serial consoles.
BTW, also, there are some minor problems with the wsvt25 termcap entry
too that I keep meaning to send-pr. For example the "xn" hack should
be turned off, the initialization file (if) is not needed, the
initialization string should include "\E)0", and since libterm isn't
broken on NetBSD the continuation should be "vt220", not "vt220-8".
--
Greg A. Woods; Planix, Inc.
<woods@planix.ca>
From: "Perry E. Metzger" <perry@piermont.com>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 16:35:12 -0400
"Greg A. Woods; Planix, Inc." <woods@planix.ca> writes:
> BTW, if you look at the differences between the default vt220
> definition (which is itself somewhat bastardized because it's not
> exactly representing a DEC VT220 terminal) and the full wsvt25
> definition I think you'll find many very important differences.
> Perhaps simple applications like "vi" won't show any issues, but
> others definitely will.
I believe is right on this. I remember having problems because the two
aren't entirely compatible. That might argue for making wsvt25 more
like a vt220 though.
Perry
From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 17:44:33 -0400
On 13-May-08, at 4:35 PM, Perry E. Metzger wrote:
> That might argue for making wsvt25 more
> like a vt220 though.
That's definitely another good alternative to solving the problem,
though the vt220 is perhaps a less-than-ideal target, being that it
represents rather antiquated technology.
Matching xterm might be an even better target and a better solution to
the problem, even though it too goes through a whole lot of hoops for
bug-to-bug compatibility with ancient technology.
--
Greg A. Woods; Planix, Inc.
<woods@planix.ca>
From: "Perry E. Metzger" <perry@piermont.com>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 17:57:58 -0400
"Greg A. Woods; Planix, Inc." <woods@planix.ca> writes:
> Matching xterm might be an even better target and a better solution to
> the problem, even though it too goes through a whole lot of hoops for
> bug-to-bug compatibility with ancient technology.
Emulating a color xterm would, of course, be ideal, since then the
"log in to remote machine" problem etc. all go away and you get all
the features you want on the local box. If you can make that happen...
Perry
From: List Mail User <track@Plectere.com>
To: gnats-bugs@NetBSD.org, perry@piermont.com
Cc: gnats-admin@NetBSD.org, misc-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 15:25:38 -0700 (PDT)
>...
>"Greg A. Woods; Planix, Inc." <woods@planix.ca> writes:
>> Matching xterm might be an even better target and a better solution to
>> the problem, even though it too goes through a whole lot of hoops for
>> bug-to-bug compatibility with ancient technology.
>
>Emulating a color xterm would, of course, be ideal, since then the
>"log in to remote machine" problem etc. all go away and you get all
>the features you want on the local box. If you can make that happen...
>
>Perry
>
Please no. Despite my name sometimes being attached to it (someone
else actually deserves all of the credit/blame), color xterm is an awful
hack - a strange mix of VTxx/ANSI and MS/IBM escape sequences (and, unless
they've been fixed, there were some conflicts between the command sets).
BTW. The "original" xterm emulated a VT102, VT52 or Tek - all probably much
worse choices than either VT100 or VT220 for portability. (I think I added
some of the missing VT100 escape sequences in X11R5, but at least a few were
reverted/deleted in X11R6 or later in XFree86.)
Paul Shupak
From: "Perry E. Metzger" <perry@piermont.com>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Tue, 13 May 2008 19:59:43 -0400
<track@Plectere.com> writes:
> >Emulating a color xterm would, of course, be ideal, since then the
> >"log in to remote machine" problem etc. all go away and you get all
> >the features you want on the local box. If you can make that happen...
>
> Please no. Despite my name sometimes being attached to it (someone
> else actually deserves all of the credit/blame), color xterm is an awful
> hack
Awful hack or no, it is what every emulation window now runs. Better
to be compatible with it, ugly or not.
Perry
From: "Valeriy E. Ushakov" <uwe@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Wed, 14 May 2008 05:02:51 +0400
On Tue, May 13, 2008 at 19:55:02 +0000, Greg A. Woods; Planix, Inc. wrote:
> BTW, also, there are some minor problems with the wsvt25 termcap entry
> too that I keep meaning to send-pr. For example the "xn" hack should
> be turned off, the initialization file (if) is not needed, the
> initialization string should include "\E)0", and since libterm isn't
> broken on NetBSD the continuation should be "vt220", not "vt220-8".
"xn" hack should NOT be turned off. See wsemul_vt100_output_normal().
It was turned off by a patch from misc/34995 and it totally broke
emacs on console.
-uwe
From: David Holland <dholland-bugs@netbsd.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Wed, 14 May 2008 03:02:27 +0000
On Tue, May 13, 2008 at 05:57:58PM -0400, Perry E. Metzger wrote:
> "Greg A. Woods; Planix, Inc." <woods@planix.ca> writes:
> > Matching xterm might be an even better target and a better solution to
> > the problem, even though it too goes through a whole lot of hoops for
> > bug-to-bug compatibility with ancient technology.
>
> Emulating a color xterm would, of course, be ideal, since then the
> "log in to remote machine" problem etc. all go away and you get all
> the features you want on the local box. If you can make that happen...
Well, I don't know about that. I don't think I'm the only one who
finds applications using tty colors to be irredeemably ugly. (Why
hasn't anyone defined a way to get real color?)
Although mucking with $TERM isn't really the right way to shut off
unwanted colors; there should probably be a wscons setting for that.
It would also be nice if "wsvt25" were documented somewhere. It
doesn't seem to appear in any man page. (A comment in /etc/ttys would
be a good start. I'd commit one, but I'm not exactly sure what it
ought to say.)
--
David A. Holland
dholland@netbsd.org
From: "Perry E. Metzger" <perry@piermont.com>
To: David Holland <dholland-bugs@netbsd.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/10127 (port i386 /etc/ttys says vt220 instead of wsvt25)
Date: Wed, 14 May 2008 12:47:51 -0400
David Holland <dholland-bugs@netbsd.org> writes:
> > Emulating a color xterm would, of course, be ideal, since then the
> > "log in to remote machine" problem etc. all go away and you get all
> > the features you want on the local box. If you can make that happen...
>
> Well, I don't know about that. I don't think I'm the only one who
> finds applications using tty colors to be irredeemably ugly. (Why
> hasn't anyone defined a way to get real color?)
If it emulates xterm-color, you can just set the TERM to xterm and get
no color, thus making you happy.
> Although mucking with $TERM isn't really the right way to shut off
> unwanted colors; there should probably be a wscons setting for that.
>
> It would also be nice if "wsvt25" were documented somewhere. It
> doesn't seem to appear in any man page. (A comment in /etc/ttys would
> be a good start. I'd commit one, but I'm not exactly sure what it
> ought to say.)
Commit one. Just have it say "set these to wsvt25 if you want to get
all the console bells and whistles" or some such. It will mean that we
at least get something out of this whole PR.
--
Perry E. Metzger perry@piermont.com
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/10127 CVS commit: src/etc
Date: Wed, 13 Jun 2012 20:49:16 +0000
Module Name: src
Committed By: martin
Date: Wed Jun 13 20:49:15 UTC 2012
Modified Files:
src/etc/etc.acorn26: ttys
src/etc/etc.acorn32: ttys
src/etc/etc.alpha: ttys
src/etc/etc.amd64: ttys
src/etc/etc.amiga: ttys
src/etc/etc.amigappc: ttys
src/etc/etc.arc: ttys
src/etc/etc.atari: ttys
src/etc/etc.cats: ttys
src/etc/etc.evbarm: ttys
src/etc/etc.hp300: ttys
src/etc/etc.hpcarm: ttys
src/etc/etc.hpcmips: ttys
src/etc/etc.hpcsh: ttys
src/etc/etc.i386: ttys
src/etc/etc.ibmnws: ttys
src/etc/etc.iyonix: ttys
src/etc/etc.mac68k: ttys
src/etc/etc.mvmeppc: ttys
src/etc/etc.netwinder: ttys
src/etc/etc.newsmips: ttys
src/etc/etc.next68k: ttys
src/etc/etc.ofppc: ttys
src/etc/etc.pmax: ttys
src/etc/etc.prep: ttys
src/etc/etc.rs6000: ttys
src/etc/etc.sgimips: ttys
src/etc/etc.shark: ttys
src/etc/etc.zaurus: ttys
Log Message:
Per discussion on tech-userlevel, finally fix PR 10127:
move all ttyE* entries that use "vt100" emulation to wsvt25 term type.
The terminfo vt220 entry lacked (correctly) a delete key entry, which
was a regression against the netbsd-5 termcap entry. On the other hand,
only a very small number of foreign systems lacks support for wsvt25
nowadays.
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.acorn26/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.acorn32/ttys
cvs rdiff -u -r1.11 -r1.12 src/etc/etc.alpha/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.amd64/ttys
cvs rdiff -u -r1.23 -r1.24 src/etc/etc.amiga/ttys
cvs rdiff -u -r1.2 -r1.3 src/etc/etc.amigappc/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.arc/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.atari/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.cats/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbarm/ttys
cvs rdiff -u -r1.15 -r1.16 src/etc/etc.hp300/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.hpcarm/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.hpcmips/ttys
cvs rdiff -u -r1.10 -r1.11 src/etc/etc.hpcsh/ttys
cvs rdiff -u -r1.19 -r1.20 src/etc/etc.i386/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.ibmnws/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.iyonix/ttys
cvs rdiff -u -r1.19 -r1.20 src/etc/etc.mac68k/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.mvmeppc/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.netwinder/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.newsmips/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.next68k/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.ofppc/ttys
cvs rdiff -u -r1.14 -r1.15 src/etc/etc.pmax/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.prep/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.rs6000/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.sgimips/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.shark/ttys
cvs rdiff -u -r1.2 -r1.3 src/etc/etc.zaurus/ttys
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Jeff Rizzo" <riz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/10127 CVS commit: [netbsd-6] src
Date: Sun, 24 Jun 2012 18:04:43 +0000
Module Name: src
Committed By: riz
Date: Sun Jun 24 18:04:42 UTC 2012
Modified Files:
src/etc/etc.acorn26 [netbsd-6]: ttys
src/etc/etc.acorn32 [netbsd-6]: ttys
src/etc/etc.alpha [netbsd-6]: ttys
src/etc/etc.amd64 [netbsd-6]: ttys
src/etc/etc.amiga [netbsd-6]: ttys
src/etc/etc.amigappc [netbsd-6]: ttys
src/etc/etc.arc [netbsd-6]: ttys
src/etc/etc.atari [netbsd-6]: ttys
src/etc/etc.cats [netbsd-6]: ttys
src/etc/etc.evbarm [netbsd-6]: ttys
src/etc/etc.hp300 [netbsd-6]: ttys
src/etc/etc.hpcarm [netbsd-6]: ttys
src/etc/etc.hpcmips [netbsd-6]: ttys
src/etc/etc.hpcsh [netbsd-6]: ttys
src/etc/etc.i386 [netbsd-6]: ttys
src/etc/etc.ibmnws [netbsd-6]: ttys
src/etc/etc.iyonix [netbsd-6]: ttys
src/etc/etc.mac68k [netbsd-6]: ttys
src/etc/etc.mvmeppc [netbsd-6]: ttys
src/etc/etc.netwinder [netbsd-6]: ttys
src/etc/etc.newsmips [netbsd-6]: ttys
src/etc/etc.next68k [netbsd-6]: ttys
src/etc/etc.ofppc [netbsd-6]: ttys
src/etc/etc.pmax [netbsd-6]: ttys
src/etc/etc.prep [netbsd-6]: ttys
src/etc/etc.rs6000 [netbsd-6]: ttys
src/etc/etc.sgimips [netbsd-6]: ttys
src/etc/etc.shark [netbsd-6]: ttys
src/etc/etc.zaurus [netbsd-6]: ttys
src/share/terminfo [netbsd-6]: terminfo
Log Message:
Pull up following revision(s) (requested by martin in ticket #342):
etc/etc.shark/ttys: revision 1.8
etc/etc.hpcsh/ttys: revision 1.11
etc/etc.amiga/ttys: revision 1.24
etc/etc.arc/ttys: revision 1.8
etc/etc.alpha/ttys: revision 1.12
etc/etc.amigappc/ttys: revision 1.3
etc/etc.ofppc/ttys: revision 1.9
etc/etc.hp300/ttys: revision 1.16
etc/etc.rs6000/ttys: revision 1.2
etc/etc.i386/ttys: revision 1.20
etc/etc.acorn26/ttys: revision 1.4
etc/etc.iyonix/ttys: revision 1.4
etc/etc.netwinder/ttys: revision 1.8
etc/etc.mac68k/ttys: revision 1.20
etc/etc.evbarm/ttys: revision 1.7
etc/etc.pmax/ttys: revision 1.15
etc/etc.hpcmips/ttys: revision 1.10
share/terminfo/terminfo: revision 1.5
etc/etc.mvmeppc/ttys: revision 1.6
etc/etc.next68k/ttys: revision 1.10
etc/etc.acorn32/ttys: revision 1.9
etc/etc.ibmnws/ttys: revision 1.4
etc/etc.atari/ttys: revision 1.10
etc/etc.sgimips/ttys: revision 1.10
etc/etc.newsmips/ttys: revision 1.9
etc/etc.hpcarm/ttys: revision 1.6
etc/etc.cats/ttys: revision 1.7
etc/etc.amd64/ttys: revision 1.6
etc/etc.prep/ttys: revision 1.8
etc/etc.zaurus/ttys: revision 1.3
Per discussion on tech-userlevel, finally fix PR 10127:
move all ttyE* entries that use "vt100" emulation to wsvt25 term type.
The terminfo vt220 entry lacked (correctly) a delete key entry, which
was a regression against the netbsd-5 termcap entry. On the other hand,
only a very small number of foreign systems lacks support for wsvt25
nowadays.
Add a delete key capability to our wsvt25 entry. Fixes a problem noted by
David Lord on netbsd-users.
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.3.20.1 src/etc/etc.acorn26/ttys
cvs rdiff -u -r1.8 -r1.8.20.1 src/etc/etc.acorn32/ttys
cvs rdiff -u -r1.11 -r1.11.20.1 src/etc/etc.alpha/ttys
cvs rdiff -u -r1.5 -r1.5.20.1 src/etc/etc.amd64/ttys
cvs rdiff -u -r1.23 -r1.23.20.1 src/etc/etc.amiga/ttys
cvs rdiff -u -r1.2 -r1.2.20.1 src/etc/etc.amigappc/ttys
cvs rdiff -u -r1.7 -r1.7.20.1 src/etc/etc.arc/ttys
cvs rdiff -u -r1.9 -r1.9.20.1 src/etc/etc.atari/ttys
cvs rdiff -u -r1.6 -r1.6.20.1 src/etc/etc.cats/ttys
cvs rdiff -u -r1.6 -r1.6.20.1 src/etc/etc.evbarm/ttys
cvs rdiff -u -r1.15 -r1.15.6.1 src/etc/etc.hp300/ttys
cvs rdiff -u -r1.5 -r1.5.20.1 src/etc/etc.hpcarm/ttys
cvs rdiff -u -r1.9 -r1.9.20.1 src/etc/etc.hpcmips/ttys
cvs rdiff -u -r1.10 -r1.10.20.1 src/etc/etc.hpcsh/ttys
cvs rdiff -u -r1.19 -r1.19.20.1 src/etc/etc.i386/ttys
cvs rdiff -u -r1.3 -r1.3.20.1 src/etc/etc.ibmnws/ttys
cvs rdiff -u -r1.3 -r1.3.20.1 src/etc/etc.iyonix/ttys
cvs rdiff -u -r1.19 -r1.19.20.1 src/etc/etc.mac68k/ttys
cvs rdiff -u -r1.5 -r1.5.20.1 src/etc/etc.mvmeppc/ttys
cvs rdiff -u -r1.7 -r1.7.20.1 src/etc/etc.netwinder/ttys
cvs rdiff -u -r1.8 -r1.8.20.1 src/etc/etc.newsmips/ttys
cvs rdiff -u -r1.9 -r1.9.20.1 src/etc/etc.next68k/ttys
cvs rdiff -u -r1.8 -r1.8.4.1 src/etc/etc.ofppc/ttys
cvs rdiff -u -r1.14 -r1.14.20.1 src/etc/etc.pmax/ttys
cvs rdiff -u -r1.7 -r1.7.20.1 src/etc/etc.prep/ttys
cvs rdiff -u -r1.1 -r1.1.10.1 src/etc/etc.rs6000/ttys
cvs rdiff -u -r1.9 -r1.9.20.1 src/etc/etc.sgimips/ttys
cvs rdiff -u -r1.7 -r1.7.20.1 src/etc/etc.shark/ttys
cvs rdiff -u -r1.2 -r1.2.20.1 src/etc/etc.zaurus/ttys
cvs rdiff -u -r1.4 -r1.4.4.1 src/share/terminfo/terminfo
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home