I am wanting to program Minecraft mods using forge. I am going through the standard installation to begin creating mods, but I have run into an issue. I ran the code "gradlew setupDecompWorkspace eclipse" and it is telling me "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH. Please set the JAVA_Home vairable in your environment to match the location of your Java installation." Is it possible to change something else or do something else that will allow me to program? I also cant change the environment variables.
You can change environment variables, even without being an administrator.
The easiest solution is to use set to temporarily change the environment variable for only your session (IE, it'll get reset when you close your command prompt):
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_91
gradlew setupDecompWorkspace eclipse
Obviously, you'd change the location given to a different one if you have the JDK in a different location.
If you want to change it more permanently, you can use the setx command. Setx keeps the changes you made between sessions (and, more importantly, you don't need to be an administrator, since changes are only made to your account). Note that running setx doesn't apply the changes to the current command prompt window, only future ones; you'd need to close and reopen command prompt after setting the path.
Run
setx JAVA_HOME "C:\Program Files\Java\jdk1.8.0_91"
and then close and reopen your command prompt, and it should keep the path set. (Note that again, you'd want to use the path for your java installation; also it needs to be surrounded by quotes here).
If you don't want to run set each time, you can probably edit gradlew.bat and put the same set command at the top of it.
Simply open gradlew.bat with a text editor and then put
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_91
at the top of it (again, replace the path with the correct one for your version).
Related
i am trying to run my MSTest from the command line, and I cannot for the life of me figure out why this isn't working. Yes it works if I manually change the directory to the executable, but I don't want to do that every time.
In the image below, you can see I have set up the environment variable, and yes I have restarted my computer many times.
You need to add it to your PATH variable. In that same dialog edit the Path variable and add the folder to the path. For example, I have enterprise installed, so I used this path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow
After updating the path you will need to close and restart the cmd window.
I need to use an envirnoment variable in all of my idea run configurations. I currently use run->edit configurations->and then enter the env variables in selected configuration. However that's very tedious when I need to run isolated test scenarios because each one creates a new run configuration and I need to enter the variables all over again.
I tried to set the env variables in my linux system using export SOME_VAR="some value" in various session profile files: /etc/profile,/etc/bash.bashrc,~/.bashrc,~/.profile but intellij seems to ignore those vars during run, even though when I launch echo ${SOME_VAR} from intellij built-in terminal it displays the correct output.
I also tried using intellij .env file plugin and then set SOME_VAR=some value in .env file in project root. Didn't work either.
I found a solution to set environment variables on IntelliJ that has been working very well for me, and is incredibly simple. Let me show you.
This is the program (you can copy and paste it) we're using to test:
package com.javasd.intelijenv;
import java.util.Map;
public class Main {
public static void main(String[] args) {
Map<String, String> env = System.getenv();
for (String envName : env.keySet()) {
System.out.format("%s=%s%n", envName, env.get(envName));
}
System.out.println("My home directory: " + System.getenv("MY_VAR"));
}
}
This program basically loads all environment variables, show them on the console, and try to show an env variable. Also, it assumes that you had created the MY_VAR env variable before calling IntelliJ IDEA, by doing something like:
$ export MY_VAR="This is my adorable var :)"
$ idea
Please, notice that we're calling IntelliJ IDEA in the same terminal (or session, or window) where we created the environment variable. If you create the variable and call the IDEA from the icon, the solution won't work because the IDEA will create its own session.
So, if run it without the correct configuration you will get something line this in your console:
Please, notice that you have just a few variables, and that MY_VAR is null.
Here's configuration I use to load the environment variables:
Click on the "Select Run/Debug Configurations" in your project and select "Edit Configurations":
Then, click on the the button with "..." on the right side of the "Environment Variables" section:
You'll see a pop-up. Check the checkbox on the bottom-left which has the label "Include parent environment variables":
That's it!!!
If you run your program now you will see something like this on your console:
You can see all the environment variables and, of course, your "MY_VAR" variable, with the right value!
Beyond the Basics
Usually, for security reasons, we don't want to keep all the environment variables visible. What we want to do is to make those variables visible only while the IntelliJ (or our program) is running.
So, no sensitive variables should be visible on the environment neither before you call Intellij nor after you close it.
Also, you want to keep those variables in a file (typically with a .env extension) to make it easy to manipulate and for security reasons.
To achieve this, there are some useful programs (you can Google them), but my favorite one is the env-cmd.
Let's say you have a test.env file with the following content:
MY_TEST_VAR=I live in the test.env file.
If you call IntelliJ by doing this:
$ env-cmd test.env idea
And edit your program to show "MY_TEST_VAR", and run it, you will see this on the IntelliJ's console:
But if you quit the IntelliJ, and look for your variable, you will see that the var doesn't exist (you can use env to confirm):
At this point, I hope you're able to play with your own solutions: create shell scripts with variables set inside, test other programs (direnv, autoenv, etc.), and so on.
Enjoy!
...
In my opinion the real issue is what Mat said.
If you want to launch IntelliJ from a shortcut, then you have to edit it a little bit:
Open the .desktop file, and add /bin/bash -c -i to the beginning of the launch command. The file should look something like this:
[Desktop Entry]
Exec=/bin/bash -i -c "/path/to/idea/bin/idea.sh" %f
Name=IntelliJ IDEA Ultimate
Type=Application
Version=1.0
If Maven is used project specific environment variables can be configured under File->Settings->Build, Execution, Deployment->Build Tools->Maven->Runner
These are reused then in any Maven configuration.
The same mechanism to set the environment variables might also work with different runners.
The problem is, that IntelliJ does not "see" the environment variables that are set in .bashrc (Also to be found in CrazyCoders answer). The easiest way to enable IntelliJ to import those variables is to start it from bash e.g. by typing intellij-idea-community.
I tried various things listed above, and adding the environment variables to the terminal configuration and the Maven build tools worked in some contexts but not others. Then I finally found the place in IntelliJ that actually works for runtime processes. Because why just have one environment variable configuration screen when you can have several and make all but one of them wrong? ^_^
If you edit the template from which your run configurations are created, and add the environment variables to the template, then they should be included in every subsequent run configuration that started with that template.
This is especially useful for the JUnit template, since it will mean that all your custom environment variables will be loaded for unit tests, regardless of the scope from which they're executed (single method, whole test class, whole module). But in general, if you edit the templates first, then any run configuration you create thereafter will inherit your environment variables from the template.
From the top menu: Run → Edit Configurations... → expand Templates tree → (choose a template) → Environment variables: → (enter a semicolon-delimited key-value pair list OR use the input widget)
For the auto-generated JUnit configurations, you should blow away any existing ones, and let IntelliJ recreate new ones as you go; each of these will use the updated JUnit template with your environment variables.
For macOs try adding /Applications/IntelliJ IDEA.app/Contents/bin/idea.properties
...
apple.awt.graphics.UseQuartz=true
apple.awt.fullscreencapturealldisplays=false
idea.jre.check=true
SOME_VAR=some value
As no other answer mentioned it here,
Add your environment variable to /etc/environment , then log out and log in again. IntelliJ will definitely pick it up.
I found another tricky solution :)
At least for Linux users...
Just create some shell script like idea.sh in any suitable location with this content.
#!/bin/bash
export YOUR_ENV_VARIABLE=some value
cd ~/path_to_your_idea_folder/bin
bash ./idea.sh
Make this script executable and run it.
This script will always run your IDE with predefined env variables.
Got to Open 'Edit Run/Debug configurations' dialogs
Go to Modify options
Select Environment variables
New box appears for Environment variables below Active profiles
About a week ago I installed golang successfully on my computer and got it's terminal commands to process. So by that, I know go is on my computer.
I have been looking for a good IDE and found https://code.google.com/p/liteide/ LiteIDE which was made specifically for Go.
I read that if you already had go installed on your computer then you could use LiteIDE to start building your code right away. I must have read something wrong some where because I cannot get my projects to build at all. I think it there may be a missing/incorrect path and or something is just setup incorrectly.
This is the error I get in the console:
Current environment change id "win64-user"
C:/go/bin/go.exe env [c:\go]
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=
set GORACE=
set GOROOT=c:\go
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set TERM=dumb
set CC=gcc
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CXX=g++
set CGO_ENABLED=1
Command exited with code 0.
First_Lite_Go_Proj [C:/go/src/First Litel Go Proj]
Error: process failed to start.
I checked the C:/go directory to make everything there is correct and it was. Also I'm using 64bit windows 7 and double checked that as well.
Any ideas? Mine are: Missing/Incorrect Paths, Can't access a certain directory due to restrictions.
While I have not tested this in Windows 7, on Windows 10, these were the steps that I took to make LiteIDE work
Installed Go to C:\Go
Added C:\Go\bin to PATH and made sure go was working from Command Line
This was the most important step for me. Defined GOPATH in an environment variable. In my case, it was C:\Users\vivek\Documents\Source\Go. I also made sure that there were three folders src, pkg and bin were created in GOPATH. At this point go env was showing me correct values for GOPATH and GOROOT. go get, go build and go install was working as well at this step.
Downloaded and unzipped LiteIDE to C:\liteide. Started LiteIDE and it worked out of the box for me. Make sure that GOPATH is seen correctly by LiteIDE by going to View > Manage GOPATH
Hope this helps. Good luck.
It's not a good idea to keep your projects in the GOROOT path, which per default (when installed using the MSI installer) is C:\Go. Always keep it separated from there. It also helps to avoid issues with updates.
Since Go projects are made up of packages which are organized in directory structures it is important to follow a few rules and keep the working space for your Go projects separated and clean.
In my opinion its best practice to create ONE working directory as the root for ALL your Go projects somewhere in your user space and stick to it.
One way to do this is to create a directory like "work" and set the environment variable GOPATH to it (e.g. C:\Users\Peter\Documents\work). Make sure to relog or restart your computer after your changes.
Upon certain operations Go will automatically create the directories bin, pkg and src below your GOPATH.
src contains your created or downloaded Go source files,
pkg contains your installed package objects, and
bin contains your installed executable files.
bin or pkg will automatically be created when you use the go install command to install a binary executable or a package. It's important to understand that these are files that are not part of the Go installation.
src, if it does not yet exist, will automatically be created the first time you issue a go get command or in case of LiteIDE, the first time you create a new Go1 Command Project or Go1 Package Project. Watch the "Location:" field on the dialog box, it should include your path defined in GOPATH followed by \src (e.g. C:\Users\Peter\Documents\work\src).
In the name field enter the path you want to use for your project. If you plan to track the development of your project on Github (or other repo) it's common practice to include the path to the Git repo in your source path (e.g. github.com/petergloor/hello-go).
Of course you can use any other structure to organize your projects as long you make sure they fall below the src directory in your GOPATH.
For more information about Go workspaces read https://golang.org/doc/code.html#Workspaces.
A final note about the GOROOT environment variable. Dont explicitly set this if you install Go in C:\Go. It's enough to include C:\Go\bin in your path and to set GOPATH. GOROOT is only needed in case Go is installed at another location.
I also had this problem first, but after completing the installation process, I succeeded.
Step 1:
Run (Ctrl+R) -> run target, request build first.
BuildAndRun(Ctrl+F7) -> build and run target
FileRun(Alt+F6) -> go run
step 2:
Check Config via this URL:
https://www.goinggo.net/2013/06/installing-go-gocode-gdb-and-liteide.html
Try setting up the GOROOT to the directory where go was installed. It worked for me.
Do you have 'Install' keyword in your project name? Try remove it.
You have to setup LiteIDE variables correctly (if there are not by default).
Please, check two options:
Go to Settings → "Manage GOPATH"
Options → LiteEnv (there are
environment definitions files). Just double click on someone and
setup Go environment variables.
I'm not sure how this works, but it worked in my case. I got this idea from this video on Youtube-Chris Hawkes
Open LiteIDE.
Click File---New.
Select "Go1 Command Project".
Browse the desired path.
Select the desired folder.
Name the folder and click Ok.
Now, you will be able to see a "main.go" file opened in the IDE.
Write whatever code you want to run in this file with correct syntax, it will run.
The only problem with this is, whenever I create another ".go" source code file in the same folder, the same error is shown. So, you might have to edit this file every time, you try to write new code.
I am trying to add a path, in PATH variable. I run cmd.exe as administrator and used
setx PATH "%PATH%;C:\MinGW\bin"
setx PATH "%PATH%;C:\MinGW\msys\1.0\bin"
I then restarted my computer, but if I type path I don't see the paths that I set there. Note that with the exact same way I was able to set some other directories on PATH.
Any idea on what might be wrong?
you should use
"My Computer" > "Properties" > "Advanced" > "Environment Variables" > "Path".
setx PATH "%PATH%;C:\MinGW\bin"
setx PATH "%PATH%;C:\MinGW\msys\1.0\bin"
Should first set PATH to "%PATH%;C:\MinGW\bin" and then to "%PATH%;C:\MinGW\msys\1.0\bin", so the second setx overrides the first because setx does not set the variable in the current or existing CMD sessions - only new ones.
setx PATH "%PATH%;C:\MinGW\bin;C:\MinGW\msys\1.0\bin"
theoretically should set PATH with those two directories appended - for future sessions.
You can check by simply starting a new session and executing a
path
command.
If the change doesn't survive a reboot, then some other process is resetting it.
If the change doesn't occur at all, then there's something mighty fishy going on. Possibly a typo...
I'd try setting some other variable as a test, say mypath.
You can delete a variable using
setx mypath ""
Googling for PATH EDITOR may be useful...
I am working with bash and still unfamiliar with the difference between .profile, .bashrc, .bash_profile.
My desired result is to have the ruby version and rvm gemset show up on my bash prompt.
I added PS1="\$(~/.rvm/bin/rvm-prompt) $PS1" to .bash_profile (via xcode) and it displays
ruby-1.9.3-p286 John-MacBook-Air:~ john$
What I trying to get is
ruby-1.9.3-p286#rails3 $
With "rails3" being the output of rvm gemset.
How do I get John-MacBook-Air:~ john removed from the prompt?
I tried adding the line in the .profile, and .bashrc with no luck but it seems to work in the .bash_profile. Any clarification between these files would be greatly appreciated. I am running rvm on a Mac.
SOLUTION
include the following to the .bash_profile
PS1='\W \$ '
PS1="\$(~/.rvm/bin/rvm-prompt) $PS1"
the prompt looks like
ruby-1.9.3-p286#rails3 ~ $
This line is the problem:
PS1="\$(~/.rvm/bin/rvm-prompt) $PS1"
What you're saying there is "add my rvm prompt to PS1" and then put the pre-existing PS1 at the end. The system's default PS1 is setting this:
PS1='\h:\W \u\$ '
In that setting \h is the hostname (here 'John-MacBook-Air'), \W is the current working directory with your home directory abbreviated to ~, \u is your user's login name (here 'john') and \$ will show a dollar sign if you are a regular user and an octothorpe (#) if you're logged in as root. On OSX, that is set by default in /etc/bashrc. If you want to change the prompt, you need to customize the latter part of the prompt rather than just re-entering $PS1 as is back into the new setting. Removing the hostname is common, but I would very strongly recommend against removing the current working directory. It's very useful information when in a terminal session. Just my two cents.
To see what you can put there, take a look for information about setting your prompt in Bash.
I am working with bash and still unfamiliar with the difference between .profile, .bashrc, .bash_profile.
That depends on your system configuration. Read the manpage for that. You can also change the behaviour either system- or userwide by including one from the other.
Here are few notes to understand better.
Per-login initialization. (or: session startup) There are startup files which are only executed for login shells. On my system, they only set environment variables. (That makes sense, because environment variables are inherited).
Those may be called /etc/profile or ~/.profile for plain sh. If bash is your shell and you have ~/.bash_profile or ~/.bash_login, it will prefer those (in this order) instead by default.
Note that changes to session startup files have no effect until you login next time. Also, you need to make sure to export variables to the environment like PS1=something ; export PS1.
Per-process initialization. For Plain sh, there is no default per-process initialization file, but you can set the ENV environment variable to point to one. For bash, there is also the BASH_ENV variable, and the ~/.bashrc file. The per-process initialization file is the place where you can store per-process shell settings (those who can't be inherited through the environment), e.g. aliases or function definitions.
If you just want to see if a particular file is executed, you can always echo something, or touch some file like echo TEST or touch /tmp/test.