I use Ubuntu 18.04 on a WSL system and usually log on a Linux server through ssh to get some work done. When I activate 'screen' and use the tab key to autocomplete commands, my cursor goes to the end of line, and the formatting of my entire terminal breaks from then on.
When using vim in that condition on a screen terminal, if I go to the end of file and press down on more time, it erases the last line from the terminal.
It seems a kind of misinterpretation of some terminal signal. When using Putty or any other ssh client under the same circumstances, everything works fine, so I am pretty sure it is a problem with WSL environment, specifically.
Any ideas about what is the main issue and how to solve it?
I just came across this same exact issue and it appears to be a possible bug with Windows Console and certain $TERM values.
I have this problem when $TERM is set to screen-256color. The problem went away after setting $TERM to xterm-256color in .screenrc
$ cat ~/.screenrc
term xterm-256color
Related
I have properly installed and setup WSL2. It works fine.
I also setup X11 forwarding and X server (VcXsrv). I can launch GUI apps such like konsole or gvim or even google-chrome from a bash shell.
Now I want to launch konsole by simply double clicking a short cut on the desktop without launching the bash command mode terminal. How should I do it?
I tried running this in cmd:
> wsl /usr/bin/konsole
and it reports:
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
I'm guessing it is because some X11 forwarding configurations were not properly setup, so I created a k.sh as follows:
#!/usr/bin/bash
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
export LIBGL_ALWAYS_INDIRECT=1
/usr/bin/konsole &
The first two lines were the X11 settings in my .bashrc, the last line launches konsole.
It works fine under bash environment; but when I ran
wsl k.sh
from windows cmd environment, it silently quitted without launching the konsole.
I'm out of ideas. What should I do to directly launch konsole or other Linux GUI apps under windows without having to getting into bash?
Thanks in advance.
You are asking about two different command-lines, and while the failures in running them via the wsl command have the same root-cause, the underlying failures are likely slightly different.
In both cases, the wsl <command> invocation results in a non-login, non-interactive shell where the command simply "runs and exits".
Since the shell is non-login/non-interactive, your startup files (such as ~/.bashrc and ~/.bash_profile, among others) are not being processed.
When you run:
wsl /usr/bin/konsole
... the DISPLAY variable is not set, since, as you said, you normally set it in your ~/.bashrc.
Try using:
wsl -e bash -lic "/usr/bin/konsole"
That will force bash to run as a login (-l), interactive (-i) shell. The DISPLAY should be set correctly, and it should run konsole.
Note that the quotes probably aren't necessary in this case, but are useful for delineating the commands you are passing to bash. More complicated command-lines can be passed in via the quotes.
As for:
wsl k.sh
That's likely a similar problem. You are doing the right thing by setting DISPLAY in your script, but I notice that you aren't using a fully-qualified path it. This would normally work, of course, if your script is in a directory on the $PATH.
But I'm guessing that you might add that directory to the $PATH in your startup config, which means (again) that it isn't being set in this non-login, non-interactive shell.
As before, try:
wsl -e bash -lic "k.sh"`
You could also use a fully-qualified path, of course.
And, I'm fairly sure you are going to run into an issue with trying to put konsole in the background via the script. When WSL exits, and the bash shell process ends, the child konsole process will terminate as well.
You could get around this with a nohup in the script, but then you also need to redirect the stderr. It's probably easiest just to move the & from the script itself to the command-line. Change your k.sh to:
#!/usr/bin/bash
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
export LIBGL_ALWAYS_INDIRECT=1
/usr/bin/konsole
Then run it with:
wsl -e bash -lic "k.sh &"`
Finally, a side note that when and if you can upgrade to Windows 11, it will automatically create Windows Start Menu entries for any Linux GUI app you install that creates a .desktop file. You can manually create .desktop files to have WSL create Start menu items for most applications.
For reference, in Windows 11 it's easier. To run a GUI application without a terminal window popping up, you just need to call wslg.exe instead of wsl.exe.
So, for example:
target: C:\Windows\System32\wslg.exe konsole
start in: C:\WINDOWS\system32
shortcut key: None
comment: Konsole
This tutorial shows how to install VcXsrv and and edit .bashrc to ensure that the "DISPLAY env var is updated on every restart".
DISPLAY env var needs to be dynamic setting.
I've used it successfully with WSL2 on Windows10 Version 21H2 (OS build 19044.2130) to run Chrome, Edge, and thunar. I'm using the Ubuntu 20.04 Linux distro.
To edit .bashrc follow these instructions.
I use tmux (tmux 1.8) from Ubuntu 14.04.
I wanted to configure it a bit via ~/.tmux.conf. But whatever I set inside this file my tmux session looks the same. Then I tried a fresh new /etc/tmux.conf but I still get the same display.
It seems that my config is hardcoded and that I cannot change it.
If I remove these two files (~/.tmux.conf and /etc/tmux.conf) my tmux session is still the same. Tmux runs but I can not configure it. But it should be so simple...
Does anybody have already seen this? And how I could solve that? Do I need to compile a fresh new release of tmux?
Today, I have more details :
on one machine it works as expected. It's OK. But I did not changed anything! Strange...
But on another machine (also running Ubuntu same release and up2date like the first machine) it does not work.
The file /etc/tmux.conf does not exist on none of these 2 machines. I put this little config file (~/.tmux.conf) :
# start Window Numbering at 2
set -g base-index 2
When I launch tmux on this second machine, window numbering starts at 0. On the first machine with the same config file, it behaves correctly : it starts at 2.
I'm going crazy!
After you make changes to ~/.tmux.conf make sure tmux sources them with the tmux source-file ~/.tmux.conf shell command.
Try removing all sessions before running tmux. I have noticed that if you have sessions still running, tmux will still load the previous .tmux.config file.
Executing tmux kill-server can stop the server and then try to run the server again using tmux command.
Please note that after killing the server you will lose all open sessions / tabs.
I am using ConEmu and am totally satisfied with it except for the fact that if I use PuTTY for SSH access, I can then run commands on the remote machine like vim or nano or mcedit or others which opens some kind of a curses-interface and I can see the console commands history, but when I use CygWin SSH client or OpenSSH for Windows I cannot see the commands history anymore after running vim/nano/mcedit/whatever else.
When I quit those programs (:wq in vim, Esc key in mcedit, Ctrl^X in nano) I can see all the previous commands executed, like this (if I use PuTTY):
Run PuTTY and connect to some host
You will see something like that in history:
host$ whoami
user
host$ vim
...do something in vim then press :wq
And you should see exactly this:
=== Cut ===
host$ whoami
user
host$ vim
host$
=== Cut ===
all the previous commands (whoami) are visible. However if I run ConEmu and then use SSH client from CygWin (or OpenSSH client, it doesn't matter) the following happens:
Run ConEmu
ssh user#somehost
host$ whoami
user
host$ vim
...do something in vim then press :wq
And now the screen is empty! No history! You just see this:
=== Cut ===
host$
=== Cut ===
As if no whoami was executed. Same happens for mcedit, nano or any other programs that has something like a "screen". Also same happens with Ctrl-O in Midnight Commander, in PuTTY everything is nice, but when using ssh from CygWin in ConEmu (or OpenSSH Windows client) and running Midnight Commander each Ctrl-O just shows an empty history. As if nothing was typed previously. That is really not nice at all.
Is there any way to fix that?
The standard TERM environment variable for PuTTY.exe is xterm and that will mostly work for Cygwin ssh.exe as well. However, a better TERM environment variable for ssh.exe is cygwin.
When you use Cygwin ssh.exe to connect to another system, Cygwin processes your escape sequences, not ConEmu. In fact you get the same behavior whether you are running ssh.exe inside or outside of ConEmu. So the problem is not really related to ConEmu at all, at least not its ANSI processor.
The solution is to use the cygwin for the TERM environment variable on the remote system. In fact, the SSH client and server cooperate to do this for you automatically. But perhaps you have accidentally overridden the supplied TERM variable with say xterm in your .bash_profile or whatever. In that case, the escape sequence to restore the screen buffer after exiting the editor won't be correct for the Cygwin ANSI processor.
You can do this test to check whether this solves your problem:
$ export TERM=xterm
$ vim
$ # the screen before is cleared
$ export TERM=cygwin
$ vim
$ # the screen buffer is restored
I am looking for a solution that would update the window title to the current host.
I am usually doing ssh to different boxes and I observed that the window title in Gnome Terminal (3.0.1 from Ubuntu 11.00) is not correctly updated. Currently it displays "user#localcompure: path" - and I want to be updated after I do a ssh.
I should note that I am looking for a solution that will not require me to change settings on any machine I'm connecting to.
I'm looking to do the same here, the functionality works fine in konsole(kde's terminal app) but not from within gnome-terminal. The best solution I have found thus far is to invoke this by using a separate app with the following:
#!/bin/bash
#!/bin/bash
SETTP='MY_PROMPT="$HOSTNAME:$PWD\$ "'
SETTP="$SETTP;"'MY_TITLE="\[\e]0;$HOSTNAME:$PWD\a\]"'
SETTP="$SETTP;"'PS1="$MY_TITLE$MY_PROMPT"'
ssh -t $1#$2 "export PROMPT_COMMAND='eval '\\''$SETTP'\\'; bash --login"
found and copied from:
https://unix.stackexchange.com/a/40337?sgp=2
My .screenrc has some initialization code that opens some windows. It's neat.
What I want to do, while running screen is simply , with one command open a new screen window that is running a program.
It SHOULD be:
screen -t 'CADMIN' sudo cherokee-admin -b
This actually works, except that it also runs my .screenrc and opens up all of my
windows in a nested screen. FAIL.
I know I could use
^c ( to create a new window )
^cA ( to title it )
sudo cherokee-admin -b
and get the same effect, but I'd like to bring a little elegance to my life, which
is why I use screen and not some multi terminal thing.
Ideas?
Ok, I've got a somewhat palatable answer:
from the bugs page there is a discussion about problems using the screen -t invocation.
I've tried this and I find that screen -c /dev/null -t CADMIN sudo cherokee-admin -b actually works the way I originally thought it would. It's kind of nifty actually, -c calls nothing for the value of .screenrc, which does not open my glorious screen rig. I can live with this.
You could setup another .screenrc file that doesn't have all of the other windows in it then in your .bash_profile you could add something like:
alias scn="screen -c '.screenrc2' -t 'CADMIN' sudo cherokee-admin -b"
then all you would have to do is run $scn from the cli to open screen with the desired effect.
hope this helps
edit: Make sure you name the second .screenrc file something different (i.e. '.screenrc2')