I've recently installed debian gnome alongside kali gnome. I'd setup a lot of keybindings in kali according to my needs. Is there a way I can port them to debian by, like, copying some config file.
Keyboard Mappings are stored in the dconf registry.
dconf-editor is a graphical tool to browse the registry.
For a textual representation you can use gsettings.
To find schemas which store keymappings:
gsettings list-schemas |grep keybindings
org.gnome.mutter.keybindings
org.gnome.mutter.wayland.keybindings
org.gnome.desktop.wm.keybindings
org.gnome.shell.keybindings
They can be printed like this:
gsettings list-recursively org.gnome.desktop.wm.keybindings
org.gnome.desktop.wm.keybindings cycle-windows-backward ['<Shift><Alt>Escape']
org.gnome.desktop.wm.keybindings minimize ['<Super>h']
org.gnome.desktop.wm.keybindings move-to-workspace-7 #as []
(..)
On the target machine enter the output with gsettings set .. in front of every line:
gsettings set org.gnome.desktop.wm.keybindings minimize "['<Super>h']"
Note that you need to put the value in quotes, or it will collide with shell substitutions.
Maybe something like this would be sufficient as transfer script for your keybindings:
gsettings list-recursively org.gnome.desktop.wm.keybindings |awk '{print "gsettings set "$1" "$2" \""$3"\""}'
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 am using versions:
ESXI 6.5.0 Update 3 (Build 14990892)
Power CLI VMware PowerCLI 11.0.0 build 10380590.
I have a VM that I am importing (ISO) into an ESXI and trying to set Autostart on the VM to "enabled" programmatically via some scripts, but it is not working. I am using the powercli command:
Set-VMHostStartPolicy (Get-VMHost | Get-VMHostStartPolicy) -Enabled:$true
I've also tried some variants of this command but none seem to work. I see the "event" get logged as "Reconfigure Autostart" under the "Recent Tasks" menu on the ESXI Web GUI as soon as I input the command, so its definitely configurating something, but when I double-check the state of the VM to see if Autostart is enabled, it still lists "Enable" as an option, implying Autostart is NOT enabled. Here's a screenshot:
Can anyone help me please? I just want to have this VM start automatically incase there is a power outage or server crash; But only in these cases, I want it to import powered OFF for the first time (as you can see in screen shot the EPS VM is imported but in a powered down state, which is what I want)
I think what you're doing is setting the host's default policy... You would think that would work. I'm using this code on ESXi 7.0 Update 1 to set the guest's policy:
$vmstartpolicy = Get-VM "$vm_name" | Get-VMStartPolicy
Set-VMStartPolicy -StartPolicy $vmstartpolicy -StartAction PowerOn
It has the same issue that it doesn't show in the web UI, (which somebody will complain about, and I'll have to fix) but it does auto-start the VM after a reboot, so at least it's a start (pun not intended).
Edit: After playing around a bit, I managed to find a solution that updates the UI.
plink -batch -ssh $user#$IP -l "$user" -pw "$password" vim-cmd hostsvc/autostartmanager/update_autostartentry "`$(vim-cmd vmsvc/getallvms | grep `"$vm_name`" | awk '{print `$1}')" "PowerOn" 0 1 "systemDefault" "systemDefault" "systemDefault"
Using plink to ssh into the host and run this vim-cmd, it updates the UI properly. Take note of the back-ticks (`) to escape the dollar signs (except the one with the $vm_name variable) and quotes in the sub command, so that powershell doesn't try to interpret them before sending them through the ssh tunnel. All the sub command does is get the all the VMs, use grep to filter down to the output line with the vm_name you specify, and use awk to print only the 1st column (the vm id required for the outer vim-cmd).
I have found a similar question here but without a working answer for me:
System Clipboard Vim within TMUX within SSH session
I'm using Gnome terminal to start a ssh session with X forwarding to Debian 10.
If I start neovim and copy (yank) text, then this text is copied to the Gnome clipboard and everything is fine.
This is the content of .ssh/config :
Host nuc
ForwardX11 yes
I have this in .vimrc:
set clipboard^=unnamed,unnamedplus
But when I start neovim inside tmux, then this doesn't work.
I have tmux with the tmux-yank plugin and this works because when I copy from neovim inside tmux and then exit tmux I can see the selected text with xsel -o
How can I get the selection forwarded to my system clipboard?
Vim and NeoVim support for clipboard use a connection to the X11 server. The address to connect is available from the $DISPLAY environment variable.
The issue with X11 and terminal multiplexers or session managers such as tmux or screen is that the environment of the shells and programs running inside them will be the environment of when the tmux session was first created. That includes the $DISPLAY variable. So it means vim inside tmux will be trying to use the address of the X11 server of when the tmux session was created, not the one from where you just connected now.
A dirty but simple workaround is to update the $DISPLAY variable when you reconnect to tmux, to ensure you'll be connecting to the correct X11 server. Note that you need to do that for every shell or program running inside tmux, since each of them will have its own out-of-sync copy of the environment variable.
Something like the following works:
$ ssh -X nuc
nuc$ echo $DISPLAY
:1234.1
nuc$ tmux attach
tmux$ export DISPLAY=:1234.1
tmux$ vim
This should make clipboard work for that particular Vim.
As mentioned, if you have many tmux windows and panes, you'd have to update $DISPLAY on all of them. Also, if you create new windows or panes, they will start with the wrong $DISPLAY setting too (though you can also update the value of $DISPLAY in tmux's environment to fix new windows and panes, see tmux's set-environment command for that.)
I am setting up my development environment, so I just installed Windows Subsystem for Linux and it always seems to open a fresh terminal in my Windows home directory - /mnt/c/Users/dl and I'm trying to make it default to the linux home directory - /home/dl.
I checked to see what the home directory is in the Linux subsystem in /etc/passwd and it is correctly set:
dl:x:1000:1000:,,,:/home/dl:/bin/bash
Then I came across this solution, but it doesn't seem to have any affect:
// Set starting directory
"startingDirectory": "\\\\wsl$\\Ubuntu\\home\\dl\\"
I know I can just run cd ~ in my dot files (which is what I'm currently using), but I'm looking for a way where /home/dl is just the default and cd ~ isn't needed. Is this possible?
You should only change the startingDirectory for WSL (Ubuntu in this case) terminal sessions.
Open settings.json via CTRL+SHIFT+,
Make sure you are modifying startingDirectory under profiles/list/name: "Ubuntu"
Example below (the slashes need to be escaped):
....
{
"guid": "{2c4de342-xxx-xxx-xxx-2309a097f518}",
"hidden": false,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"startingDirectory": "\\\\wsl$\\Ubuntu\\home\\windows_username_in_lower_case"
},
....
Documentation about startingDirectory including default values and expected values.
Inside settings.json you will also find an explanation of the json schema which is here
If you need to know how or where to edit Windows Terminal settings/preferences: https://learn.microsoft.com/en-us/windows/terminal/get-started
In Windows 10 21H2 or later and Windows 11, it's now much simpler. According to the Microsoft Doc:
On newer versions of Windows, startingDirectory can accept Linux-style paths.
That means you can simply use:
"startingDirectory": "/home/yourusername"
No need for any prefixes for Windows directory structure, nor escaped backslashes. Just plain old Linux forward-slash notation.
This works in both WSL1 and WSL2.
Note: I tried to use "~" and it failed. There may be some way to use {$USERPROFILE}, but haven't tried it.
Changing the home directory with WSL is done the same way as in Linux:
Enter bash
Type the command sudo vim /etc/passwd
Find your account's line, which might look like:
shadyar:x:1000:1000:"",,,:/home/shadyar:/bin/bash
Change the home directory, which above is /home/shadyar, to the new directory, using WSL
note: If you want to set Windows directory as home directory, you need to prepend it with /mnt/, like /mnt/c for C:/, /mnt/d for D:/, etc
Save the file and exit vim by typing :wq and press Enter
Exit bash and re-launch it
To test, use the commands:
cd ~
pwd
The other answers here (especially the latest one from #TomBoland) are great for starting in an arbitrary directory, but the example in your question was to start in your home directory. The easiest way to do that is simply to create or change the "commandline" property to wsl ~. This is an undocumented flag to wsl.exe, and it must be the first argument (e.g. wsl ~ -u root).
Current and Recent Windows Terminal Releases
Since Windows Terminal now has a GUI for Settings, you can just edit your profile to point to wsl ~ in the ->General->Command Line setting.
Older Windows Terminal Releases, or if you want to edit manually
If you are editing your settings.json directly (currently found in %userprofile%\AppData\Local\Packages\MicrosoftWindowsTerminal...\LocalState\settings.json, but this may change) ...
Remove the "source" attribute and replace it with "commandline":
"guid": "{2d5ef231-38b7-51cf-b940-2309a097f644}",
"hidden": false,
"name": "Ubuntu",
//"source": "Windows.Terminal.Wsl",
"commandline": "wsl ~",
"startingDirectory": "//wsl$/Ubuntu/",
"tabTitle": "Ubuntu"
Also, for the fun of it, here's an alternative (hacky) way to open WSL to ~/$HOME (without hardcoding as with the other answers). This is absolutely not needed since it's much easier to use wsl ~, but:
wsl -e sh -c 'cd $HOME; exec $SHELL'
This starts up sh, changes the directory to $HOME, and then exec's your $SHELL to replace the sh.
Should you use Windows Terminal with WSL, then the simplest solution is to configure the starting directory via the Settings menu:
and then:
startingDirectory Should be a windows path, not a nix path. Try D:\Folder\SubFolder instead
refer this link,worked for me
github
I tried many things here and none worked but I finally found a workaround.
After opening your ubuntu, you can set the default path by editing your .bashrc file.
I personally wanted to change it from the default /home/${my_username} to my current user directory (like command prompt C:/users/${my_username}), so I just ran this in my Ubuntu terminal
echo 'cd "../../mnt/c/users/${my_username}"' >> $HOME/.bashrc
Step 1: Open windows command prompt and type "bash"
or open Linux app directly .
Step 2: Type a route which is something like this : /mnt/c/Users/HP/..(You can enter your desired directory here).
For example : /mnt/c/Users/HP/Documents , and by this you will get inside Documents.
For WSL2 Ubuntu the syntax should now match the following example in the json:
"guid": "{2d5ef231-38b7-51cf-b940-2309a097f644}",
"hidden": false,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"startingDirectory": "//wsl$/Ubuntu/",
"tabTitle": "Ubuntu"
To start in /: "startingDirectory": "//wsl$/Ubuntu/",
To start in /root: "startingDirectory": "//wsl$/Ubuntu/root/",
To start in /home: "startingDirectory": "//wsl$/Ubuntu/home/",
No need to do any of that, just open up the profile for Ubuntu under settings, then update the Command line to add the following option
C:\Windows\system32\wsl.exe -d Ubuntu --cd ~
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