Tag Info

New answers tagged

2

GNU screen is setting $TERM locally, and ssh is passing that value to the remote side. There are a few things you can do. Detect the screen-256-color-s on the remote side and set to a more sane. From that you can have case $TERM in screen-256*) TERM=screen;; esac. From the local side, have screen set the terminal. In your ~/.screenrc file have: term ...


3

Just set another TERM, For example TERM="rxvt" or TERM="xterm" or TERM="vt102" Maybe an export TERM helps too. The TERM variable is used by curses and termcap programs, such as mc or dialog, to read the terminal escape codes from the terminfo/termcap databases, where the command is executed, so in your case in the remote system. To support the ...


0

Interesting question. I just skimmed through man screen so I am not absolutely sure whether it is possible to achieve without using external tools. However, one can use a named pipe and a combination of tail and grep to do this: $ mkfifo /tmp/fifo/fifo $ tail -f /tmp/fifo/fifo | grep --line-buffered bar >> /tmp/DONE Inside screen do: logfile ...


3

You use the -X switch. From the man page: -X Send the specified command to a running screen session. You can use the -d or -r option to tell screen to look only for attached or detached screen sessions. Note that this command doesn't work if the session is password protected. To combine this with actually seeing the screen: ...


1

tput tells you what the terminal advertises as its function keys. Terminals often don't advertise all the function keys and keychords that they support. To see what escape sequences the terminal actually sends, use the Ctrl+V method mentioned in that same answer: press Ctrl+V in a terminal application that doesn't rebind the Ctrl+V key (such as the shell). ...


0

There are no more log files you can check. Make sure that you catch each exception in your code and write a message via your logger and/or e.printStackTrace().


0

I found a temporary solution which may be the only possible solution. It may bring light on the actual cause so I won't accept my own answer for a few days but I will after that point. By connecting to the device through a virtual machine, although the crashes are just as frequent, the connection can be force closed by disabling and re-enabling the link ...


1

Your screen session is probably hung waiting for the pseudo-terminal of the shell that you last attached to the screen with. Sometimes a lost connection leaves that shell around and screen has to timeout in order to detach from it. If you run ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>, you should see that it is the pts of for the ...



Top 50 recent answers are included