I'm using WSL and ConEmu build 180506. I'm trying to setup a task in ConEmu to use the current directory of the active tab when opening a new console but I cannot get it to work.
What I did is to setup the task {Bash: bash} using the instructions on this page
setting the task command as :
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -C~ -cur_console:pm:/mnt
Then following the instruction on this page, I added to my .bashrc
if [[ -n "${ConEmuPID}" ]]; then
PS1="$PS1\[\e]9;9;\"\w\"\007\e]9;12\007\]"
fi
and finally setup a shortcut using the macro :
Shell("new_console", "{bash}", "", "%CD%")
But it always open the new console in the default directory ('/home/[username]').
I don't understand what I'm not doing right.
I also noticed that a lot of environment variables listed here are not set. Basically, only $ConEmuPID and $ConEmuBuild seem to be set.
Any help would be appreciated.
GuiMacro Shell was intended to run certain commands, not tasks.
You think you may try to run macro Task("{bash}","%CD%")
Or set your {bash} task parameters to -dir %CD% and just set hotkey for your task.
Of course both methods require working CD acquisition from shell. Seems like it's OK in your case - %d shows proper folder.
I found the answer:
Shell("new_console:I", "bash.exe", "", "%CD%")
The readme is actually pretty good: https://github.com/cmderdev/cmder/blob/master/README.md
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 able to set up in Workspace Settings for VS Code that my internal terminal should be a MSys2 bash shell. However the shell is started as an external shell, not internal. This does not happen for ex with git shell or ubuntu sub system shell
I have tried different settings found here:
How do I integrate MSYS2 shell into Visual studio code on Window?
No code to show, look at examples provided in the link to the other stackoverflow post.
I would expect the shell to be started as an internal shell to VS code
Append the user settings with the following JSON code:
// MSYS2
"terminal.integrated.shell.windows": "C:\\msys64\\usr\\bin\\bash.exe",
"terminal.integrated.shellArgs.windows": ["--login", "-i"],
"terminal.integrated.env.windows": {
"CHERE_INVOKING": "1"
},
having a small problem where you can help me out. On our new cluster we use LMod as environmental module system.
Creating a Module TCL Script for OpenFOAM, a system-dependent bashrc file need to be loaded.
This is the TCL script which I am using on another module system, it works fine. I am not able to execute the "source" command line in Lmod, what I am missing here?
#%Module1.0#####################################################################
##
## modules software/openfoam_v1812
##
## /opt/software/openfoam/openfoamv1812/OpenFOAM-v1812
proc ModulesHelp { } {
global version modroot
puts stderr "software/OpenFOAM-v1812 - sets the Environment for OpenFOAM-v1812 (openfoam.com)"
}
module-whatis "Sets the environment for using OpenFOAM-v1812"
# for Tcl script use only
set VERSION v1812
set OpenFOAM_PATH /opt/software/openfoam/openfoam${VERSION}/OpenFOAM-${VERSION}
set FOAM_INST_DIR /opt/software/openfoam/openfoam${VERSION}
puts stdout "source /opt/software/openfoam/openfoam${VERSION}/OpenFOAM-${VERSION}/etc/bashrc;"
I am not an expert, but I have recently come across a similar problem, in my case for activating Anaconda Python in a model. In my case, the solution was to use the 'execute' command in LMod
https://lmod.readthedocs.io/en/latest/050_lua_modulefiles.html
which has the documentation:
execute {cmd=”<any command>”,modeA={“load”}}
Run any command with a certain mode. For example execute {cmd=”ulimit
-s unlimited”,modeA={“load”}} will run the command ulimit -s unlimited as the last thing that the loading the module will do.
Hope this helps
I have the problem that I want to enable logging of a screen session at the start of it which then saves the log to a specific file.
What I have until now was:
screen -AmdSL cod2war /home/cod2server/scripts/service_28969.sh
while service_28969.sh is a shell script that will call other scripts which produce output.
I started multiple of those screen-sessions with different names, for example
screen -AmdSL cod2sd /home/cod2server/scripts/service_28962.sh
-L enables logging as the screen's man say, and will safe the ouput in a file called 'screenlog.0', now since I have multiple of those screens only one of it produces output saved in that log file (I can't find other 'screenlog.*' files in that folder).
I thought to use the -Logfile "file" option from the same man page, but it doesn't work for me and I can't find out what I'm doing wrong..
screen -Logfile cod2sd.log -AmdS cod2sd /home/u268450/cod2server/scripts/service_28962.sh
will produce the following error:
Use: screen [-opts] [cmd [args]]
or: screen -r [host.tty]
Options:
[...]
Error: Unknown option Logfile
and
screen -AmdS cod2sd /home/u268450/cod2server/scripts/service_28962.sh -Logfile cod2sd.log
will run without any error and start the screen but without the logging at all..
You can specify a logfile from within the default startup ~/.screenrc file using a line like
logfile mylog.log
To do this from the command line you can create a file mystartup to hold the above line, then use option -c mystartup to tell screen to read this file for setup instead of the default. If you also need to have ~/.screenrc read, you can add the source command to your startup file. The final result would look something like:
echo 'logfile mylog.log
source ~/.screenrc' >mystartup
screen -AmdSL cod2war -c mystartup /home/cod2server/scripts/service_28969.sh
This works for me:
screen -L -Logfile /Logs/Screen/`date +%Y%m%d`_screen.log
The configs I checked:
screen version 4.08.00 (GNU) 05-Feb-20 on FreeBSD 12.2
and
version 4.06.02 (GNU) 23-Oct-17 on Debian GNU/Linux 10 (buster)
and
version 4.00.03 (FAU) 23-Oct-06 on Mac OS X 10.9.5.
I just ran into this error myself and found this solution that worked with my python file, wanted to share for anyone else who might run into this issue:
screen -L -Logfile LOGFILENAME.LOG -dmS SCREENNAME python3 ./FILENAME.PY
I have no idea if this is the 'correct' way but it works.
-L enables logging
-Logfile LOGFILENAME.LOG declares what to call the log file and file format
-dmS SCREENNAME, dm runs in detached mode and S allows you to name the session
python3 ./FILENAME.PY in this case is my script but I assume that any other script here functions
I have tried a different ordering of these commands and this was the only way I managed to have them all run without issues. Hopes this helps.
I am trying to create a project which Vue-cli through Git bash Window.
Git version 2.14.1.windows.1
Vue version 3.0.0-rc.3
For some reason the cursor is still visible during installation.
And when I press any arrow key, the option does not change, only the cursor move around. (However, pressing enter still process me to the next step).
Searching for a solution with google does not let me anywhere, only a few Github bug report: https://github.com/vuejs/vue-devtools/issues/283
I had the same issue. The solution I came up with was:
$ winpty vue.cmd create `<project-name>`
Surprisingly, Windows Command Prompt is not suffered from this bug. So my solution is:
Hold Shift + Right click project folder -> choose Open command window here
This does not solve the root cause. If you happen to know a better option, please post your answer.
Note:
If you get error cannot execute scripts on powershell, then you need to enable script execution. Run powershell as administrator and run the following command to enable scripts on it:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
UPDATED 2021, Apr 4th!
Here's a CTRL+C and CTRL+V step-by-step practical solution to solve this. The fact that you have this trouble means you are on Windows and you most likely use Git Bash.
Using Git Bash a quick solution would be typing
echo 'alias vue="winpty vue.cmd"' >> ~/.bashrc
This will not overwrite .bashrc, and instead append the text on the left of >>
Restart your bash. That means close it and open it again.
If you're looking for "Why do I have to add such thing to .bashrc?", I think another user has mentioned that. If you found this helpful please upvote it so others can see it too.
Old answer
You can try to make a file .bashrc in your current <UserNameProfile>.
Then, inside of it use your favourite text editor and write
alias vue='winpty vue.cmd'
Then restart your bash. And you should be able to use vue as it should be on the documentation.
There are two ways to solve this issue which is explained in the Vue CLI Documentation:
1 - You must run the command as winpty vue.cmd create hello-world.
2 - If you still want to use the vue create hello-world syntax. You'll need to add the following line, alias vue='winpty vue.cmd', to your ~/.bashrc file. Then, you'll need to restart your Git Bash terminal session to pull in the updated bashrc file.
Git Bash is not an interactive shell. That's why you should use something that is by default interactive such as CMD or you have to do as mentioned in the Vue CLI doc:
If you are on Windows using Git Bash with minTTY, the interactive
prompts will not work. You must launch the command as winpty vue.cmd
create hello-world. If you however want to still use the vue create
hello-world syntax, you can alias the command by adding the following
line to your ~/.bashrc file. alias vue='winpty vue.cmd' You will need
to restart your Git Bash terminal session to pull in the updated
bashrc file.
Vue CLI is an interactive CLI. But Git Bash is not an interactive shell. That's why it won't work. Source