TERM for filepro

[Brian K. White]

I assume it was an accident sending to me instead of trhe list.

You don't set TERM=linux unless you are at a linux terminal. Most 
xterm-alikes are not linux terminals but "xterm".

The purpose of the TERM variable is to tell applications what kind of 
terminal you are using, as in, the very last thing (that operates on a 
tty level) on the way from the app to your eyes, what is that very last 
layer of software? On a typical linux desktop this is xterm, or 
kde-terminal or gnome-terminal etc... Now some of these do have a "linux 
console mode", so if you are using that mode, then in that case 
TERM=linux is correct. Generally xterm or xterm-color would be correct.

Basically, whatever the terminal itself sets, just make sure that 
propagates to the remote session. Open a terminal window on your desk, 
and view TERM "echo $TERM" , aso check LANG and LC_*, so:
set |egrep "^(TERM|LANG|LC_)"
What does that say? Unless you did something really weird on your end, 
those will be set correctly to describe the way your terminal will 
actually behave. They are set by the terminal itself, so it is the 
authority on the matter. It is possible to break this because it's 
possible to break anything, but I can't cover _everything_ here...
So assuming your end is sane...

Now ssh to remote machine.
Run the same set|egrep command over there before you do anything else.

Any mis-match in any of those may cause a problem. Which is exactly why 
the default /etc/ssh/sshd_config is configured to accept those values 
from the client, and no others. None of those should be being hard coded 
or overridden on the remote server side, but it is not uncommon for 
boxes to be set up incorrectly by software vars who only barely know how 
to use the OS they are running on.

That's really just a start. There are lots of possible things that could 
be going on. There are a lot of points along the chain from remote 
process to your eyes where some misconfiguration could cause symptoms 
like you're seeing, but the most common is simply the wrong TERM 
variable for your actual terminal, or a bad or incomplete set of 
termcap/terminfo definition for that term, or an intermediate modifying 
layer like "screen" that is it's own special case I won't get into 
unless pressed.

If you see a discrepency between those variables, it's safe to just 
manually overwrite or unset them to exactly match your side to see if 
that works. The changes won't save anywhere or affect anyone else. 
Fixing the real problem probably means editing profile or bashrc scripts 
or sshd_config, all on the remote side, and that _could_ affect the 
current users even if you are making something from incorrect to 
correct, the current users are all setup to work _with_ the current 
broken setup, so you might or might not have to fix them too.

For instance if the Anita clients are not setting those variables 
correctly, or at all, then someone may have hard coded something on the 
server instead of fixing the clients. If you take away the server side 
hard coding, the clients all start breaking.

-- 
bkw


On 9/28/2011 4:28 AM, calvin covington wrote:
> If this has already been answered, I apologize. --please just point me
> in the right direction.
>
> I use Centos 5.5 as my desktop and ssh to my clients directly from
> Centos (no emulator)
>
> I have a client in another state.   I installed filePro 5.6.10D4
> remotely onto his  fresh install of Centos 5.6 on an athlon dual 245
> server. (he installed Centos, I installed filePro remotely)
>
> When I ssh onto his system,  I get the funky boarder lines  and some of
> the F key functions do not work.   I checked his /etc/sysconfig/i18n,
> and it is identical to mine. I've tried TERM=linux, etc.,  (which I
> don't have to do on the other linux hosts that I  'ssh' into...
>
> He hasn't complained of any problems at his place (they use Anita
> emulators), but it is very annoying to me to work around not having F
> key functions .. and of course the display is ugly.
>
> Thanks in advance.
>
>
> Calvin
>
>
>
>
>
> On Wed, 2011-09-28 at 02:28 -0400, Brian K. White wrote:
>> On 9/27/2011 6:02 PM, Henry Arredondo wrote:
>>>
>>>
>>> -----Original Message-----
>>> From: filepro-list-bounces+hxarredondo=lkqcorp.com at lists.celestial.com [mailto:filepro-list-bounces+hxarredondo=lkqcorp.com at lists.celestial.com] On Behalf Of Fairlight
>>> Sent: Tuesday, September 27, 2011 4:15 PM
>>> To: filepro-list at lists.celestial.com
>>> Subject: Re: TERM for filepro
>>>
>>> Y'all catch dis heeyah?  Jay Ashworth been jivin' 'bout like:
>>>> There's a version of Putty for Linux, but in general, you don't *need* a
>>>> terminal emulator for Linux workstations, you're already *talking to* Linux
>>>> through a terminal emulator.  You just SSH over to the machine with the
>>>> binaries, and run them, from whatever you're already running, konsole, rxvt
>>>> or what have you.
>>>
>>> I never understood it, either...
>>>
>>> m->
>>> --
>>> Audio panton, cogito singularis.
>>> _______________________________________________
>>> Filepro-list mailing list
>>> Filepro-list at lists.celestial.com
>>> Subscribe/Unsubscribe/Subscription Changes
>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>
>>> The thing I like about Putty is that it let's you do copy-paste on the fly by selecting the range and clicking the right mouse button to paste. I wonder if there's a terminal emulator within Linux that would do that besides putty.
>>
>> Are you kidding me? You don't need an emulator for cut&  paste. Every
>> terminal (be it an emulator or not) already does that perfectly natively.
>>
>> There are a few plausible reasons to use any emulator when you don't
>> need one and it's just another unnecessary
>> layer/point-of-falure/complication/crap-you-have-to-keep-track-of/problemo-bfuscator-if-not-causer...
>> but cut&  paste sure isn't one.
>>
>> There are numerous, numerous xterm-alikes by now. Practically countless.
>> There are reasons to go try 50 of them and fall in love with some
>> unusual feature of one, and there are reasons to specifically avoid
>> doing any of that because the hot new killer terminal today is next
>> months derelict project that no one works on and goes obsolete and
>> you're tied to it so your stuck with whatever problems it ends up
>> having. Tabbed sessions, built-in zmodem and/or kermit, clickable url's,
>> multi-language, saved session managers, etc...
>>
>> I would only use putty on linux for 3 reasons
>>
>> * The ability to save all session settings in a portable (also cgi
>> generatable) config file.
>> * emulating sco ansi on the client side if I supported a lot of random
>> sco boxes where it would be impractical to properly install
>> linux/xorg-xterm termcap, terminfo, and profile stty settings on all the
>> sco boxes.
>> * ultra consistency, "the same app, putty, everywhere, all clients, all
>> os's"
>>
>> The first is hardly necessary unless you had end-users using linux
>> desktops, and even then there are session saving regular xterm-alikes
>> anyways, or just plain putting a command line full of options into a
>> shell script. The second hasn't been true for me since several years
>> ago. The third is only partially possible since even on those platforms
>> putty supports, it varies somewhat in the details for each platform, so,
>> hardly enough consistency to be of any value.
>>
>> I see really only the very rarest reason to run any emulator, putty or
>> other, on a linux desktop. The reason you run an emulator on a windows
>> desktop is because windows isn't X and has no "x terminal" or any other
>> form of unix-like (streaming mode) terminal, and so you need to emulate
>> one. a cmd prompt is not like a unix tty even if it sort of looks like  it.
>>
>> On linux, both your regular console screen or xterm-alike in X are
>> already, natively, perfect tty terminals and are already natively
>> exactly the correct tool for connecting to any other remote unix-like
>> server.
>>
>> Apple is as usual a weird case. It technically has a native terminal and
>> should in theory be like linux or freebsd or any other unix and require
>> no emulator for talking to other boxes, but they pretty much bastardized
>> it and screwed it up and so you're best off actually using an emulator
>> on Mac the same as you would on Windows.
>>
>> --
>> bkw
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>