I'm having an issue when I try to run the code command from Visual Studio Code in WSL Ubuntu. I get the following error:
$ code .
/mnt/c/Users/Name/.vscode/extensions/ms-vscode-remote.remote-wsl-0.64.2/scripts/wslCode.sh: 63: /mnt/c/Users/Name/.vscode/extensions/ms-vscode-remote.remote-wsl-0.64.2/scripts/wslCode.sh: /home/barry/.vscode/bin/899d46d82c4c95423fb7e10e68eba52050e30ba3/bin/remote-cli/code: not found
When I run the following, it installs the VS Code Server and the command works as expected:
$ /mnt/c/Users/Name/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code .
When I run which -a code, I can see I have two paths related to this command and I believe the correct one is /mnt/c/Users/Name/AppData/Local/Programs/Microsoft VS Code/bin/code, but I don't know how to remove the first one or how it even related two paths to this command in the first place?
barry#RandomName:~$ which -a code
/mnt/c/Program Files/Microsoft VS Code/bin/code
/mnt/c/Users/Name/AppData/Local/Programs/Microsoft VS Code/bin/code
Can anyone help please?
Ran into the same problem 5 min ago and this post from thesteve0 worked for me:
https://github.com/microsoft/vscode-remote-release/issues/6294#issuecomment-1031974516
Quoting from the original post:
Open VS Code on Windows
Open Extensions and then search on WSL
It should say the extension needs to be reloaded - go ahead and reload it
Open WSL and type code
This should force another upgrade of code and this time it should launch.
I've managed to 'solve' it by creating a new Symlink to the correct directory so this one gets run first. I couldn't find a way to remove the incorrect directory so would appreciate it if someone knows a cleaner solution?
To add the Symlink, I ran ln -s /mnt/c/Users/Name/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code /usr/local/bin/code
So now I have these 3 paths for the code command:
$ which -a code
/usr/local/bin/code
/mnt/c/Program Files/Microsoft VS Code/bin/code
/mnt/c/Users/Name/AppData/Local/Programs/Microsoft VS Code/bin/code
Whenever I tried to remove rm or unlink /mnt/c/Program Files/Microsoft VS Code/bin/code (with sudo), I get permission denied.
Just run Vscode normally on windows. This will load wsl extension and solve the issue.
A simple sudo apt update -y and then rerunning code . fixed this for me.
I fixed my issue by opening wsl and removing the .vscode-server
rm -rf .vscode-server
i followed this link link to fix
Keep it simple S*upid method:
Download & install vscode again. link for windows
(Ubuntu example) apt update && yes | apt upgrade
Try to launch code from wsl
You should see something like:
Updating VS Code Server to version 5554b12acf27056905806867f251c859323ff7e9
Removing previous installation...
Installing VS Code Server for x64 (5554b12acf27056905806867f251c859323ff7e9)
In my case the extension in VS Code was not in a state needing reload like in the most upvoted answer. What helped after multiple attempts:
Terminate the WSL2 distribution (from the Windows CLI): wsl -t Ubuntu (replace Ubuntu with your distribution name)
Check that it is stopped: wsl -l -v
Start your WSL distribution again.
In my case the command code started to be accessible through a Windows directory: /mnt/c/Users/username/AppData/Local/Programs/Microsoft VS Code/bin/code
In C:\Users<user>.vscode rename path ms-vscode-remote.remote-wsl- to ms-remote-wsl-old
In WSL run: code .
I got two versions of Visual Studio Code installed, one said "(user)". I uninstalled both and installed the newest version via winget.
That fixed it for me.
I have got two different versions of visual studio code installed on my PC.
I have uninstalled the older version keeping the latest one.
This resolved issue for me.
Related
I have installed opam 2.1.0 on a Linux Virtualbox VM. When I try opam init, I get the following error:
<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
[ERROR] Could not update repository "default": OpamDownload.Download_fail(_, "Curl
failed: \"/snap/bin/curl --write-out %{http_code}\\\\n --retry 3
--retry-delay 2 --user-agent opam/2.1.0 -L -o
/tmp/opam-32196-d33843/index.tar.gz.part --
https://opam.ocaml.org/index.tar.gz\" exited with code 23")
[ERROR] Initial download of repository failed.
Running with --disable-sandboxing doesn't help. I know that its a problem creating/writing to /tmp/opam-... directory because if I replace that with my current directory or home directory the command by itself runs fine. It also runs fine with /tmp/opam-... if I use the --create-dirs option in curl but I don't have any way of getting opam init to use that option. Any ideas?
thanks
Update
The reason opam init failed for me was because curl was installed with snap on my system. This exactly what is going on with your VM.
Try to run opam init -verbose and that could reveal more about why you ran into an error.
In my case I needed to install other things with opam and it kept failing every time. So snap uninstall curl and then sudo apt install curl fixed things. (Was only able to figure this out with help from my professor)
Workaround
I ran into the same issue and I found a workaround on the OCaml forum: here. (Credits to UnixJunkie)
You can run:
opam init github git+https://github.com/ocaml/opam-repository.git
This should avoid the certificate issues. This worked for me.
I tried to fix the certificate issues using this answer as well. You could try doing that, but it seems complicated when the workaround is to simply point it to the github repo directly.
This question is similar to this one.
Since I have updated windows, my conemu terminal is giving me the following error each time a session is created:
wslbridge error: failed to start backend process
note: backend error output: -v: -c: line 0: unexpected EOF while looking for matching `''
-v: -c: line 1: syntax error: unexpected end of file
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
Has anyone an idea to bring conemu to a wsl terminal? Thank you
A similar error is caused by upgrading WSL from v1 to v2.
If you read through the discussion on this github issue for ConEmu you'll find a variety of instructions that can be distilled into:
Change the command for the task {Bash::bash} to the following:
wsl.exe
A GitHub user posted this workaround which worked for me:
I've fixed the issue by doing this:
Download latest cygwin1-20200531.dll.xz from https://cygwin.com/snapshots/ and unpack the file as cygwin1.dll into ConEmu\wsl\ (replacing the original file there)
Download #Biswa96's wslbridge2 from https://github.com/Biswa96/wslbridge2/releases and unpack to the same directory
Replacing {WSL::bash} task's Command with:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe -cur_console:pm:/mnt -eConEmuBuild -eConEmuPID -eConEmuServerPID -l
I can now access my Ubuntu under W10 just like before the W10 upgrade. Backscroll and arrows in VIM work as expected.
The key part of step 3 is to replace conemu-cyg-64.exe --wsl with conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe.
Longer term, it looks like the author of ConEmu is working on switching to the new Windows PTY API, which will eliminate the need for the wslbridge hack (and many others) entirely.
I had the same issue with last update windows
(Feature update to Windows 10, version 2004 - Successfully installed on 9/1/2020)
the error does not seem to be related to the version of WSL from 1 to 2:
$ wsl -l -v
NAME STATE VERSION
Ubuntu-20.04 Running 1
Nevertheless, this workaround worked for me as well, thank you so much!
Exactly this goes through upgrading WSL from v1 to v2.
You have to open cmder and in the startup command or Task enter {wsl.exe} and ready
cmder is working again.
Yes, the new command for WSL2 is much simpler, but just running wsl does not cause .profile to be read because launching this way does not request login shell, and it launches as root.
A better command is to specify the user id and to invoke the shell of your choice (bash is most common) with the appropriate option. For bash a login shell is desirable so .profile, .bashrc and .bash_aliases get sourced, if present. The -l (lower case L) does that:
wsl -U yourUserName bash -l
I am trying to install CKAN on my local computer using Ubuntu 14.04 LTS.
I followed the instructions for installing from source found here and I try to check if solr is running by visiting http://localhost:8983/solr/.
I can see that Jetty is running because when I visit http://localhost:8983 I see that it is up.
I added the jdk as follows:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk-amd64
I am getting a 500 error when i try to open the solr page:
HTTP ERROR 500
Problem accessing /solr/index.jsp. Reason:
JSP support not configured
Powered by Jetty://
Any ideas? Should I redo the whole thing from the start?
Edit/Update
I just couldn't do anything with this installation. The bigger problem was that installation files were meshed up! I tried to install tomcat/solr instead of jetty/solr and things went sour. So I just created a VM and did a fresh install there. For anyone interested I did a tomcat/solr installation following this and a CKAN installation following this (with out of course the solr instructions). Also, for some reason the CKAN installation has commented out the solr URL, so even if it is right, I had to delete the comment.
A fix has been documented by #mstantoncook here [2939] & [1651] How to solr-jetty JSP support
Note the last comment, sudo service jetty restart
It's a Jetty BUG on Ubuntu 14.04!
There is nothing wrong with Ckan itself.
Actually, there is a bug in the libjetty-extra-java package (version 6.1.26 and newer) in Ubuntu 14.04. The bug was introduced after Jetty (in Ubuntu) has changed it's dependences from libtomcat6-java to libtomcat7-java.
You can get more info about this bug in Ubuntu Launchpad: Bug #1508562 "Broken symlinks for JSP support in libjetty-extra-java version 6.1.26-1ubuntu1.1".
The bug is already fixed on Debian, and I'm hope it will be solved in Ubuntu 14.04 soon.
There are workarounds that may work for your case
I proposed some workarounds in this bug report, and since they can be useful for the Ckan users, I'll also replicate them here.
All of them consist on use both jetty and libtomcat7-java, but adding/replacing some classes (code ported from libtomcat6, in put in the jsp-2.1-6.0.2.jar file) to the Jetty classpath.
I don't know if they have some problem. Use them at your own risk!
Workaround 1 - Install the fix package proposed by vshn
I found this workaround here: https://github.com/ckan/ckan/pull/2966
In short:
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
service jetty restart
This will install a JSP jar that works (the file will be named jsp-2.1-6.0.2.jar, but it contains classes ported from libtomcat6).
Workaround 2 - Manually install the JSP jar
Download the same JAR file that the DEB package above would install.
wget https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562/+attachment/4785985/+files/jsp-2.1-6.0.2.jar
Now, move it to a proper location inside the Jetty config dir. I did it this way:
mkdir /etc/jetty/extra-jars
mv jsp-2.1-6.0.2.jar /etc/jetty/extra-jars
And add a line like this one in the Jetty start.config file:
echo "/etc/jetty/extra-jars/jsp-2.1-6.0.2.jar" >> /etc/jetty/start.config
And:
service jetty restart
Correct solution
The correct solution is to wait for the Ubuntu Team solution. However, while waiting for this fix, you can use any of the previous workarounds (I prefer the last one).
I hope they help you!
Try this steps:
sudo mv jsp-2.1-6.0.2.jar /usr/share/jetty/lib/.
change own:
sudo chown root:root /usr/share/jetty/lib/jsp-2.1-6.0.2.jar
finally restart jetty:
sudo service jetty restart
I followed this steps and now I can see localhost:8983/solr and localhost/solr/admin
In Ubuntu 14.04 this can be fixed with:
cd /tmp
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
sudo dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
sudo service jetty restart
Following http://docs.ckan.org/en/ckan-1.6/solr-setup.html#single-solr-instance
(this one a bit old, but worked perfect for me )
You will have to edit /etc/profile and add this line to the end such as this to the end (adjusting the path for your machine’s jdk install:
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/ (or other version)
then
export JAVA_HOME
sudo service jetty start
I can't get sencha command 3.0.0.250 to install correctly.
I'm on OSX 10.7.5. Using zsh shell.
Installing sencha command I install to the default "users/mark/bin"
I've downloaded sencha touch 2.1.0 commercial and navigated to that sdk folder. Running "sencha" in terminal gives "zsh: command not found: sencha"
I guess I'm installing to the wrong directory?
Advice would be appreciated.
If anyone else is having this problem, the solution is to create an alias in your .zshrc file to the sencha executable. In my case this looked like this
alias sencha="~/bin/Sencha/Cmd/3.0.0.250/sencha"
The command:
alias sencha="~/bin/Sencha/Cmd/3.0.0.250/sencha"
Will work BUT... make sure that you match the number of the version that you installed. ie:
alias sencha="~/bin/Sencha/Cmd/<version number installed>/sencha"
Took me an hour to figure this out...
On the terminal, run:
nano ~/.zshrc
then add:
alias sencha="~/bin/Sencha/Cmd/<VERSION NUMBER>/sencha"
save the file and restart your terminal.
This should do the trick.
I am trying to use the static binary of wkhtmltopdf on Ubuntu server 10.0.4. The reason for is that it apparently has a built in modified QT that will allow me to run wkhtmltopdf without an X Server.
Result:
Once installed (see steps below), when I execute wkhtmltopdf in the terminal, it does not fire up... just returns me to the prompt - like it ran and did something, no error but no output:
:/usr/bin$ wkhtmltopdf
:/usr/bin$
Same behavior if I put args:
:/usr/bin$ wkhtmltopdf http://www.google.com test.pdf
:/usr/bin$
Am I doing something wrong --- my understanding that the static binary should just fire up. Perhaps missing some dependency? Is there a way to get some verbose output?
These are the steps I have followed:
In /usr/bin:
1) Confirmed that the existing (non-static) wkhtmltopdf resides there and that it executes. When I execute it with no args I get the help/about output from the app.
2) Moved the existing wkhtmltopdf out of the directory (renamed it)
3) Get the static binary: sudo curl -C - -O http:
//wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.9.9-static-i386.tar.bz2
4) Untar: tar xvjf wkhtmltopdf-0.9.9-static-i386.tar.bz2
5) Rename: mv wkhtmltopdf-i386 wkthtmltopdf
6) Get (apparently) necessary packages: sudo apt-get install openssl build-essential xorg libssl-dev
I was having the same problem. I removed the existing wkhtmltopdf and followed the steps below and the installation worked.
First, installing dependencies
sudo aptitude install openssl build-essential xorg libssl-dev
for 64-bit OS
wget http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.9.2-static-amd64.tar.bz2
tar xvjf wkhtmltopdf-0.9.2-static-amd64.tar.bz2
chown root:root wkhtmltopdf-amd64
mv wkhtmltopdf-amd64 /usr/bin/wkhtmltopdf
The only difference is that I put it in /usr/local/bin/wkhtmltopdf.
I hope this helps!
Following deb's answer got it working for me on Ubuntu 10.04 64bit - thanks!
Although rather than downloading 0.9.2 as per deb's instructions, I would suggest people download the latest version by:
Go to http://code.google.com/p/wkhtmltopdf/downloads/list
Download the latest version of wkhtmltopdf-[version number]-static-amd64.tar.bz2
At this time, the latest 64bit is http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.11.0_rc1-static-amd64.tar.bz2.
In my debian server trying to run wkhtmltopdf-i386 lead to same blank prompt.
Non-static (with non-patched QT) version of wkhtmltopdf installed with "aptitude install wkhtmltopdf" is worked.
Problem solved by switching to wkhtmltopdf-amd64, server was a 64 bit and i missed it.
After that, wkhtmltopdf-amd64 says 'libxrender shared library not found', this problem was solved by "aptitude install xorg"
0.11.0_rc1 seems to be buggy.
It keeps throwing the error "Cannot create a QPixmap when no GUI is being used".
Reverting to 0.9.9 worked for me.