1

It's strange that neither

ssh user@192.168.1.59 bash -c "top"

nor

ssh user@192.168.1.59 "top"

works as expected, whereas both

ssh user@192.168.1.59 "ls"

and

ssh user@192.168.1.59 bash -c "ls"

work well.

Here is the error message\output for the former command.

TERM environment variable not set.

I searched and found this post.

As per the said post, there is an answer shed some light on this matter.

You can see if it's really not set. Run the command set | grep TERM. If not, you can set it like that: export TERM=xterm

I tried

ssh user@192.168.1.59 bash -c "set | grep TERM;top"

, and the output is

TERM=dumb
TERM environment variable not set.

, which is in my expectation.

Then I try to set XTERM as what the post told me, but it does not work. I am stuck again. Here is my command to set XTERM and run top:

ssh user@192.168.1.59 bash -c "export TERM=xterm-256color; top"

Here is the output for the above command:

declare -x DISPLAY="localhost:13.0"
declare -x LANG="en_US.UTF-8"
declare -x LC_ALL="C"
#...
TERM environment variable not set.

Could somebody shed some light on this matter?

John
  • 2,963
  • 11
  • 33
  • 2
    Questions that are about how UNIX tools work, as opposed to about software development per se, are a better fit for [unix.se] than Stack Overflow. – Charles Duffy Jun 14 '22 at 13:07
  • It's the difference between writing to standard output (a stream) and trying to write directly to the terminal (allowing finer grained cursor control, for example). – chepner Jun 14 '22 at 13:12
  • @chepner Could you please explain that in more detail? – John Jun 14 '22 at 13:13
  • You can't possibly have gotten the output you describe from the command you posted. Are you sure that you did not accidentally write a semicolon after the `export`? The reason is that you get on the output a list of your environment, and the commands you have posted here don't generate such a list. – user1934428 Jun 14 '22 at 13:14
  • BTW, the usual way to set an environment on the remote side, is to create a file `~/.ssh/environment` which contains just `TERM=xterm-256color`. – user1934428 Jun 14 '22 at 13:16
  • @user1934428 No, I wrote the semicolon after the `export` on purpose. And I run `export TERM=xterm-256color; echo $TERM` in local `bash` just now, the output is `xterm-256color`. If I miss something, please let me know. – John Jun 14 '22 at 13:16
  • Maybe you could post in your comment a screenshot.... – user1934428 Jun 14 '22 at 13:18
  • @CharlesDuffy `Unix & Linux` is very slow. And you see there are many questions about `bash` 、`ssh` on StackOverflow. So I think it's all right to do so. – John Jun 14 '22 at 13:22
  • Asking questions here when they belong there is part of _why_ it's so slow over there. – Charles Duffy Jun 14 '22 at 13:31
  • 1
    ...and yes, there are lots of questions that are on-topic about bash here, specifically those asking how to _write bash scripts_; which is software development. Merely _using_ bash is not software development. Same for ssh: A question that's specific to automating ssh in a script is software development and on-topic; whereas a question about using ssh manually as a human operator is off-topic. – Charles Duffy Jun 14 '22 at 13:32

1 Answers1

2

Try using the -t option to allocate a pseudo-terminal for the ssh session. For example

ssh -t user@192.168.1.59 top
Dima Chubarov
  • 16,199
  • 6
  • 40
  • 76
  • Yup, it works! Thank you for the rapid reply. Two more questions arise:1. why `ssh user@192.168.1.59 "ls" ` works, whereas `ssh user@192.168.1.59 "top"` does not? 2. why `ssh user@192.168.1.59 bash -c "***export TERM=xterm-256color***; top"` does not work, you see I set `TERM` indeed. – John Jun 14 '22 at 13:12
  • 1
    Use `top -n 1`. `-n` parm will tell top make a list of processes one time instead of continuous output from top which is why it never seems to work in your case. – GoinOff Jun 14 '22 at 13:30
  • @John, `ls` and `top` are very unlike each other: the former doesn't need any kind of terminal interaction; the latter is explicitly a tool for display to human users, and is expected to take enough control over the terminal to do things like rewriting in-place (the alternative that's more like `ls` is `ps`) – Charles Duffy Jun 14 '22 at 13:33
  • `ssh -t user@192.168.1.59 "top -n 1"` I just tried it out and it works great for me – GoinOff Jun 14 '22 at 13:37
  • @GoinOff Yup, both `ssh -t user@192.168.1.59 "top -n 1"` and `ssh -t user@192.168.1.59 "top"` work well. The problem is I did not add `-t` option. – John Jun 15 '22 at 01:27