I'm trying to use LiteIDE (the Go IDE) on Linux 32-bit. Everything works except for autocomplete. Builds, running, everything works. The gocode binary seems to be running tho:
ithisa#miyasa ~> ps aux | grep gocode
ithisa 10003 0.0 0.0 823788 2624 pts/1 Sl+ 09:06 0:00 /home/ithisa/scratch/liteide/bin/gocode -s -sock unix -addr localhost:37373
What might I be doing wrong?
You may need to set a GOROOT=. To set it within LiteIDE, look for the environment toolbar; it should be a a dropdown, probably with "system" preselected, and a button. Click the button to bring up the Edit Environment pane, then double-click "system.env", or whichever environment was picked in the dropdown.
Change the line that starts GOROOT= to point to your 'go' directory. Plain old $HOME/go is a common setting if you installed it from golang.org, and if you don't know where it is, running go env will show the GOROOT that the Go toolchain itself is using. And of course if the line is commented out (#GOROOT=...) remove the #. Save.
If the toolbar is missing entirely, View -> Environment toolbar unhides it.
It's probably also worth setting GOROOT and related settings in your .bashrc, so tools started from the command line see it. I installed Go and LiteIDE in my homedir and my workspace is ~/gocode, so mine is like:
export PATH="$HOME/go/bin:$HOME/liteide/bin:$PATH"
export GOROOT=$HOME/go
export GOPATH=$HOME/gocode
I can't be certain this is actually your issue, but if I unset my GOROOT the symptom matches what you're seeing: completion works on my code, but not on the standard library. Good luck!
Did you install gocode?
https://github.com/nsf/gocode
Also, does nothing autocomplete or just new packages? Packages need to be installed to autocomplete. Do you have a standard install setup?
Your GOROOT and GOPATH should also be correctly setup.
I've got the exact same problem, except for 64-bit linux (ArchLinux)
I got this solved by:
set up correct GOROOT and GOPATH, for example:
$ cat ~/.bashrc | grep GO
export GOROOT=/usr/lib/go
export GOPATH=~/goroot
PATH="$PATH:$GOPATH/bin"
bash
installing/starting gocode daemon
$ go get -u github.com/nsf/gocode
$ gocode -addr=:37373
$ gocode status
set correct GOROOT on LiteIDE config file:
sudo vim /usr/share/liteide/liteenv/linux64.env
GOROOT=/usr/lib/go
For me gocode (autocomplete) broke in LiteIDE after updating Go to the latest version.
What I did was make sure GOPATH was set correct. Then install gocode:
go get -u github.com/nsf/gocode
Then remove the gocode version from the liteide/bin/ folder, because else LiteIDE will use its own version (I only renamed it just in case).
Now when you boot LiteIDE it should say
GolangCode: Found gocode at <YOUR GOPATH>/bin/gocode
instead of LiteIDE using its own version.
Related
At first, I tried to fix my problem of npm instruction
so I added
[interop]
appendWindowsPath = false
to /etc/wsl.conf
It works, but another problem happen.
When I type code .
Command 'code' not found, did you mean:
command 'node' from deb nodejs (12.22.9~dfsg-1ubuntu3)
command 'cdde' from deb cdde (0.3.1-1build1)
command 'ode' from deb plotutils (2.6-11)
command 'tcode' from deb emboss (6.6.0+dfsg-11ubuntu1)
command 'cde' from deb cde (0.1+git9-g551e54d-1.2)
Try: sudo apt install <deb name>
The above Error message appear.
I tried the following instruction
export PATH=$PATH:"/mnt/c/Users/%USERNAME%/AppData/Local/Programs/Microsoft VS Code/bin"
It also works properly.
Whenever I restarted WSL, npm instruction still worked well, but code instruction lost its function again.
What should I do to fix the problem?
Thanks in advance!
My main suggestion would be to not use appendWindowsPath = false to fix your NPM problem. That's like using a sledgehammer as a flyswatter. As I said in this answer:
Please do not follow the recommendations (like this answer) to completely remove all Windows paths from WSL, as that will severely limit your ability to run Windows applications in WSL (one of its great features).
You'll also lose access to the ability to run PowerShell scripts and commands in WSL easily. You won't have direct access to wsl.exe itself from inside WSL (which comes in handy).
You can type the full paths to these commands, of course, but most instructions and other answers you find here are going to assume that you've left the Windows path intact.
Instead, figure out where npm is installed in your WSL distribution and then determine why it is further toward the end of the PATH than your Windows directories. Windows paths are added at the end of the Linux PATH for a reason. If something in your startup files is adding to the path, it should put it at the beginning, so it has precedence. E.g.:
export PATH="newdir:$PATH"
Note that I'm not saying that you should change your export statement above since, as mentioned, that Windows path would normally come at the end anyway. It's really not going to matter unless you put another code executable somewhere else in your path.
Whenever I restarted WSL, npm instruction still worked well, but code instruction lost its function again.
If you do want the "quick and dirty" (not recommended) solution, then you can simply add that export command that "makes it work" to your ~/.bashrc. That file is processed each time the Bash shell starts interactively.
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.
Every time when I open the terminal in ubuntu and try sudo apt-get autoremove
can someone guide me on what to do?
Thanks
#The output will show this error
/usr/sbin/update-info-dir: 2: /etc/environment: JAVA_HOME: not found
dpkg: error processing package install-info (--configure):
installed install-info package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
install-info
E: Sub-process /usr/bin/dpkg returned an error code (1)
Currently my /etc/environment contains this informations
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/>
JAVA_HOME = /usr/lib/jvm/jdk-15
Basically, you have stuffed up the "/etc/environment" file:
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/>
JAVA_HOME = /usr/lib/jvm/jdk-15
The first line should not end with a > character. And there is a missing ". And it doesn't make sense for the root directory ( / ) to be on the search path.
The second line should not have spaces before and after the =.
However, I don't know exactly what the video tutorial was trying to tell you to do ... or why it even suggested that you should edit that file. (I certainly wouldn't mess with that file!!)
My advice:
Find and >>read<< a Linux tutorial (or book!) on how to use the shell. It will explain what environment variables, how they are set and how they are used. It will also explain what PATH is and what it should contain.
I do NOT recommend watching videos. My observation is that they are too superficial and will often leave the viewer thinking that they understand, when they don't.
Revert the "/etc/environment" file to what it was before you started.
Either watch the video again and make the changes more carefully ... OR ... don't change it. If you don't change it you can put the environment variables into your shell startup script; e.g. "~/.bash_profile" if your shell is bash; see step 1!
In Ubuntu 20.04, If you installed Android Studio from the snap store, It comes with java.
You can set JAVA_HOME and ANDROID_HOME as follows:
Edit file ~/.bashrc with gedit
Run gedit ~/.bashrc
Add the following lines at the end of the file.
export JAVA_HOME=/snap/android-studio/current/android-studio/jre
export PATH=$JAVA_HOME/bin:$PATH
export ANDROID_HOME=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/tools
export PATH=$PATH:$ANDROID_HOME/tools/bin
export PATH=$PATH:$ANDROID_HOME/platform-tools
For reload run source ~/.bashrc
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
I'm using rvmrc with the following text:
rvm_path=/local/rvm
(on Ubuntu 11.10) but trying to install gives an obscure error:
$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
Successfully checked out branch ''
Current branch master is up to date.
Successfully pulled (rebased) from origin
: No such file or directory
Any ideas?
You have no need at all to set $rvm_path. You're using a multi-user install. Please follow the explicit instructions for the Multi-User install at https://rvm.io and remove any existing installations, remove /etc/rvmrc, /etc/profile.d/rvm.sh, and $HOME/.rvmrc. Comment out any RVM sourcing lines in your .bash_profile, and .bashrc and log out of the machine then back in. Then reinstall correctly. Setting the rvm_path has never been a requirement of the installer UNLESS you already have a Multi-User working installation in place, and you want to attempt to use a per-user install with it. THEN you would preset the $rvm_path to $HOME/.rvm in your own $HOME/.rvmrc, log out then back in and then attempt the install again. BUT, that is not a supported installation type. Which is why 99.999% of users will not need to set rvm_path at all.
The real problem was that the git configuration for auto-converting line endings was not set correctly which prevented any installation from working. It had nothing to do with using rvmrc settings.
The fix for this is simple (and comes straight from the github help page):
$ git config --global core.autocrlf input
Line endings are important in linux and by forgetting that setting, everything the rvm-install script was pulling from github had \r\n endings. I made that change so long ago on my work machine, I didn't even remember it -- but it was not set on my home system.
I'll leave it up in case someone else has the same problem.