Google, Wikipedia directly on ASCII terminal?

[Grant Taylor]

On 01/16/2018 03:38 AM, Peter Corlett via cctalk wrote:
> I do this routinely, albeit with a terminal emulator and ssh session 
> rather than a physical terminal and modem.

Agreed.

> My "small device" is a Debian Linux box in Germany on which I read mail 
> and Usenet, do IRC, etc. I wrote a trivial Perl script called "google" 
> that inspects its arguments, and constructs a search URL which it passes 
> to elinks, a text-mode web browser. A similarly-trivial "wikipedia" 
> script could be written. Some web sites such as Twitter recognize the 
> elinks User-Agent and switch to a non-JavaScript "mobile" site. Facebook 
> doesn't work, but there's nothing of value there anyway.

Nice.

> A physical serial connection is simpler than a pair of modems, so start 
> with that. Run a null modem cable between your terminal and COM1 on 
> the Linux box, edit the inittab to add a getty for /dev/ttyS0 with the 
> appropriate terminal type (there's usually a commented-out example) 
> and reload init. A similar principle applies to USB-serial dongles, 
> but they're a bit unreliable so try to use a proper on board serial port 
> if possible.

I'm curious what sort of issues you've had with USB based serial ports. 
Is it the fact that USB devices can change names?  Or is it a race 
condition between driver load and getty launching?  Or something else?

> Linux's "vt100" terminal type differs somewhat from DEC's in that it 
> includes command sequences that an original VT100 does not and some 
> full-screen applications will render incorrectly,

That surprises me.

Is it actually the VT100 definition in termcap / terminfo?  Or are you 
referring to the fact that Linux uses the "linux" (?) term type in lieu 
of the "vt100" term type?

> but a VT220 worked OK when I last tried, back in 2003-ish. If the 
> render is occasionally off-by-one -- you'll know it when you see it -- 
> it means that the terminal is configured for 24 lines and the Unix box 
> for 25 lines or vice-versa. Use the terminal's settings menu and/or 
> tweak $LINES/$COLUMNS on the Linux box.

*nod*

I feel like theses are issues that were prevalent back in the days of 
serial terminals.  Probably not new.  If anything, new variants in an 
existing messy soup.

Throw some DEC MMJs and LAT in for good measure.  }:-)

> Dial up is a refinement of this. You will need to use "mgetty" instead 
> which understands Hayes commands and other modem control signals, but 
> it might not be installed by default.

Why is mgetty required?  Are you referring to the fact that mgetty can 
discern the difference between text / SLIP / PPP / FTN / fax / voice and 
hand the connection off to the proper back end?

If the port is dedicated for this, then I don't think mgetty (or any 
other fancy getty) is required.

> Note that 15 years ago we were running sysvinit, and now we have 
> the Brave New World of systemd, which is overcomplicated GUI junk and 
> probably doesn't support serial terminals. If you decide to build this, 
> find a Linux distribution without systemd, or use something like FreeBSD.

Why will systemd be a blocker?  Shouldn't any self proclaimed init 
system be able to launch a daemon (what ever it's dependencies / 
arguments are) and re-spawn it when it exits?  -  Why does systemd need 
to know anything about the serial port?  Why can't systemd just launch 
(m)getty which is monitoring the serial port.  -  Or are you saying that 
the (systemd based) login program that (m)getty would call might have 
issues.

Note:  I am anti-systemd.  But I don't see how Master Control Program, 
ala Tron, can prevent (m)getty from working on a modern distribution. 
Granted, the OP might need to create some custom systemd config files. 
But I view that as more of a speed bump than an actual blocker.



-- 
Grant. . . .
unix || die





-- 
Grant. . . .
unix || die