(my Wyse 120 after I converted and installed the old Slackware "Scrawl" font on it)
In setting it up to do this (it turns out you can't install them on it in the VT-100 compatibility mode, you have to put it into a WYSE mode, such as the native WYSE 120 mode), I was reminded of the trouble I'd had in the past with trying to use the thing in a native Wyse mode. Yes, even if you tell the system "export TERM=wy120", or more sensibly change the "getty" entry in your inittab file to use wy120 as the terminal type. I mean, there's the "wy120" and "wyse120" terminfo entries, so it should work ok, right? Well no, which is why like so many other people apparently, I always just ran the thing in vt100 mode.
Here's a few of the problems you'll encounter in configuring things if you do use a native Wyse mode:
LS
GNU LS has the lovely colourised mode which makes everything pretty. Colourised mode can be turned on or off. It also has the --color=auto setting, which on most Linux distros is the default in your config files (via the LS_OPTIONS environment variable). This is meant to use colour terminal-control codes only if it "detects" that the output system is compatible. How does it do this? Well... it sees if the output stream is a terminal device, such as a tty or an Xterm or the Linux console. And then... if it is, it decides it can do colour. THAT'S IT. No checking the Terminfo database for the ability to handle colour or anything like that, obviously if you're using a Linuxish system, any "terminal" must automatically mean a virtual terminal of some sort running inside the computer.
(addendum: I note that the "compiled-in database" in the dircolors command, has a list of common terminals that it says are compatible with colour; still, none of this seems to be output to the LS_COLORS variable, and the "ls" manual claims nothing about taking such factors into account... AHA! Ok, if you log in when your TERM variable isn't one listed, dircolors evaluates differently, and LS_COLORS winds up empty. And yet STILL LS_OPTIONS has --color=auto and it STILL garbles the output regardless!)
If you use your WY-120 in VT100 mode, it seems to work out ok, and you just get a fairly normal output without colour (I don't know of any colour WY-120s, mine is amberscreen, I presume there's green and white options), but maybe with bold and underscored output etc amongst the entries.
Now, if you're using your WY-120 in WY-120 mode, all those control codes for colour make the output go funny, and it seems it interprets them as cursor control codes or something. OH! Nope... the specific outputs used for the colour LS, is given by the LS_COLORS variable. I hadn't given this much thought, but it seems it does it in terms of the raw control codes. Or almost.
So, in your shell startup scripts or wherever, if you have code to detect you're on the WYSE terminal, you should EITHER setup LS_OPTIONS to be --color=no to turn it off completely, OR set LS_COLORS to a set of codes that'd be WYSE compatible, via dircolors. Normally this gets its configuration from a built-in config file (you can't edit it), but you can feed it an alternative config file too.
Sadly the docs don't tell you for sure how these entries are processed (other than eg that "33" represents yellow or that "01" represents bold); it's quite possible, that it completely ignores Termcap for this too, and just bungs VT100 control codes around the values it sees, in which case you're probably stuck with turning it off. We'll have to see...
TODO: relocate half that addendum to here maybe
Readline
Bash uses "readline" for cursor control and all that (or does it???). This is a rather good library with a lot of clever features and much configurability. Unfortunately though, one of the first things you'll spot if using WY120 mode in Bash, is that the up key does bugger-all, and the down key gives a newline! Amongst various other noticable screwups.
Partly this is because Wyse mode produces ^K for up arrow, and ^J for down arrow; the latter is commonly equivalent to return, although not identical (Return gives ^M).
Now, the Readline library is also configurable, but doesn't seem by default to work with the Terminfo system (nor even the older, obsolete Termcap). So all the entries in the Readline configuration file (/etc/inputrc for global config, and ~/.inputrc for user-specific stuff) have to be done in terms of characters, not abstract keys. The saving grace is that it can use conditionals, to do different code based on things like terminal type.
In order to test our alternate settings, we can use Bash's "bind" command, in the form of
bind '"key characters":readline-command'
where key characters would be what bytes get sent by the terminal, for instance \C-k for ^K that gets sent for the up arrow, and readline-command would be what you want that key to do in Bash (or whichever other Readline-based program you're configuring, but other configuration would have to be in a config file, not the shell "bind" command)- for instance "previous-history" for producing the last thing entered (or the thing before that, etc). SO:
bind '"\C-k":previous-history'
makes the ^K key (as produced by Wy-120's up key in native mode) go to the previous item in command history- just like we're used to normally!
Now, does it work for the down key?
bind '"\C-j":next-history'
YES, this works perfectly! No problems, no attempting to give a newline.
What about left and right? These have been giving backspace and *bloink* respectively (I'm not sure what that is, judging by the control codes it's maybe form-feed or something??). I like being able to edit my actual line...
Well firstly, even if we don't change those bindings, it is still possible (in fact it also is with the previous and next history commands too) to use them via ctrl keys: ^B (\C-b) goes back (without backspace-deleting), and ^F (\C-f) goes forward. But we'd ideally like to be able to use the normal keys.
Sadly the deal is, that left arrow produces the infamous ^H character, and so does backspace. AFAIK there's nothing we can do to distinguish one from the other- though I may be mistaken. If we want to use left-arrow for moving in WY-120 native mode, we can no longer use backspace for deleting. We'd have to use another key, like the Delete key. Well as it is, the Delete key in this mode does a backspacing action anyway, but it is kinda awkward to reach for compared to backspace, especially if you're used to using it as much as I am (I type too fast). Thankfully there doesn't seem to be a problem with the ^L from the right arrow though. So:
bind '"\C-h":backward-char'
bind '"\C-l":forward-char'
Work as well, and yes, as expected, they make backspace stop deleting as well. "Delete" remains a backspace-like delete key.
As an aside, in investigating the Readline stuff, I found out that that is what causes the £ key in Bash (well, the version I still have installed) to puke (it pops a # at the start of the line, and then hits Return. WTF??). Turns out it's a Readline variable "convert-meta", which if set to On, takes any character you type that has the 8th bit set (the bit which it interprets as the "Meta" modifier), and converts it into an escape sequence instead. The £ character is outside of ASCII proper (which is only 7-bit, in case you didn't know), and so gets mangled this way if that variable is set.
To fix this (if you don't benefit from the old behaviour), enter
bind 'set convert-meta off'
and see if it makes a difference. If it does, edit /etc/inputrc and change the "convert-meta" line in there, if there is one. You want the line to say just
set convert-meta off
and not be commented-out (# is a comment symbol of course).
You might also notice, that all those other weird characters, like ÷, æ,ß, Ð, ± etc, that you couldn't enter before at the command prompt (but could if running another program reading from stdin, say), are now typeable at the prompt too. Unless you had this variable turned off already, in which case all these things would never have been a problem probably.
Dosemu
This probably applies to (non-X version) Dosemu in other terminal types too, at least some of it.
- As with a few other programs, it mostly wants a 25-line terminal. Wyse-120 can give that, but you have to select it in the Wyse configuration screen (Shift-Select or something). You also have to use a terminal type variable that specifies 25 lines! EG wy120-25 or similar. The default wy120 type is for 24 lines.
- At least some programs seem to spout cobblers at the screen. This MAY be down to the colour output, which you can turn off in the dosemu.conf- or at least tell it that your terminal isn't colour. I'm not sure how you can conditionally set DOSEMU variables though- I mean, I do normally want colour in Dosemu...
- If you use programs like DOS Help, you find you can't exit with Alt-F x, as it won't recognise Alt as a separate keypress, and it doesn't seem to accept Alt-F in teh same way either. *shrug*
Meanwhile, AFAIK you can't use Dosbox at all, although I've not tried that yet.
"Fonter"
a somewhat mad font editor for the Linux console. Wants 25 lines, doesn't want to run in X. Could be that if you tweak some (several?) of the start-up options, it MIGHT be able to run on a Wyse terminal. The softfont part may be a problem tho! Code for installing the font's probably not compatible at all with a Wyse, it's probably Linux console only.
Sterling work
My WY-120 has a proper UK keyboard. Yay! It's quite nice. Pretty much everything in its proper place, including a Sterling (£) key! And it doesn't cause that glitch you used to get in Bash where £ would mess up! (see earlier on how to fix this if yours still has this problem). Yes, even without the fix! Guess how it manages that?
Ok. This becomes a bit more clear if you ever read some shell script files or anything from the terminal. Yep, that's right! It doesn't produce a £ character in fact. It produces a # ("octothorpe", "hash" etc, unless you're one of those Americans who bizarrely considers that a "pound" sign, WTF?) character, and the built-in font simply uses a £ glyph for that. This also I guess helps to explain the actual # key (in its standard UK keyboard place, next to the Return key). This produces NOTHING in normal use. Classy!! If you pass stdin through a hexdump program or similar, you see it is actually generating ^@ characters, which are ASCII 0. Why? NO IDEA.
So what use is this internationalisation attempt? Not a whole lot really, except that most of the keys are where I expect them to be at least. Somewhat similar things happen with the `¬| key: the ' works, the ¬ produces ^@, and | gives ^A`` or something weird. So that's a 2nd character that just produces ^@, perhaps due to being extended ASCII. And actually, using Alt- or AltGr- with other keys seems to have a similar ^Asomethingsomething effect.
AFAIR most/all of this also applies in VT100 mode. I'm not sure you can escape it! Well, not in the way we'd like (£ produces a real £, # produces a real #, both useable at once, etc). I could've sworn there used to be a mode where it'd act like a US-based terminal, but the Language config option on mine can only select between European locales. Hmm.
Also note, that if you install a WY60 soft font, and it's designed with real ASCII etc, the # characters will render as # again and not £.
other keyboard handling modes?
Meantime, I note that on the same page of the config system (Shift-Select) that lets you select the "Language", the keycodes can be configured as "ASCII" or "SCAN". I had been using ASCII. What about SCAN? I'm guessing that works on raw keyboard locations or something, but then what interprets things? What are the pros and cons of this? Does it need setting up on the system? Perhaps it'd let us use the non-ASCII chars.
...ARGH! OK LETS NOT DO THAT AGAIN
Ok that's weird. In normal ASCII mode, the config system is reached by Shift-Select and nothing else. In Scan mode, that produces keycodes, like everything else, and no config system. Watch with joy as it makes everything go mad! In this mode, you have to use Ctrl-Select instead, to get back in and fix the keyboard. Which at least works within the config menus.
How're you supposed to use Scan mode? I have no idea. I imagine it needs dedicated software on the host computer, to act like a virtual terminal or something. OTOH from this I guess you could implement things like processing Unicode, using different font banks for non-ASCII characters, and perhaps reprogramming the banks on-the-fly as characters are used. Naturally this can only work as long as you don't use too many characters on screen at once. And no I'm not aware of such a program. And no, I'm not in a hurry to make one! (But if you do, let me know, I'll probably link it!)
Other stuff you can do with a text terminal
Apart from using command-line based software in Linux (or in some cases DOS), you could play various roguelike games? But only the really roguelike ones of course. Note that some roguelikes on some terminals (eg mine!) may cause a bit of glitching if they assume they can use colour. And on terminals such as mine (with the half-arsed internationalisation...) you may find that walls display as (sterling) instead of #.
Basically if you can use the program over Telnet or SSH, you can probably run it on a serial text terminal like this.