When opening a new terminal in vscode, if I have
"python.terminal.activateEnvironment": true
and I already selected a Python interpreter (see related question here and documentation here), then the terminal opens and automatically activates the environment using
source /path/to/the/environment/bin/activate /path/to/the/environment
I can turn this behavior off by setting python.terminal.activateEnvironment to false.
Of course, I can also manually activate the environment using
conda activate /path/to/the/environment
How to get vscode to use conda activate automatically instead of source activate?
Using source as vscode does sets the activated environment as the "base", e.g. if I do conda env list I will see something like:
conda env list
# conda environments:
#
/path/to/the/actual/base/environment
base * /path/to/the/environment
and this causes some issues. For example, if I try to use mamba which I have in my "true" base environment but not in the other one, it will cause a "No such file or directory" error.
I'm currently using a vscode over a remote ssh connection and cannot figure out how to set the search PATH for the vscode process itself. I have set the PATH for processes run in the terminal in my .bashrc file, which is also sourced from .bash_profile.
In spite of this, vscode complains that pipenv is not on the path although it is visible to my integrated terminal session. In my .bashrc I am loading environment modules to load versions of needed libraries, which get put on the PATH. Since I created my virtualenv using pipenv in the terminal, it knows which python version to use and makes a link to it in the environment definition. Because of the way python virtual environments work, the actual python binary is copied to the virtual environment. And because vscode has hardcoded paths where to look for virtual environments it is able to find the correct version of python that is in use (despite it not seeing it in the PATH).
In addition, hardcoding the path to pipenv using the extension setting python.pipenvPath still produces a "not found" error.
Solutions that I have seen elsewhere suggest launching vscode from the command line so that the process inherits the PATH settings. However, this will not work over a remote connection.
I have installed swig on my mac and it works in the console just fine. If I type swig -verison in terminal it spits out the version. Eclipse keeps telling me that it can't find swig. I am using the liquidfun library http://google.github.io/liquidfun/SWIG/html/index.html and it told me to put this export SWIG_BIN=$("which" swig) in .bashrc, which I did. This enviroment variable registers through terminal as well. Eclipse STILL won't grab swig properly. What the hell?
Bash reads .bash_profile, .bash_login or .profile. I don't expect the Eclipse process to load such a file (although I could be wrong) nor the SWIG_BIN variable to augment its search path for executables, but if you launch Eclipse from the shell, it should inherit the shell's environment variables.
Try running swig from eclipse using a full absolute path (the one that "which" returns).
The eclipse.ini file can set some startup parameters but perhaps not the path. There might be other eclipse startup files.
Another possibility is to add swig's directory to the path in a login script. (To test that, log out and back in, then start eclipse.)
My company provides an eclipse based development environment which needs some environment variables setting up for the underlying toolchain so multiple versions can be installed concurrently and not take over the system.
I want to provide an icon in finder or the dock which sets these then launches eclipse so customers cannot accidentally launch eclipse without the environment being set. This is what I have tried so far:
Setting environment in Info.plist
for eclipse:
This should be a nice way to do it
but I cannot make it add to the
existing path (like export
PATH=/myapp/bin:$PATH).
bash script wrapping eclipse:
I created a bash script called
eclipse.command to set the
environment then launch eclipse.
This opens a terminal window as well
as the eclipse icon and allows
people to "Keep on dock" for the
bare eclipse. I cannot put
eclipse.command on the dock as it is
not an application.
Applescript wrapping eclipse.command:
An Applescript wrapper around
eclipse.command makes it look like
an app and prevents the terminal
window appearing. Unfortunately I
now get a dock icon for the
applescript and one for eclipse so
can still keep the bare eclipse on
the dock.
Any suggestions? Am I going about this in completely the wrong way?
There is an alternate solution which involves replacing the executable that is run by MacOS X when the user launches the Eclipse application with a shell wrapper that sets up the environment.
Create an empty text file called "eclipse.sh" in the Eclipse application bundle directory /Applications/eclipse/Eclipse.app/Contents/MacOS.
Open the eclipse.sh in a text editor an enter the following contents:
#!/bin/sh
export ENV_VAR1=value
export ENV_VAR2=value
logger "`dirname \"$0\"`/eclipse"
exec "`dirname \"$0\"`/eclipse" $#
In the example ENV_VAR1 and ENV_VAR2 are the environment variables being set up. These variables will be visible to processes launched from within Eclipse. The logger command will just log the path of the eclipse executable to the system.log as a debugging aid.
In the Terminal set the executable flag of the shell script eclipse.sh, i.e.:
chmod +x /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.sh
Open the Eclipse.app Info.plist and change the value for the key CFBundleExecutable from eclipse to eclipse.sh.
MacOS X does not automatically detect that the Eclipse.app's Info.plist has changed. Therefore you need to force update the LaunchService database in the Terminal by using the lsregister command:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -v -f /Applications/eclipse/Eclipse.app
The next time you launch Eclipse.app from the Dock or from the Finder the environment variables should be set.
I created the following:
alias start-eclipse='open /Applications/eclipse/Eclipse.app'
If you run start-eclipse from the command line, all env vars will be picked up. This way, you only need to maintain a single set of env vars across both command-line and eclipse environments.
Take a look at a related question: Environment variables in Mac OS X.
Basically, this involves the creation of a ~/.MacOSX/environment.plist file.
Log out and Log in for the environment.plist to get picked up by .App's
This worked perfectly in OS X Yosemite:
Open /Applications/Automator.
When the drop-down appears asking you what kind of document you want to create, choose "Application."
In the second-from-the-left list, double-click "Run Shell Script."
In the right side delete the "cat" that gets put there automatically, and replace it with this:
source ~/.bash_profile && /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse
Now go to File->Save, and save the application to your Applications directory. I named it "Eclipse" with a capital 'E' so as not to conflict with the "eclipse" directory I already had. For good measure, you can even give it the Eclipse icon by selecting the real eclipse app, pressing command-i, selecting the icon, pressing command-c, then selecting the automator "Eclipse" app, pressing command-i, selecting the icon, and pressing command-v.
Now you can open the app, or even drag it to your dock. Note that if you start it, the "real" eclipse will still show up in your dock as a separate icon, but you can't have everything. :)
sakra's answer above is awesome, except is doesn't automatically inherit your existing bash environment. To ensure eclipse.sh picks up your existing bash environment, modify eclipse.sh to use bash instead of sh and add a line to source your existing ~/.bash_profile thus:
#!/bin/bash
source ~/.bash_profile
logger "`dirname \"$0\"`/eclipse"
exec "`dirname \"$0\"`/eclipse" $#
None of the above worked for me. you have to set Eclipse -> Preferences -> Terminal -> Arguments set to --login
That will instruct Eclipse to login with your account just after opening Terminal.
See screenshot:
Reference: https://marketplace.eclipse.org/comment/4259#comment-4259
Link to Eclipse doesn't use the path set in .bashrc
Create simple script
#!/bin/bash
source /home/user/.environment_variables
/home/user/eclipse_cpp/eclipse -Duser.name="My Name"
2.
Next put your all system variables in file /home/user/.environment_variables (any file you want)
My looks like:
export COCOS_ROOT=/home/user/Projects/edukoala
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/
3.
Now you can delete your variables in .bashrc and put line
source /home/user/.environment_variables
Everything works fine :)
As pointed out in https://github.com/atom/atom/issues/7045, the environment variables can be loaded automatically, without explicit source ~/.bash_profile by using
#!/usr/bin/env bash -l
instead of
#!/bin/bash
source ~/.bash_profile
after that, in both cases, follows
exec "`dirname \"$0\"`/eclipse" $#
It works great for me, thanks for all previous work.
After setting env variables in .bash_profile.
Simply open the application through terminal!
open /Application/{path/to/app}.app
I'm having a very weird issue with the command line and running Ant. I point the path variable at the location of my Ant bin directory (C:\Ant\bin) and when i go into a command window and type PATH it shows the location in it. But when I go to run Ant by typing "ant" it does nothing and states that it isn't recognized. But when I go to the run window (Windows+R) and type "ant" it runs it.
I have restarted Windows twice and the problem still persists. I am running Windows Vista Ultimate with SP1 installed. I have tried "Running as Administrator" with no difference.
Any one experience anything like this before?
Sometimes you can set a system-wide (or even just personal) Environment Variable and it'll cure it, as opposed to just setting it in your shell.
Go to the Control-panel, then System, then Advanced, and look for the button on Environment Variables. From there, you can follow your nose.
Good luck.
Ant also depends on Java to be on the path. Do you have that?
I would also check to make sure the environment variables ANT_HOME and JAVA_HOME are set up properly in the console.
Is there any chance that the command window you are trying to run Ant in is a different window to the cmd windwo where you set up and verify that its in the path? If the PATH is updated after a cmd window is already open it won't recongnise the change. Not clear if that might be your issue.
If you are in the dir C:\Ant\bin and type "ant" does it recognise it?