When invoke vi in a session inside SCREEN, I always encounter error:
bash-3.2$ vi perf332.db2
ex: 0602-108 screen is not a recognized terminal type.
[Press return to continue]
[Using open mode]
After I explicitly export TERM=xterm or something, it works fine.
My SCREEN is running on a Linux server, and I SSH from there to a AIX server.
The default TERM variable for screen is TERM=screen. This is what its supposed to be.
You might consider putting something like this in your .bashrc to change the TERM variable to xterm when its screen.
if [[ $TERM = screen ]]; then
export TERM=xterm
fi
However I do not recommend doing this as this might confuse other application.
It seems vi does not know how to send commands to screen when the TERM variable is set to screen. The other way of getting around this would be to install vim which does understand how to communicate with screen.
Try putting shell -$SHELL into your ~/.screenrc file
Related
While installing a new RHEL on KVM host I am displaying a text file using more command. Problem is more is behaving like cat in virt-manager i.e. not displaying page-by-page and directly scrolling to the end of the page. I tried using less instead of more but it is displaying the same behavior.
Can anyone suggest what could be the reason for this?
Edit Based on comments I tried changing TERM to xterm during first boot. But that didn't have any effect. I tried this command export TERM=xterm
I got the env variables printed. I am pasting it hoping this might be a clue.
Edit I couldn't get it working. I noticed that before the script is executed, some other script is running and this might be setting some environment variable because of which more isn't working. I am now calling more command before this script start executing. And now it is working.
I suspect your environment is not correct. Specifically your $TERM environment variable may not be set. See here for the more manual entry.
The more command respects the following environment variables, if
they exist:
MORE This variable may be set with favored options to more.
SHELL Current shell in use (normally set by the shell at login
time).
TERM The terminal type used by more to get the terminal
characteristics necessary to manipulate the screen.
VISUAL The editor the user prefers. Invoked when command key v is
pressed.
EDITOR The editor of choice when VISUAL is not specified.
After help from a senior dev, I found out what was happening behind the scenes.
Suppose A.sh is executing more command like below:
more pathtofile
A.sh is being called by some other script like below:
pathtoA.sh | tee
Because of this tee command, more command in child script was not behaving as it should have been.
I want to open a new xterm with a custom prompt string.
Since prompt is set using the prompt variable, I thought I could just run:
xterm -e "set prompt = $prompt_string_of_my_choosing" #The organization I work for uses tcsh
The problem is, I want the xterm to stay interactive.
I tried tcsh -c as a command for -e, I tried sourcing another script that would set the prompt to the way I want it . The results I'm getting are either an interactive shell with the default prompt, or an xterm that just closes (or stays open with -hold but not interactive).
I was however able to bypass the problem by adding the following to ~/.cshrc:
if ($?calling_prompt) then
set prompt = "$calling_prompt"
endif
And of course I preset the $calling_prompt variable in advance.
This works, but requires me to edit ~/.cshrc, so it's not a global solution.
Any ideas?
Maybe you can set variable being a flag for your new term and than use this approach:
http://www.owsiak.org/?p=2582
This way, you can alway set whatever you like in prompt - e.g. based on type of term you have started.
I want to use the PS1 setting in my .bashrc file to change the color of the terminal based on whether I'm on my local machine or using ssh.
My current .bashrc file on both my local machine and the ssh server is (the default):
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
I've tried adding "\e[40m" to the end, but only changes part of the background of the terminal, leaving a black bar in the middle
How would I go about changing the PS1 setting to, say, my local terminal is dark blue and the ssh terminal is dark gray?
Thanks!
Just out of curiosity, doesn't that remote machine set its own PS1 value which means however you set your prompt locally, that remote machine will override it?
One way around this is to setup a function to replace your actual ssh command. Have that function set the color of your terminal, and then run the actual ssh command:
function ssh_function
{
printf "\e[40m\e[37m" # Grey on black
clear
\ssh $# || read # Actual ssh command
printf "\e[0m" # Reset terminal
clear
}
Now, create an alias:
alias ssh="ssh_function"
Now, when you run ssh, it will run your ssh_function which sets the screen color before executing ssh and then resets your screen colors once out of ssh. The clear is to clear your terminal, so you get a constant color. Otherwise, it merely resets the color at your prompt.
And then hope that the remote PS1 environment variable doesn't reset the terminal color on you.
I have a redhat machine which I use remotely using putty and this is what have been bugging me a lot now...
Each time I open and close a file with any editor, my prompt shows up on the bottom line without the content of the screen being refreshed. This is really problematic because then I can't see previous outputs that were on the screen just before I opened that file which is still showing up after closing.
Is there a way to fix this. I want it to behave like the gnome-terminal. I don't think this use to happen when I was using an ubuntu server.
I understand that this is the traditional tty behavior, but I don't want it...
Thanks in advance.
If your terminal supports an alternate screen buffer, it should have rmcup and smcup define in its terminfo entry
% infocmp | grep -e rmcup -e smcup
ri=\EM, rmacs=^O, rmcup=\E[2J\E[?47l\E8, rmir=\E[4l,
smcup=\E7\E[?47h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
If enabling altscreen in your .screenrc doesn't fix it, try adding these 2 lines to your .vimrc:
set t_ti=^[[?47h
set t_te=^[[?47l
(note that ^[ is escape, I typed ctrl-v esc)
Vim will echo ti to the terminal on startup and te on exit, instructing the shell/xterm/screen to switch screen buffers.
When running a vim instance in gnu screen hitting shift enter in insert mode adds an 'M' and then a newline, rather than just a newline.
Does anybody know what the problem might be, or where to look?
Relevant system info:
Ubuntu 8.04.1
Screen version 4.00.03 (FAU) 23-Oct-06
VIM - Vi IMproved 7.1 (2007 May 12, compiled Jan 31 2008 12:20:21)
Included patches: 1-138
Konsole 1.6.6 (Using KDE 3.5.10)
Thanks to the comments. When checking the value of $TERM I noticed that it was xterm (as expected), but within screen $TERM was set to screen-bce. Setting TERM=xterm after launching screen resolves this issue.
Adding the following to ~/.screenrc solved the problem without having to do anything manually:
term xterm
Missing info from your question:
Where do you run screen and see this issue? Some terminal app (KTerminal, Gnome terminal, virtual console etc) or remote session (eg putty, ssh from another computer)
do a “echo $TERM” and tell us its output
do a “cat -v”, press Shift-Enter, then Enter, then Ctrl-D and then tell us what is output.
First, you could fix your $TERM for within konsole. Install "ncurses-term" and configure konsole to set $TERM=konsole-256color. Then configure screen with "term screen-256color". Or 'konsole' and 'screen', respectively, if that's your preference. Konsole and screen are not xterm and doesn't support everything xterm does, so using incorrect $TERM can lead to bad things.