Setting 132 columns in Solaris
Shiva MahaDeva
like I issue "set terminal/width=132" in OpenVMS ?
Thanks in advance.
Rich Teer
> How could I setting a terminal emulator to 132 columns in Solaris,
> like I issue "set terminal/width=132" in OpenVMS ?
WHich terminal emulator? For dtterm, I have this line in my
.Xdefaults file:
Dtterm*geometry: 132x24
I imagine that other terminal emulators have a similar resource.
HTH,
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
Anton Rang
> How could I setting a terminal emulator to 132 columns in Solaris,
> like I issue "set terminal/width=132" in OpenVMS ?
The command
stty columns 132
will change it on the host side. There isn't a standard way to send
the command sequence to request that the terminal automatically switch
as well, though.
Anton
Dennis Clarke
From the command line :
TERM=vt100;LINES=50;COLUMNS=132;export TERM LINES COLUMNS
will generally work well in xterm.
dc
Richard S. Shuford
|
| How could I setting a terminal emulator to 132 columns in Solaris,
| like I issue "set terminal/width=132" in OpenVMS ?
Anton Rang <rang%visi.com> replied:
>
> The command
> $ stty columns 132
> will change it on the host side. There isn't a standard way to send
> the command sequence to request that the terminal automatically switch
> as well, though.
The VMS DCL command "SET TERMINAL/WIDTH=132" does two things:
(1) set the operating system's opinion of the terminal's width to 132 columns
(2) send an Escape sequence that causes a DEC VTx00 terminal to configure
its screen buffer to actually display 132 characters horizontally
The Unix command "stty columns 132" performs only thing (1).
For thing (2), while there is no "de jure" ANSI standard for switching the
visible screen width, there is yet a widely implemented mechanism, based
on the control codes implemented in the DEC VT220 video terminal (and in
later DEC terminal products).
If "xterm" is being used, then the "Allow 132/80 Column Switching" option
must be enabled from the "VT Options" menu. (This screen menu is accessed
by holding down the Control key and pressing the middle mouse button.) Then
some software running on the Unix host can cause (2) to happen by sending
the DECCOLM Escape sequence:
Esc [ ? 3 h
In Solaris, the "some software" may consist of this simple one-line command:
$ printf "\033[?3h"
The control sequence to reset/clear the screen size back to 80 columns is:
Esc [ ? 3 l
$ printf "\033[?3l"
(where 'l' is a lowercase 'L').
Finally, you must reset the operating system's opinion to 80 columns like this:
$ stty columns 80
Archived information on related topics may be found here:
http://www.cs.utk.edu/~shuford/terminal_index.html
--
...Richard S. Shuford
shuford(at)list.stratagy.com
Thomas Dickey
> From the command line :
only for termcap-based applications.
since the current newsgroup is solaris, that only addresses obsolete programs.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Thomas Dickey
> For thing (2), while there is no "de jure" ANSI standard for switching the
> visible screen width, there is yet a widely implemented mechanism, based
> on the control codes implemented in the DEC VT220 video terminal (and in
> later DEC terminal products).
But on Solaris, the supported terminal program (so I'm told) is dtterm.
That recognizes also a different escape sequence. Oddly Solaris' xterm
doesn't seem to recognize this (though some of Solaris' manpages haven't
been updated since Solaris 2.3 - I noticed several instances today ;-).
"man resize" mentions this feature:
-s [rows columns]
This option indicates that Sun console escape
sequences will be used instead of the special xterm
escape code. If rows and columns are given, resize
will ask the xterm to resize itself. However, the
window manager may choose to disallow the change.
I added that feature to XFree86 xterm a while back. It's very convenient
for resizing the terminal, e.g.,
resize -s 45 80
to get 45 rows by 80 columns.
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Dennis Clarke <dcl...@blastwave.org> wrote:
>> On Wed, 5 Nov 2003, Shiva MahaDeva wrote:
>>>How could I setting a terminal emulator to 132 columns in Solaris,
>>>like I issue "set terminal/width=132" in OpenVMS ?
>>>
>>>Thanks in advance.
>
>> From the command line :
>
>> TERM=vt100;LINES=50;COLUMNS=132;export TERM LINES COLUMNS
>
>> will generally work well in xterm.
>
>only for termcap-based applications.
>since the current newsgroup is solaris, that only addresses obsolete programs.
Since termcap is portable in contrary to terminfo (*), I would not call
termcap based applications obsolete - all my self written applications
are based on a self written termcap implementation.
But I don't understand why setting LINES/COLUMNS should have any effect....
*) terminfo is binary and would only be portable if there was a single central
institituion that coordinates terminfo content. Try to do something similar
to using ~/.termcap with a universally working xterm entry when
uning terminfo.....
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Dennis Clarke
> TERM=vt100;LINES=50;COLUMNS=132;export TERM LINES COLUMNS
I don't know "why" it always works for me, I only know that it does.
At the moment I am watching a system with my terminal session set to 60 lines
and 132 columns.
LINES=60;COLUMNS=132;export LINES COLUMNS
.. works perfectly.
dc
Thomas Dickey
> Since termcap is portable in contrary to terminfo (*), I would not call
since you're starting off by asserting a fallacy, you're wasting bandwidth again
Thomas Dickey
> *) terminfo is binary and would only be portable if there was a single central
> institituion that coordinates terminfo content. Try to do something similar
> to using ~/.termcap with a universally working xterm entry when
> uning terminfo.....
rofl
Thomas Dickey
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> *) terminfo is binary and would only be portable if there was a single central
>> institituion that coordinates terminfo content. Try to do something similar
>> to using ~/.termcap with a universally working xterm entry when
>> uning terminfo.....
>
>rofl
Ignorance doesn't change facts.....
Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
machine?
Decompiling the Solaris entries and re-compiling it on HP-UX didn't work either
Using 'vi' on HP-UX from a remote login from Solaris t HP-UX did completely
srew up the window.....
Having a file ~/.termcap with corrected entries for the broken entries and using
termcap and a termcap based editor instead of terminfo seems to be the solution.
Richard S. Shuford
|
| How could I setting a terminal emulator to 132 columns in Solaris,
| like I issue "set terminal/width=132" in OpenVMS ?
Then Richard S. Shuford wrote:
>
> For thing (2), while there is no "de jure" ANSI standard for switching the
> visible screen width, there is yet a widely implemented mechanism, based
> on the control codes implemented in the DEC VT220 video terminal (and in
> later DEC terminal products).
And then Thomas Dickey <dickey%saltmine.radix.net> wrote:
+
+ But on Solaris, the supported terminal program (so I'm told) is dtterm.
+ That recognizes also a different escape sequence. Oddly Solaris' xterm
+ doesn't seem to recognize this....
Hi, Thomas,
Recent releases of Solaris have included Sun-supported versions of
both "xterm" and "dtterm". However, with Sun moving away from the
committee-compromise "Common Desktop Environment" and toward the
Gnome windowing environment, the CDE "dtterm" program is becoming
less important. (And "cmdtool" is even further out of mind, whereas
Gnome Terminal is becoming more important.)
Noting that Shiva said merely "a terminal emulator", it is not clear
what software is being used. Possibly it could be some program
running under Windows and not any of the above Unix/Linux packages.
(I picked "xterm" because it is fairly typical of a decent VT100
emulator.)
But, you do raise an issue that I forgot. By default, the Solaris
"dtterm" program will ignore the DECCOLM control sequence. However,
there is an invocation option to make "dtterm" honor DECCOLM, which
the user can choose like this:
$ /usr/dt/bin/dtterm -132
(In Solaris 8 and 9, this is documented in the dtterm man page.)
Another variant control sequence was developed by Digital Equipment
Corporation for its real DEC VT330 terminals (and is used in later DEC
and/or Boundless terminal models and faithful emulators of them). To
support multiple screen-page memory in the terminal, DEC invented a
more generalized screen-sizing feature: the command sequence is called
DECSCPP (DEC Set Columns Per Page).
For switching to 132 columns, the DECSCPP sequence (without the
intervening spaces) would be:
Esc [ 1 3 2 $ |
(Using a Unix shell command to emit the '$' dollar and '|' pipe
characters, without interpreting them, can require tricky quoting.)
To reset/clear the VT330 to the default of 80 columns, any of these
work:
Esc [ $ |
Esc [ 0 $ |
Esc [ 8 0 $ |
According to the documentation, the VT330 also supports an analogous
DECSLPP (DEC Set Lines Per Page) control sequence, to allow screen
pages containing 24, 36, 72, or 144 (!?) lines.
Esc [ 2 4 t
Esc [ 3 6 t
Esc [ 7 2 t
Esc [ 1 4 4 t
Additional video-terminal lore resides here:
http://www.cs.utk.edu/~shuford/terminal_index.html
...RSS
Thomas Dickey
> In article <boj7r3$hc1$2...@news1.radix.net>,
> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> *) terminfo is binary and would only be portable if there was a single central
>>> institituion that coordinates terminfo content. Try to do something similar
>>> to using ~/.termcap with a universally working xterm entry when
>>> uning terminfo.....
>>
>>rofl
> Ignorance doesn't change facts.....
indeed: learn something, so you won't be.
> Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
> machine?
no, I'm not stupid.
I use the portable approach, decompiling and compiling.
Judging by your comments, it would be fitting if you prefer programming in
Basic versus C, since the latter is more often compiled than the former.
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> In article <boj7r3$hc1$2...@news1.radix.net>,
>> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>> *) terminfo is binary and would only be portable if there was a single central
>>>> institituion that coordinates terminfo content. Try to do something similar
>>>> to using ~/.termcap with a universally working xterm entry when
>>>> uning terminfo.....
>>>
>>>rofl
>
>> Ignorance doesn't change facts.....
>
>indeed: learn something, so you won't be.
Looks like you never heard of the concept of having a NFS mounted home directory
that is used between different architectures. It is really bad to see that the
only way to understand your behavior is that you don't like to learn :-(
>> Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
>> machine?
>
>no, I'm not stupid.
If this was true, why then are you writing things that contradict your own
writings?
>I use the portable approach, decompiling and compiling.
This contradicts your previous writings!
So you either did not understand what I was writing or you are unwilling to do
so :-(
Sometimes you are unable to fix broken termcap or terminfo databases on a
specific OS. The only way to work on such a OS is to have your own corrected
data base in your home directory.
You just did admit that with terminfo you cannot use a binary data base on
different platforms. So you admit that terminfo is nonportable. Why then did you
start to tell us that this is wrong in an earlier posting from you?
There is no problem when you use termcap. As I did write before: Just keep
a file .termcap in your home directory and use a termcap implementation that
offers the TERMPATH property. ~/.termcap is searched for the current $TERM
before /etc/termcap or whereever the official data base of the system is
located. termcap is absolute platform independant. You only need one termcap data
base file for all supported platforms. Terminfo is not. You would need to
compile your corrected terminfo entries. The HP-UX 'tic' does not even accept
the 'source' form of a Solaris terminfo entry.... even if you succeed, you
would need a separate compiled directory tree for every platform you may use
with your NFS mounted home directory.
>Judging by your comments, it would be fitting if you prefer programming in
>Basic versus C, since the latter is more often compiled than the former.
You write contradictions, why should people believe that you are able to judge
other people? Barfing at people like you did, never is a good idea.
I wish that you are not a hopeless case.....
Dennis Clarke
> I wish that you are not a hopeless case.....
Not hopeless .. but a waste of time.
Ignore him .. there are better ways to spend your valuable time.
dc
Thomas Dickey
--
Thomas Dickey
> Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
> machine?
> Decompiling the Solaris entries and re-compiling it on HP-UX didn't work either
actually it does work - start by reading the manpages.
(apparently there's not enough bandwidth to educate you).
Thomas Dickey
> This contradicts your previous writings!
> So you either did not understand what I was writing or you are unwilling to do
> so :-(
I understood your posting. It was quite ignorant to start in a Solaris
thread asserting that you're using termcap. Do you use Solaris, or are
you just fond of typing? (Apparently the latter).
ldd shows (read the manpage):
/usr/bin/vi:
libmapmalloc.so.1 => /usr/lib/libmapmalloc.so.1
libcurses.so.1 => /usr/lib/libcurses.so.1
libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
strings (on libcurses) shows
TERM
TERMINFO
/usr/share/lib/terminfo/
(don't waste my time if you choose to be ignorant)
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>
>> This contradicts your previous writings!
>> So you either did not understand what I was writing or you are unwilling to do
>> so :-(
>
>I understood your posting. It was quite ignorant to start in a Solaris
Really? ^^^^^^^
It seems that you used a superfluous 't' here.
>thread asserting that you're using termcap. Do you use Solaris, or are
>you just fond of typing? (Apparently the latter).
>
>ldd shows (read the manpage):
>
>/usr/bin/vi:
> libmapmalloc.so.1 => /usr/lib/libmapmalloc.so.1
> libcurses.so.1 => /usr/lib/libcurses.so.1
> libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1
> libgen.so.1 => /usr/lib/libgen.so.1
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
>
>strings (on libcurses) shows
>
>TERM
>TERMINFO
>/usr/share/lib/terminfo/
>
>(don't waste my time if you choose to be ignorant)
******
Thank you for shortening this discussion, you just did verify that you are
ignorant!
******
As I did write before, I am using my own portable termcap implementation....
ldd /opt/schily/bin/ved
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
strings /opt/schily/bin/ved | grep -i TERM
Bad line length or page size in terminal descriptor.
missing terminal cap: %s
missing terminal cap:
TERM
Cannot open termcap file.
Cannot find terminal type: %s.
VED_DBGTERM
@(#)terminal.c
TERM
TERMCAP
TERMPATH
.termcap /etc/termcap
Termcap entry too long
Bad termcap entry
No memory for parsing termcap
VED is based on libxtermcap which is written by me.
http://www.blastwave.org/packages.php
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
>> machine?
>
>> Decompiling the Solaris entries and re-compiling it on HP-UX didn't work either
>
>actually it does work - start by reading the manpages.
Aha, did you try this on a 1996 HP-UX?
I _did_ read the man pages and spend 3 hours in trying to get it work.
Later I decided to port my 'ved' to HP-UX - it took half an hour....
I am still in hope that this "discussion" with you is not a waste of bandwidth
and you finally understand that terminfo was a step into the wrong direction -
mainly triggered by the fact that the old V7 filesystemcode used by AT&T was
slow in reading large files.
In addition, it seems that people at AT&T when working on terminfo did not
understand that reading the termcap data base is a duty of the shell at login
time, so this is done only once in a login session. My shell does this since
1984.
Thomas Dickey
> Recent releases of Solaris have included Sun-supported versions of
> both "xterm" and "dtterm". However, with Sun moving away from the
I was more/less aware of that. There was a comment in this newsgroup
a year or two ago regarding a Solaris-specific performance improvement
which was in xterm. (Not detailed enough for me to make the same change,
but enough to see that Sun was making changes that aren't in the X/Open
version).
> committee-compromise "Common Desktop Environment" and toward the
> Gnome windowing environment, the CDE "dtterm" program is becoming
> less important. (And "cmdtool" is even further out of mind, whereas
> Gnome Terminal is becoming more important.)
( supporting Gnome Terminal may be challenging ;-)
> Noting that Shiva said merely "a terminal emulator", it is not clear
> what software is being used. Possibly it could be some program
> running under Windows and not any of the above Unix/Linux packages.
> (I picked "xterm" because it is fairly typical of a decent VT100
> emulator.)
I was thinking mostly of dtterm, since it's what is normally run as "terminal"
(but don't have a Solaris 9 to adjust my expectations about that).
> But, you do raise an issue that I forgot. By default, the Solaris
> "dtterm" program will ignore the DECCOLM control sequence. However,
> there is an invocation option to make "dtterm" honor DECCOLM, which
> the user can choose like this:
>
> $ /usr/dt/bin/dtterm -132
> (In Solaris 8 and 9, this is documented in the dtterm man page.)
That applies to xterm as well.
> Another variant control sequence was developed by Digital Equipment
> Corporation for its real DEC VT330 terminals (and is used in later DEC
> and/or Boundless terminal models and faithful emulators of them). To
> support multiple screen-page memory in the terminal, DEC invented a
> more generalized screen-sizing feature: the command sequence is called
> DECSCPP (DEC Set Columns Per Page).
It is more generalized - but as you note, apparently limited to specific
values of columns and rows. (I implemented something based on this in
XFree86 xterm, but omitting the limit - easier to do with a software terminal
emulator than a piece of hardware).
Thomas Dickey
> In article <bok6b0$ib6$2...@news1.radix.net>,
> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
>>> machine?
>>
>>> Decompiling the Solaris entries and re-compiling it on HP-UX didn't work either
>>
>>actually it does work - start by reading the manpages.
> Aha, did you try this on a 1996 HP-UX?
man untic
man infocmp
(reading the manpage of course assumes the appropriate one)
> I _did_ read the man pages and spend 3 hours in trying to get it work.
> Later I decided to port my 'ved' to HP-UX - it took half an hour....
hardcoded programs do have a few (very few) advantages.
Thomas Dickey
> In addition, it seems that people at AT&T when working on terminfo did not
> understand that reading the termcap data base is a duty of the shell at login
> time, so this is done only once in a login session. My shell does this since
> 1984.
In the context of this thread, that's asserting that it updates $LINES and
$COLUMNS and $TERMCAP whenever the screensize changes.
Thomas Dickey
> As I did write before, I am using my own portable termcap implementation....
> ldd /opt/schily/bin/ved
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
it's not vi.
(I've read the source for ved, don't see anything I'd want to use)
Thomas Dickey
> I had no problems just ftp'ing the dtterm terminfo binary to all the
> HP/UX systems so I could have the SUN dtterm recognized when I
> rlogged-in from a SUN box to an HP box.
hmm - which version of HP/UX? The binaries are structurally similar,
but the order & contents of the string table differ. It's trivial to
decompile.
> So, what's the problem here? Idologies? Soapboxen? C vs. Basic? Java
> vs. C++? Yawn...
just swatting a mosquito...
Thomas Dickey
> In article <bom716$k80$1...@news1.radix.net>,
> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>> "Michael wrote:
>>
>> > I had no problems just ftp'ing the dtterm terminfo binary to all the
>> > HP/UX systems so I could have the SUN dtterm recognized when I
>> > rlogged-in from a SUN box to an HP box.
>>
>> hmm - which version of HP/UX? The binaries are structurally similar,
>> but the order & contents of the string table differ. It's trivial to
>> decompile.
> 9.0<something>, 10.20, 11.<something>. No problems.
I'm pretty sure it's not without problem, since I set up mapping tables
to do the translation. If you're not using line-drawing characters,
you generally won't notice: the lower function keys have the same offsets.
However, function keys starting with F11, and colors won't work. So
copying the binary will give a result adequate for running vi, but not
for much more than that.
I'm reading from a table that I made for HPUX 11.something - the same issue
with line-drawing characters applies to 9.something, but I don't have a nice
table to quote from.
Alan Coopersmith
|In comp.unix.solaris Richard S. Shuford
|<shu...@list.stratagy.rem0ve-th1s-part.com> wrote:
|
|> Recent releases of Solaris have included Sun-supported versions of
|> both "xterm" and "dtterm". However, with Sun moving away from the
|
|I was more/less aware of that. There was a comment in this newsgroup
|a year or two ago regarding a Solaris-specific performance improvement
|which was in xterm. (Not detailed enough for me to make the same change,
|but enough to see that Sun was making changes that aren't in the X/Open
|version).
For Solaris 2.6 through 8, xterm is basically the X11R6 version. For
Solaris 9 it was upgraded to the l18nux.org (now openi18n.org) version,
with yours/XFree86 supplied on the unsupported freeware companion CD.
I'm not sure what comment or fix you're referring to, but if there's
something you think can be of benefit, let me know and I can look to
see if there's something there we can contribute. (We contribute fixes
to both X.org & XFree86 now, though the process of going through our
code and finding changes that would be beneficial to contribute is
slow going since it's a lot of work and not our highest priority.
XFree86 4.4 will contain a number of Sun-contributed fixes and the IPv6
work from Sun.)
--
________________________________________________________________________
Alan Coopersmith al...@alum.calberkeley.org
http://www.CSUA.Berkeley.EDU/~alanc/ aka: Alan.Coo...@Sun.COM
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Thomas Dickey
> Thomas Dickey <dic...@saltmine.radix.net> writes in comp.unix.solaris:
> |In comp.unix.solaris Richard S. Shuford
> |<shu...@list.stratagy.rem0ve-th1s-part.com> wrote:
> |
> |> Recent releases of Solaris have included Sun-supported versions of
> |> both "xterm" and "dtterm". However, with Sun moving away from the
> |
> |I was more/less aware of that. There was a comment in this newsgroup
> |a year or two ago regarding a Solaris-specific performance improvement
> |which was in xterm. (Not detailed enough for me to make the same change,
> |but enough to see that Sun was making changes that aren't in the X/Open
> |version).
> For Solaris 2.6 through 8, xterm is basically the X11R6 version. For
> Solaris 9 it was upgraded to the l18nux.org (now openi18n.org) version,
> with yours/XFree86 supplied on the unsupported freeware companion CD.
> I'm not sure what comment or fix you're referring to, but if there's
I was recalling one of your postings - but checking now, I'm misquoting it.
The posting commented that dtterm had been modified to use a SolarisIA
extension (makes subprocesses get a priority boost), but went on to say that
xterm was not modified. This was in April 2002.
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> In article <bok6b0$ib6$2...@news1.radix.net>,
>> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>> Did you ever try to use a binary terminfo database taken from Solaris on a HP-UX
>>>> machine?
>>>
>>>> Decompiling the Solaris entries and re-compiling it on HP-UX didn't work either
>>>
>>>actually it does work - start by reading the manpages.
>
>> Aha, did you try this on a 1996 HP-UX?
>
>man untic
>man infocmp
Guess what I did!
This was most likely a HP-UX 8.x (what has been on a HP ATM tester)
TERM=sun-cmd
When you call 'vi' on HP-UX, it immediately sets scrolling to one line only.
HP-UX 'tic' gives many 'errors' for the disassembled Solaris 'sun-cmd'
output.....
>(reading the manpage of course assumes the appropriate one)
Do you still like a fight? If you like a serious discussion, it does not help
to write useless things like you do...
>> I _did_ read the man pages and spend 3 hours in trying to get it work.
>> Later I decided to port my 'ved' to HP-UX - it took half an hour....
>
>hardcoded programs do have a few (very few) advantages.
How about writing in a way that people may understand you?
What is hardcoded?
VED is not hardcoded, it implements a clean layered termcap interface....
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>
>> In addition, it seems that people at AT&T when working on terminfo did not
>> understand that reading the termcap data base is a duty of the shell at login
>> time, so this is done only once in a login session. My shell does this since
>> 1984.
>
>In the context of this thread, that's asserting that it updates $LINES and
>$COLUMNS and $TERMCAP whenever the screensize changes.
Do you know how tgetent() works? It does not sees so.....
Since around 1983, there was SIGWINCH & ioctl(STDOUT_FILENO, TIOCGSIZE,
tgetent() did call ioctl(STDOUT_FILENO, TIOCGSIZE, and modified the
TERMCAP string to reflect the current size, and so does my termcap
implementation used by ved and bsh.
A editor does not need to read /etc/termcap completely as the compressed
termcap entry is in TERMCAP=, tgetent() only has to modify 'co#' and 'li#'.
Joerg Schilling
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> As I did write before, I am using my own portable termcap implementation....
>
>> ldd /opt/schily/bin/ved
>> libc.so.1 => /usr/lib/libc.so.1
>> libdl.so.1 => /usr/lib/libdl.so.1
>
>it's not vi.
>(I've read the source for ved, don't see anything I'd want to use)
Well, your 'vile' is not 'vi' too. Even worse: it looks like 'vi'
but it does not correctly implement important basic commands like
ESC:w
.... so 'vile' is nothing I would like to use.
Joerg Schilling
Michael Vilain <vil...@spamcop.net> wrote:
>I had no problems just ftp'ing the dtterm terminfo binary to all the
>HP/UX systems so I could have the SUN dtterm recognized when I
>rlogged-in from a SUN box to an HP box.
I hope you know that dtterm is a bit later than the time when I did
try with 'sun-cmd'. As HP and Sun did both work on CDE, it is no wonder that
after CDE has been available thinks did look different....
Thomas Dickey
> Do you know how tgetent() works? It does not sees so.....
awai: you don't know much about research either...
Thomas Dickey
> In article <boljmt$1ki$4...@news1.radix.net>,
> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>> As I did write before, I am using my own portable termcap implementation....
>>
>>> ldd /opt/schily/bin/ved
>>> libc.so.1 => /usr/lib/libc.so.1
>>> libdl.so.1 => /usr/lib/libdl.so.1
>>
>>it's not vi.
>>(I've read the source for ved, don't see anything I'd want to use)
> Well, your 'vile' is not 'vi' too. Even worse: it looks like 'vi'
awai: sigh. repeating: read the manpage.
> .... so 'vile' is nothing I would like to use.
good. then you won't waste my time, reminding you to read the documentation