Terminal Settings
So this has been bugging me for a few years now and I can always “fix” the problem, but I don’t know if that’s actually the correct way. So the issue is terminal emulation. I use Secure CRT (vandyke.com) to connect to any and all of my servers through SSH. Whether the terminal is set to ‘linux’ or
‘xterm’ makes no difference, I always get this output when I run a ‘tree’
command (and others that have some sort of graphical output):
[13] 05:04:53
rpmbuild/
â”── BUILD
│  └── ncftp-3.2.5
│  â”── autoconf_local
│  │  â”── acconfig.h
│  │  â”── aclocal.m4
│  │  └── aclocal.m4.ncursesw
│  â”── bin
│  │  â”── ncftp
│  │  â”── ncftpbatch
│  │  â”── ncftpbookmarks
│  │  â”── ncftpget
│  │  â”── ncftpls
│  │  â”── ncftpput
│  │  └── ncftpspooler -> ncftpbatc
Now, the way I fix that is by changing the LANG setting. By default it’s set to ‘en_US.UTF-8’ right after a fresh install. If I change that to simply ‘en_US’, then I get the output I’m expecting:
[16] 05:06:14
rpmbuild/
|– BUILD
| `– ncftp-3.2.5
| |– autoconf_local
| | |– acconfig.h
| | |– aclocal.m4
| | `– aclocal.m4.ncursesw
| |– bin
| | |– ncftp
| | |– ncftpbatch
| | |– ncftpbookmarks
| | |– ncftpget
| | |– ncftpls
| | |– ncftpput
| | `– ncftpspooler -> ncftpbatch
…
So my question is: why is that? Why would the default setting not work? Is it actually something that I need to be doing on the server (like changing the LANG setting), or is it with SecureCRT? And if so, can anyone give me any suggestions of what I need to be looking for and change?
Like I said, it’s been a couple of years and it’s never a big deal since I
know what to do to sort of fix the problem.
Thanks.
11 thoughts on - Terminal Settings
Right, one key information missing: I’m working on a Windows machine, using SCRT to connect to remote servers – I have no choice, it’s company policy. I should also point out that this only happens on newer systems. I have some old Fedora and even Redhat machines that don’t do that, but I also suspect that because they are older machines that have not been (or can not be) upgraded to more recent OS’s, that they don’t have UTF capability.
Ashley M. Kirchner wrote:
policy.
A suggestion? Your company could save money (I see SecureCRT is proprietary) – show them putty. It’s *very* solid, and lightweight, and free.
And if you need more security, say, the way we do here (US federal gov’t agency), and some things *require* that we use our PIV cards (for those civilians in the military sector, the same thing’s called a CAC), we use Reisacher’s fork, putty-cac. It’s really solid. And saves budget….
mark
Ok, so if I understand it correctly, it’s the client that doesn’t support UTF, correct?
you need to configure SecureCRT to do UTF, its probably using a ISO8559
type 8 bit encoding. this combination of settings works for me…
on the terminal->emulation, set Terminal to either Linux or Xterm, and uncheck alternate keyboard emulation. on the terminal->appearance, set a font that has unicode, like Lucida Console, or Consolas. do NOT use the vt100 family fonts.
now log out, and log back into the target system, and I bet ‘tree’ works.
re: those who say to use putty, while putty is free, SecureCRT has a lot of worthwhile features, I’ve been using it for years.
Thanks John, but that’s exactly what my setup is. I use either Linux or xterm with the alternate keyboard emulation unchecked. I’m always using the White/Black color scheme with Lucida Console font. There’s also a check box for ‘Use Unicode graphics characters’ which is checked.
oh, left out, on terminal->appearance, also set character encoding to UTF-8
Tah-ah! That fixed it! That’s what I’ve been overlooking all this time. Thanks much!
Sorry, been busy and missed this thread, but here’s a bit more help, if it’s useful…
To set it for all future terminals isn’t completely intuitive… go to Global Options -> General -> Default Session, and that’ll get you to the defaults that will be used when any new Session is created.
Good ol’ SecureCRT… it’s a bit odd.
One fun “trick” with SecureCRT (or anything that’s been around the block long enough to know what ZModem is/was…) install the lrzsz package on your Linux systems, and then pick any file you want to send to your Winderz machine, “sz [filename]”… and watch the auto-start ZModem fun begin… heh… or the opposite direction, “rz”… and pick from the ZModem menu in SecureCRT what file you want to send…
It’ll take ya right back to BBS’ing in the 80s. :-)
Minicom, of course, will also play this game. Ahh, the fun of back-door file transfers on serial consoles! LOL… :-)
Nathan Duehr wrote:
Hey, you puttin’ down zmodem, man? The only one that picked up, if you lost the connection, from where it was, rather than starting new? Only rsync is that good….
The nerve of some people, puttin’ down perfectly good software….
mark “that’s right, when I get the 5.25″ floppy drive working,
to go through all my old ones, I need to copy Brief….”
No way man… ZModem rocks. :-) Heck of a lot easier than remembering how to stuff a binary through uuencode so you can pipe the thing back to your console to grab a file over telnet! LOL!
Nathan Duehr wrote:
Never used the uuencode routine – I zipped it first. But I did have to retire my modem – it was a 56k… but an IDE interface. I’m just worried
’bout my next m/b upgrade (in five years or so, just did it the beginning of the year), because I’ve got a perfectly good big flatbed scanner… SCSI, pci card.
THEY do try to lock down the ‘Net… there was a Net before there was a Web, and a *lot* of it was servers (sorry, minicomputers) dialing each other up every hour or day…. The joys of the original design specs for the ‘Net.
mark