ANSI terminal emulators for linux

Am 02.11.2016 um 19:21 schrieb Tim Wescott:

> This throws me, and I'm sorry I didn't mention it.  In Windows-land, a
> "terminal emulator" is a program that makes your computer emulate a
> serial terminal.

Hmmm... I've only ever seen those called "terminal program" --- a  breed 
including what was arguably the most broken pre-installed Windows 
utility ever, aptly nicknamed "Hypoterminal", because there was really 
nothing "Hyper" about it.

> In Unix-land, a "terminal emulator" is a program that
> runs under X and emulates the serial terminal that the operating system
> was originally designed to talk to.  So, they're two entirely different
> things with the same name.

There are terminal emulators like that on Windows, too, e.g. MinTTY or 
the ported rxvt.  And if all else breaks, one can always run X11 on 
Windows, including xterm.

PuTTY by comparison is a multi-tool serving as a terminal program, 
telnet, rsh and ssh clients, and a Unix-style terminal emulator, too. 
It really has to pack all those into one tool to be useful, since 
Windows itself provides none of them.  Even Telnet is absent in a normal 
install.

> The thing known in Windows-land as a "terminal emulator" is known in Unix-
> land as a "serial communications program".  The Unix-land "terminal
> emulator" is the Windows-land "DOS window" or perhaps "command-line
> window".

Windows itself calls them "consoles", and it interjects its own native 
terminal emulator automatically whenever a console application (i.e. a 
normal C program with a main() function) is executed by anything that 
isn't already running in a console.  It has to do that because Windows 
GUI programs otherwise have no connection to any console, i.e. no 
"controlling pty".

On 2016-11-02, David Brown <david.brown@hesbynett.no> wrote:
> On 02/11/16 18:22, Syd Rumpo wrote:
>> I use multiple instances of TeraTerm in Windows to provide ANSI/VT100
>> emulation for embedded processor diagnostics using serial USB
>> converters.  It's not unusual to have six running at once.
>>
>> What are my best options in Linux, specifically Peppermint 7?  I don't
>> want lots of clutter, just setup to eg 38k4 baud, ANSI emulation with
>> screens to type in and display text stuff.  It's not full ANSI, just
>> cursor-moving escape codes and the like.
>
> Like Don, I use screen (with Linux, rather than BSD).  Using different 
> colours for the windows is not a bad idea at all.
>
> 	screen /dev/ttySerial_hub2 115200

Wow, I didn't know screen would talk directly to serial ports.

The description of that feature is hidden 2000+ lines into the man
page under the heading "Window Types".  And I've been using screen for
a _long_ time (30 years) -- since before Linux was born. I first used
screen when I ported it to a 16-bit Unix v7 clone called Coherent that
I was running on an 8MHz IBM-AT with an 80268:

https://en.wikipedia.org/wiki/Coherent_%28operating_system%29

[And before I could port screen to Coherent, I first had to write a
pty driver, since Coherent didn't have ptys at the time.]

The interesting thing about screen is that it _is_ a terminal
emulator, but it doesn't run in a graphical window (like xterm or
putty), but instead runs on top of another terminal (either an
emulator or a real serial terminal).  IOW, it emulates a VT1xx/ANSI
terminal on top of whatever type of termial you actually have.  Back
in the day, if you happened to be using some oddball non-ANSI
terminal, and wanted to use a program that was hard-wired to expect an
ANSI terminal, screen was a life-saver.

The multi-window and session-disconnect/reconnect is pretty cool
too...

-- 
Grant Edwards               grant.b.edwards        Yow! -- I love KATRINKA
                                  at               because she drives a
                              gmail.com            PONTIAC.  We're going
                                                   away now.  I fed the cat.

On 02/11/16 22:23, Grant Edwards wrote:
> On 2016-11-02, David Brown <david.brown@hesbynett.no> wrote:
>> On 02/11/16 18:22, Syd Rumpo wrote:
>>> I use multiple instances of TeraTerm in Windows to provide ANSI/VT100
>>> emulation for embedded processor diagnostics using serial USB
>>> converters.  It's not unusual to have six running at once.
>>>
>>> What are my best options in Linux, specifically Peppermint 7?  I don't
>>> want lots of clutter, just setup to eg 38k4 baud, ANSI emulation with
>>> screens to type in and display text stuff.  It's not full ANSI, just
>>> cursor-moving escape codes and the like.
>>
>> Like Don, I use screen (with Linux, rather than BSD).  Using different 
>> colours for the windows is not a bad idea at all.
>>
>> 	screen /dev/ttySerial_hub2 115200
> 
> Wow, I didn't know screen would talk directly to serial ports.
> 
> The description of that feature is hidden 2000+ lines into the man
> page under the heading "Window Types".  

I can't claim any credit for finding it on the man page - I read about
it on a website somewhere, and realised it does exactly what I need for
a terminal emulator on a serial port.  I had been using screen for a
decade or so before I found out that it can talk to the serial port.

And you can still do normal "screen" things with it while using a serial
port, like have multiple virtual windows, connect to it from a different
computer in parallel, or do logging.

> And I've been using screen for
> a _long_ time (30 years) -- since before Linux was born. I first used
> screen when I ported it to a 16-bit Unix v7 clone called Coherent that
> I was running on an 8MHz IBM-AT with an 80268:
> 
> https://en.wikipedia.org/wiki/Coherent_%28operating_system%29
> 
> [And before I could port screen to Coherent, I first had to write a
> pty driver, since Coherent didn't have ptys at the time.]

I think you are the second person I have ever heard of who ran Coherent!

> 
> The interesting thing about screen is that it _is_ a terminal
> emulator, but it doesn't run in a graphical window (like xterm or
> putty), but instead runs on top of another terminal (either an
> emulator or a real serial terminal).  IOW, it emulates a VT1xx/ANSI
> terminal on top of whatever type of termial you actually have.  Back
> in the day, if you happened to be using some oddball non-ANSI
> terminal, and wanted to use a program that was hard-wired to expect an
> ANSI terminal, screen was a life-saver.
> 
> The multi-window and session-disconnect/reconnect is pretty cool
> too...
> 

One of the main things I use "screen" for is when connecting by ssh to a
server.  I can happily run long-term tasks within screen - it doesn't
matter if my ssh session dies, or if I want to move between by office
machine, my home machine, my mobile with JuiceSSH, or whatever.

Grant Edwards <invalid@invalid.invalid> writes:

> I recommend ckermit, which isn't a terminal emulator, just a
> rock-solid serial comm program.

I like ckermit too but considering I first used it back in 1986 and the
UI hasn't changed much I wouldn't recommend it to anyone not already
familiar with it. Same goes for Emacs whose serial-term is fine for
basic use.

So I guess for ease of use for someone coming from Windows it's putty.

Thanks for all the helpful suggestions, guys.

Cheers
-- 
Syd

On 11/3/2016 2:47 AM, Anssi Saari wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
>
>> I recommend ckermit, which isn't a terminal emulator, just a
>> rock-solid serial comm program.
>
> I like ckermit too but considering I first used it back in 1986 and the
> UI hasn't changed much I wouldn't recommend it to anyone not already
> familiar with it. Same goes for Emacs whose serial-term is fine for
> basic use.
>
> So I guess for ease of use for someone coming from Windows it's putty.

While its NOT what the OP has requested (i.e., he's looking to run
under UN*X), IMO, one of the best tools under Windows (i.e., if
PuTTY comes to mind) is XShell.  Very slick -- esp if purchased
as part of the XManager suite!

On 2016-11-02, Tim Wescott <seemywebsite@myfooter.really> wrote:
>
> This throws me, and I'm sorry I didn't mention it.  In Windows-land, a 
> "terminal emulator" is a program that makes your computer emulate a 
> serial terminal.  In Unix-land, a "terminal emulator" is a program that 
> runs under X and emulates the serial terminal that the operating system 
> was originally designed to talk to.  So, they're two entirely different 
> things with the same name.  
>
> The thing known in Windows-land as a "terminal emulator" is known in Unix-
> land as a "serial communications program".  The Unix-land "terminal 
> emulator" is the Windows-land "DOS window" or perhaps "command-line 
> window".
>

No (IMHO anyway :-)). I think you are confusing the application (which is
designed to emulate a physical terminal) with the back end connectivity
options implemented within that application.

For example, PuTTY on Windows only has remote connectivity (network and
serial) options available due to Windows limitations.

PuTTY on Linux also has that but it also has an additional back end
connectivity option which allows direct connection to a pty and hence
to a shell running on the local machine. (This is implemented using
the pterm program if you didn't already know about it).

Likewise, various other Linux based terminal emulators just implement
the pty back end connectivity option only.

This doesn't change the fact that these programs all do the same thing,
which is to emulate a physical terminal but with some additional
optional features (such as long terminal window lengths) thrown in.

BTW, many of those open source terminal emulators are absolutely
lousy when it comes to fully and accurately emulating a VTxxx terminal.

A good test is to try them against vttest but I've found an even
better test is to try using VMS with them. (VMS is an operating system
developed by the company (DEC) which gave us the VTxxx standards in
the first place.)

Try using a DEC editor (such as EDT or EVE) with many of these
open source emulators and they fall down hard. One of the major problems
is that properly emulating a terminal involves emulating it's keyboard
as well as it's display (so that, for example, pressing Num Lock on a
PC keyboard would give you the PF1 keyboard escape sequence) and many
of them simply don't bother with the keyboard part of the emulation.

When I've looked at them in the past; some of them couldn't even render
the EDT/EVE screen correctly and this was before you even got to trying
out the keyboard. The only open source successes I have had here are
with xterm and PuTTY and both of them required some configuration
(especially xterm) before they could be used with VMS systems correctly.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 11/2/2016 2:23 PM, Grant Edwards wrote:
> On 2016-11-02, David Brown <david.brown@hesbynett.no> wrote:
>> On 02/11/16 18:22, Syd Rumpo wrote:
>>> I use multiple instances of TeraTerm in Windows to provide ANSI/VT100
>>> emulation for embedded processor diagnostics using serial USB
>>> converters.  It's not unusual to have six running at once.
>>>
>>> What are my best options in Linux, specifically Peppermint 7?  I don't
>>> want lots of clutter, just setup to eg 38k4 baud, ANSI emulation with
>>> screens to type in and display text stuff.  It's not full ANSI, just
>>> cursor-moving escape codes and the like.
>>
>> Like Don, I use screen (with Linux, rather than BSD).  Using different
>> colours for the windows is not a bad idea at all.
>>
>> 	screen /dev/ttySerial_hub2 115200
>
> Wow, I didn't know screen would talk directly to serial ports.

IMO, the biggest advantage of screen is that it is NOT "just a terminal
emulator".

Have a single (text) console?  (e.g., boot single user on a box
that has been configured with ONLY the primary console)  Screen
lets you start multiple "sessions" so you can do several things
at once -- hot switch between them without waiting for one to
complete:
    1# ls -alR / | gzip > /ls-alR.gz
meanwhile:
    2# tail -f /ls-alR.gz
and:
    5# cd ~me; tip MyDevelopmentTarget
plus:
    3# cd ~me; vi MySourceCode.c

*Some* "terminal emulators" will let you escape from the current
"session" (without dropping the connection) to rummage around
in the shell.  But, your actions then scroll the previous
"session" contents off the display.  Hot switching between
sessions lets you, for example, scroll down to the point in
session 3 where the MySourceCode.c initializes the target's
hardware; then hot-switch back to session 5 to interact with that
target using the information gleaned from session 3.

And, this stuff continues to work in the same way when invoked
from one of *multiple* consoles (if the local system is
configured as such) *or* from an xterm(1) -- or multiple
xterms!

screen(1) is my all-time favorite (in terms of practicality)
tool in terms of capabilities that it presents vs. implementation
costs!

Anssi Saari <as@sci.fi> writes:

> Grant Edwards <invalid@invalid.invalid> writes:
>
>> I recommend ckermit, which isn't a terminal emulator, just a
>> rock-solid serial comm program.
>
> I like ckermit too but considering I first used it back in 1986 and the
> UI hasn't changed much I wouldn't recommend it to anyone not already
> familiar with it. Same goes for Emacs whose serial-term is fine for
> basic use.

I've also used kermit for decades. Another option is to simply use
screen or if I need some of the kermit features I run kermit under
screen. Then multiple users (logging in to the same user) can use use the
same screen session.

//Petter


-- 
.sig removed by request. 

On 11/02/16 17:26, Tim Wescott wrote:

>
> I use minicom.  It is, oddly enough, a command-line utility -- but none
> of the graphics-based ones that I've tried are good plain-old terminals.
> I'd prefer something that has a point-and-click interface (with a window
> to type in), but none of those touch Minicom for ease of use, even
> including the fact that I don't like having to memorize all the stupid
> control-this, control-that to make it work (I just remember ctrl-X to get
> a command line, and H to get "help", which is a menuing system).
>
> minicom -b 38400 -D /dev/ttyUSB0
>

So do I. Some may find the initial user interface a bit clunky, but
it's solid right up to 115K and with no flow control ime, much as is
Teraterm under windows.

Currently have it on a laptop, running under FreeBSD, but just the same
results on Linux...

Regards,

Chris