Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25323 > unrolled thread

ANSI terminal emulators for linux

Back to article view | Back to comp.arch.embedded

Contents

  ANSI terminal emulators for linux Syd Rumpo <usenet@nononono.co.uk> - 2016-11-02 17:22 +0000
    Re: ANSI terminal emulators for linux Tim Wescott <seemywebsite@myfooter.really> - 2016-11-02 12:26 -0500
      Re: ANSI terminal emulators for linux Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-06 13:12 +0000
    Re: ANSI terminal emulators for linux Grant Edwards <invalid@invalid.invalid> - 2016-11-02 18:12 +0000
      Re: ANSI terminal emulators for linux Tim Wescott <seemywebsite@myfooter.really> - 2016-11-02 13:21 -0500
        Re: ANSI terminal emulators for linux Grant Edwards <invalid@invalid.invalid> - 2016-11-02 18:52 +0000
        Re: ANSI terminal emulators for linux Grant Edwards <invalid@invalid.invalid> - 2016-11-02 19:02 +0000
        Re: ANSI terminal emulators for linux Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-11-02 22:13 +0100
        Re: ANSI terminal emulators for linux Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-11-03 18:36 +0000
      Re: ANSIOA terminal emulators for linux Anssi Saari <as@sci.fi> - 2016-11-03 11:47 +0200
        Re: ANSIOA terminal emulators for linux Don Y <blockedofcourse@foo.invalid> - 2016-11-03 06:43 -0700
        Re: ANSIOA terminal emulators for linux Petter Gustad <newsmailcomp6@gustad.com> - 2016-11-04 20:59 +0100
    Re: ANSI terminal emulators for linux Don Y <blockedofcourse@foo.invalid> - 2016-11-02 11:37 -0700
      Re: ANSI terminal emulators for linux Don Y <blockedofcourse@foo.invalid> - 2016-11-02 11:45 -0700
    Re: ANSI terminal emulators for linux David Brown <david.brown@hesbynett.no> - 2016-11-02 21:14 +0100
      Re: ANSI terminal emulators for linux Grant Edwards <invalid@invalid.invalid> - 2016-11-02 21:23 +0000
        Re: ANSI terminal emulators for linux David Brown <david.brown@hesbynett.no> - 2016-11-03 08:02 +0100
        Re: ANSI terminal emulators for linux Don Y <blockedofcourse@foo.invalid> - 2016-11-03 14:52 -0700
    Re: ANSI terminal emulators for linux rickman <gnuarm@gmail.com> - 2016-11-02 16:28 -0400
    Re: ANSI terminal emulators for linux Syd Rumpo <usenet@nononono.co.uk> - 2016-11-03 12:17 +0000

#25323 — ANSI terminal emulators for linux

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.

Cheers
-- 
Syd

[toc] | [next] | [standalone]

#25324

On Wed, 02 Nov 2016 17:22:25 +0000, 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.
> 
> Cheers

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

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#25405

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

[toc] | [prev] | [next] | [standalone]

#25325

On 2016-11-02, Syd Rumpo <usenet@nononono.co.uk> 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 recommend ckermit, which isn't a terminal emulator, just a
rock-solid serial comm program.  You can run it in any terminal
emulator you want (linux console, xterm, aterm, rxvt, urxvt,
gnome-terminal, kterm, screen, ...)

> 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.

I prefer the Unix approach of one-function-one-program -- separating
the serial comms from the terminal emulation. But, if you want
something that's pointy-clicky-all-in-one, there's always putty:

  http://www.putty.org/

A lot of people use minicom, but I find its UI utterly abhorrent.

-- 
Grant Edwards               grant.b.edwards        Yow! I brought my BOWLING
                                  at               BALL -- and some DRUGS!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#25326

On Wed, 02 Nov 2016 18:12:52 +0000, Grant Edwards wrote:

> On 2016-11-02, Syd Rumpo <usenet@nononono.co.uk> 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 recommend ckermit, which isn't a terminal emulator, just a rock-solid
> serial comm program.  You can run it in any terminal emulator you want
> (linux console, xterm, aterm, rxvt, urxvt, gnome-terminal, kterm,
> screen, ...)

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".

>> 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.
> 
> I prefer the Unix approach of one-function-one-program -- separating the
> serial comms from the terminal emulation. But, if you want something
> that's pointy-clicky-all-in-one, there's always putty:
> 
>   http://www.putty.org/

I tried putty and really didn't like it.  I can't remember why, just that 
the features available didn't make me happy.

> A lot of people use minicom, but I find its UI utterly abhorrent.

I'll have to try ckermit.  Minicom works for me, but only because I have 
a basic strategy of getting into the "help" menu and navigating 
(sometimes with lots of iteration and cussing) to what I need.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#25330

On 2016-11-02, Tim Wescott <seemywebsite@myfooter.really> wrote:

> I'll have to try ckermit.  Minicom works for me, but only because I have 
> a basic strategy of getting into the "help" menu and navigating 
> (sometimes with lots of iteration and cussing) to what I need.

In CKermit it's ctrl-\ to get to the ckermit prompt, and then it's all
commands like  "set baud 9600" "set parity none" etc.

IMO, the easiest way to use ckermit is to define an initialization
file for your most commonly used configuration and then write a small
shellscript for each configuration that invokes ckermit with the
proper initialization file.

My default config file looks like this:

 set port /dev/ttyS0
 set baud 115200
 set flow none
 set parity none
 set carrier-watch off
 log session
 connect

So that's what I get if I just type "kermit".

-- 
Grant Edwards               grant.b.edwards        Yow! Should I get locked
                                  at               in the PRINCICAL'S
                              gmail.com            OFFICE today -- or have
                                                   a VASECTOMY??

[toc] | [prev] | [next] | [standalone]

#25331

On 2016-11-02, Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Wed, 02 Nov 2016 18:12:52 +0000, Grant Edwards wrote:
>
>> On 2016-11-02, Syd Rumpo <usenet@nononono.co.uk> 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 recommend ckermit, which isn't a terminal emulator, just a rock-solid
>> serial comm program.  You can run it in any terminal emulator you want
>> (linux console, xterm, aterm, rxvt, urxvt, gnome-terminal, kterm,
>> screen, ...)
>
> 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.  

Well, they're not entirely different.  Both of them emulate a vt52, or
vt102, or ANSI, or Wyse50, or Tek4014[1], or whatever inside a
graphical window.

The Windows version _also_ handles serial-port (and often network)
communications.

The X version just talks to a pty (which is sort of a dumbed-down
minimalist virtual serial port that connects two programs together)
and leaves the actual serial-port stuff to be handled by whatever is
connected to the other end of the pty.  Then you can connect the other
end of the pty to ckermit, tip, cu, telnet, ssh, rsh, nc, or anything
else you want to use to provide a byte-stream connection to the
applicatoin that's expecting to talk to a "terminal".

[1] Yes, xterm will still emulate a Tektronix 4014 storage-scope
    vector graphics terminal [except, sadly, there's no bright-green
    flash when the screen is erased -- I've always wanted to add
    that...]

-- 
Grant Edwards               grant.b.edwards        Yow! It's some people
                                  at               inside the wall!  This is
                              gmail.com            better than mopping!

[toc] | [prev] | [next] | [standalone]

#25334

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".

[toc] | [prev] | [next] | [standalone]

#25340

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

[toc] | [prev] | [next] | [standalone]

#25337 — Re: ANSIOA terminal emulators for linux

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.

[toc] | [prev] | [next] | [standalone]

#25339 — Re: ANSIOA terminal emulators for linux

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!

[toc] | [prev] | [next] | [standalone]

#25366 — Re: ANSIOA terminal emulators for linux

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. 

[toc] | [prev] | [next] | [standalone]

#25327

On 11/2/2016 10:22 AM, 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.

I don't run Linux -- but screen(1) is a viable option under *BSD.
I imagine if not available as a prebuilt package for your distro,
you could just build from source.

Run it in an xterm or from one of the consoles.  Plumb it to tip(1),
as appropriate.

It has the added advantage that you can hot-key between multiple
"sessions" in that same "window" (or console).  IIRC, you can also
subdivide the "display" to show two or more sessions *in* that
single window.

Far too many capabilities to describe how it can be exploited, here.

[toc] | [prev] | [next] | [standalone]

#25329

On 11/2/2016 11:37 AM, Don Y wrote:
> It has the added advantage that you can hot-key between multiple
> "sessions" in that same "window" (or console).  IIRC, you can also
> subdivide the "display" to show two or more sessions *in* that
> single window.

Hint:  if you opt to exploit the multiple sessions capability,
set the foreground/background colors of each "screen" to something
you can easily recognize:
    "Ah, this is red so it must be screen #2"
This makes keeping track of the associated hot-key much
easier!

[toc] | [prev] | [next] | [standalone]

#25332

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

It doesn't get much easier than that.  (It is not quite as flexible in 
its serial parameters as something like minicom - but you don't usually 
need that.)


A /really/ nice thing you can do in Linux is use udev rules to set up 
rules for USB components.  For example, I have a 4-port hub connected to 
one of my PC's USB ports.  I have some lines in a udev rules file like this:

KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.0/*", SYMLINK += 
"ttySerial_hub2"
KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.1/*", SYMLINK += 
"ttySerial_hub2b"
KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.0/*", SYMLINK += 
"ttySerial_hub3"
KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.1/*", SYMLINK += 
"ttySerial_hub3b"

Any USB to serial converter I attach to port 2 of the hub turns up as 
device /dev/ttySerial_hub2, as well as the standard /dev/ttyUSB0.  If it 
is a two channel converter, the second one is "hub2b".  I have similar 
rules for physical ports 1 to 4 on the hub.

You can also have rules that match on serial number of the converter 
regardless of the port, exact type of converter (TTL, RS-232, RS-485, 
etc.), or combinations.  Rules can make multiple symlink names, change 
access permissions, and so on.

It is vastly easier than Windows assigning different COM port numbers 
for each device and changing it according to the physical port, the 
hubs, the weather, etc., so that you never know if you should be using 
COM94 or COM16.

[toc] | [prev] | [next] | [standalone]

#25335

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.

[toc] | [prev] | [next] | [standalone]

#25336

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.

[toc] | [prev] | [next] | [standalone]

#25341

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!

[toc] | [prev] | [next] | [standalone]

#25333

On 11/2/2016 1:22 PM, 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.

Linux is a bit odd in that a command window *is* a terminal emulator. 
It just isn't connected to a serial port.

I ran into this problem when I was working with a Raspberry Pi to use as 
a remote interface to an embedded MCU board.  I seem to recall miniterm 
had some problems with the end of line character conversion.  I can't 
recall what I used, it may have been picoterm.  The ones I found were 
all a bit crude and every single one had some sort of significant 
limitation.

I don't recall what I used to use under windows, but in the "old" days 
it seemed there were plenty and they worked well.  Now it seems to be 
harder to find them and they don't work as well.  By that I mean the 
user interface is not as good.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#25338

Thanks for all the helpful suggestions, guys.

Cheers
-- 
Syd

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web