weird sftp problem with csh

[MTSU_SAN]

I have clients who customize their cshrc. After upgrading my HP-UX box to 11i (from 11.0), sftp will no longer log into the customized clients--while debugging I noticed it receives an immediate eof. I've picked apart the .cshrc, and this clause seems to kill it (in other words, I can successfully log in until this point in the .cshrc is added)
# Establish some terminal-dependent items
if ($?TERM == 0||$TERM == "unknown"||$TERM
== "network"||$TERM == "hp") then
setenv TERM vt100
setenv term vt100
endif
Any ideas why this simple statement breaks it?

[Stephen Keane]

Does it still break if you remove/comment out the line

setenv term vt100


(just a hunch)

[MTSU_SAN]

Yes, in fact that is the only statement in the clause that if left will not break it. I've left just the empty if, and it breaks. I've levt just the TERM, ditto. But the term one is OK?!

[Stephen Keane]

Can you run

ssh yourhost /usr/bin/true

[Stephen Keane]

I suspect what is happening is that TERM is not set when it gets to the if statement.
The if command fails and outputs a message such as "TERM: Undefined variable.". If the shell tries to write something to the terminal it has become interactive and will kill sftp/ssh.

If you edit the cshrc and just before the if statement put

printenv > /tmp/foo

You can check if TERM is actually set (and to what) in the script. I'm not used to csh, but in ksh there is an option to report/not report access to environment variables that haven't been declared. You might need to turn it off in csh?

[MTSU_SAN]

I think I agree with you--it is trying to output. The $?TERM == 0 check is supposed to take care of TERM not being set at that point (which it is NOT) but maybe it is still printing something.

[Bill Hassell]

The code in .cshrc is really archaic and assumed (years ago) that all machines are HP-UX. Both csh.login and .cshrc should not be making these tests anymore, but should instead identify the terminal using ttytype. This applies *only* to interactive (real people at real keyboards) logins. The value of TERM should be set using ttytype. For POSIX shells, the all the: if $TERM ... code should be replaced with: eval $(ttytype -s). For csh users, use the older style command substitution, grave accents: eval `ttytype -s`

ttytype is smart enough to output the right commands depending on the setting for $SHELL. You never want to inherit TERM from a remote connection, especially if the remote user is not using another HP-UX system. Always let ttytype figure out the terminal type, and always bypass ttytype (and tabs, tset, stty, etc) if there is no real terminal (ie, a batch or cron job)

[MTSU_SAN]

I agree with ttytype stuff, but this is one of my academic Department's customization code, which is shared with their linux box, and they aren't gonna change it!
I did figure out that separating the check for unset TERM, and the rest of the if statement works (it was obviously trying to complain DURING the if that TERM was not set), so problem is solved!!
Thanks for all of your help.

[MTSU_SAN]

Ooops, forgot to close.