on 09:10 Fri 04 Mar, Sean Carolan (scarolan at gmail.com) wrote: > > In this case, you might want to conditionally assign some reasonable > > value on failure. Say: > > > > tput -T $TERM init >/dev/null 2>&1 || export TERM=xterm > > > > 'tset -q' is another test which can be used. > > The remote host's $TERM variable is in fact xterm. When I connect to > the screen session the $TERM variable is 'screen'. Are you running screen locally or remotely? My experience is it's best to launch SSH sessions in their own terminal(s), then start screen on the remote side. This also generally provides more utility (you want a single session to a host, and a logically grouped set of shells / processes on that host). Nesting screen sesssions is possible, but generally not terribly friendly due to having to hit multiple C-a escapes for screen commands. > I think it's because I'm opening a new ssh session in each screen > window. Not a huge deal; I mainly use this for short commands, and if > I need to run something longer I just write it all out in a text > editor and paste it into the terminal. Or you could write a script, scp it to the hosts you want to run it on (testing first, natch), and exec it: for host in <hostlist>; do scp myscript $host:.; done [fiddle around with tests or verification as necessary] for host in <hostlist>; do echo "** $host **"; ssh $host ./myscript; done ... which is a shell idiom that shows up a LOT in my history. As I mentioned earlier, dsh (distributed ssh) is a very powerful tool for running multiple remote commands. Puppet, cfengine, and other tools may also be useful. Scales from low multiples through thousands and more of hosts. -- Dr. Ed Morbius, Chief Scientist / | Robot Wrangler / Staff Psychologist | When you seek unlimited power Krell Power Systems Unlimited | Go to Krell!