I have a ~/.config/fish/config.fish which contains the following lines:
set PATH $PATH (go env GOPATH)/bin
set -x GOPATH (go env GOPATH)
If I simply run go env GOPATH at the command line, I get the default location (~/go):
> go env GOPATH
/Users/kurt/go
However, the $GOPATH environment variable is not defined:
> echo $GOPATH
Why is the $GOPATH environment variable not getting set?
set -x will only affect your current session. Once you logout of that session, the export will go away.
set --export --global will export your environment across all running fish sessions, however is ephemeral and will not persist after you log out.
set --export --universal will export your environment across all running fish sessions, and is persistent.
-g or --global
Causes the specified shell variable to be given a global scope.
Global variables don't disappear and are available to all functions
running in the same shell. They can even be modified.
-U or --universal
Causes the specified shell variable to be given a universal scope.
If this option is supplied, the variable will be shared between all the current
user's fish instances on the current computer, and will be preserved across
restarts of the shell
If you are running a current version of fish, you can use the built in fish_add_path (go env GOPATH)/bin once and it's done, you don't have to have it in a conf file.
To add Go paths to your Fish shell, add the following lines to your config.fish:
set -x GOPATH $HOME/go
set -x PATH $PATH $GOPATH/bin
Related
I have a conda environment that I created with a path (conda create -p /full/path/to/env). When I activate the environment it displays the full path to the environment in parentheses at the beginning of the command prompt line. like
(full/path/to/env) [username#server]
I want to change it so it just shows env instead of full/path/to/env. How do I do that?
I tried adding the directory leading up to my conda environment (i.e. full/path/to) to my env_dirs configuration using conda config but that didn't work.
I want to set $GOPATH for each vscode project/workspace. Right now, in .vscode/settings.json, I have:
{
"go.gopath": "$HOME/codes/huru"
}
I close vscode and reopened, and at the command line terminal, I echo $GOPATH, and it's empty. I was hoping that vscode would read the env variable from "go.gopath", but it seems not have to done so.
Does anyone know how to do this?
The go.gopath on user settings or workspace settings will replace the GOPATH value on the VSCode. This particular GOPATH value is the one that shows up whenever Go: Current GOPATH command is executed on VSCode, so it is not the $GOPATH environment variable.
The go.gopath value will not replace the $GOPATH environment variable.
Explanation from GOPATH in the VS Code Go extension:
Out of the box, the extension uses the value of the environment variable GOPATH. From Go 1.8 onwards, if no such environment variable is set, then the default GOPATH as deciphered from the command go env is used.
Setting go.gopath in User settings overrides the GOPATH that was derived from the above logic. Setting go.gopath in Workspace settings overrides the one from User settings. You can set multiple folders as GOPATH in this setting. Note that they should be ; separated in Windows and : separated otherwise.
Below is an example I've made up that might be useful on trying to understand the differences.
For example, I already set the $GOPATH env on my local with a certain value. Then I set the go.gopath on the user settings (with different value compared to the $GOPATH). When I execute the command Go: Current GOPATH, a popup on the bottom right appears, showing the very same value as on my go.gopath settings. I put red line on all of this.
But, whenever I execute shell command echo $GOPATH on the terminal, the output is still the $GOPATH value from my env variable (blue line). This is because go.gopath setting will not replace the $GOPATH env variable.
In your case, the echo $GOPATH return empty output because you haven't set the $GOPATH environment variable.
I'm using the oh-my-zsh dotenv plugin, which loads .env file, if it exists, whenever I cd into a project directory.
I know it works because I can see my custom environment vars set when I run the set cmd.
I can can also echo my custom environment variable from command line:
$ echo $FOO
'foo'
However, I cannot access this environment variable via the env command or Ruby:
$ irb
2.4.1 :001 > ENV['FOO']
nil
How can I make sure environment variables loaded from my .env are accessible from Ruby?
Contrary to what is stated in the documentation of dotenv, you actually need to use the export keyword within the .env file in order to make the parameters available to the environment, e.g.
export FOO=foo
The only exception would be, if the parameter was already an environment variable. For example if it had been exported in ~/.zshrc or if it was already part of the environment zsh got when it started (e.g. PATH or HOME).
All dotenv does is automatically sourcing any .env file when changing into a directory. There is no additional "magic". That means .env needs to be a valid zsh script and its content is run in the context of the current shell session (essentially as if you typed it manually).
It also means that the usual rules apply. That is, just settings parameters makes them available to the current shell context only. In order to make them available as environment variables they need to be exported (either before, during or after being set). So unless a parameter has already been exported before, export is not really "optional" in .env.
When I set my GOPATH use:
set -gx GOPATH /usr/local/Cellar/go/1.8.1
I get this issue:
-bash: set: -g: invalid option
set: usage: set [--abefhkmnptuvxBCHP] [-o option] [arg ...]
The bash command set doesn't support the g option. Also this command is not used for setting environment variables all together - your snippet is probably intended for a different shell (fishshell?).
In bash, use export as suggested:
export GOPATH /usr/local/Cellar/go/1.8.1
However, you should understand what you are doing and how to configure your environment on MacOS (guessing from 'Cellar' in your path).
This might be a good starting point.
You should set GOROOT environment variable instead of GOPATH.
GOROOT should reference a folder (where go is installed), not the go executable itself
export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin
GOPATH should reference a folder under which you will find src, pkg and bin. (it should not reference directly the src folder):
See "How to Write Go Code - Workspace"
Regarding the GOPATH:
try and set it in your ~/.bashrc (using export).
check that your current shell is a bash (and not another one like fish)
check the output of go env.
Does anyone know how to automatically set environment variables when activating an env in conda?
I have tried editing */bin/activate, but that adds the new environment variables for every new env that is created. I want to set env variables that are specific to each env.
Use the files $CONDA_PREFIX/etc/conda/activate.d and $CONDA_PREFIX/etc/conda/deactivate.d, where $CONDA_PREFIX is the path to the environment.
See the section on managing environments in the official documentation for reference.
Environment Variables as Configuration Settings
Conda v4.8 introduced a new command-line interface in the conda-env tool for managing environment variables on a per-environment basis. The command is conda env config vars and here is the help description as of v4.8.3 for the command overall:
$ conda env config vars -h
usage: conda-env config vars [-h] {list,set,unset} ...
Interact with environment variables associated with Conda environments
Options:
positional arguments:
{list,set,unset}
list List environment variables for a conda environment
set Set environment variables for a conda environment
unset Unset environment variables for a conda environment
optional arguments:
-h, --help Show this help message and exit.
examples:
conda env config vars list -n my_env
conda env config vars set MY_VAR=something OTHER_THING=ohhhhya
conda env config vars unset MY_VAR
Perhaps a bit verbose, but it avoids having to manually manage files in etc/conda/(de|)activate.d.
YAML Specification
Added in Conda v4.9, there is now support for automatic defining of environment-specific variables as part of an environment YAML definition. For example,
name: foo
channels:
- defaults
dependencies:
- python
variables:
MY_VAR: something
OTHER_VAR: ohhhhya
which would set up the environment variables MY_VAR and OTHER_VAR to be set and unset on environment activation and deactivation, respectively.
The accepted answer (conda/activate.d and conda/deactivate.d) works well enough, but it is inconvenient if you want the environment variables to be version controlled without putting the entire environment into version control too. Generally you'd want to store only the environment.yml file in version control.
(I understand that this does not apply to all projects - sometimes the entire reason for using environment variables is to prevent that particular configuration getting stored in version control.)
My preference (on Windows, but the same principle would apply on Linux) is to create a (version-controlled) activate.cmd file in the root of the project directory that sets the environemnt variable(s) and then calls conda's own activate.bat script.
Example (a per-project pylint configuration):
set PYLINTRC=%cd%\pylintrc
#activate.bat %cd%\env
Note that on Windows at least you have to set the environment variables before calling activate.bat because the call to activate.bat never returns to the calling batch file. You also have to name your own script something other than activate.bat to avoid recursion, which is why I chose the cmd extension (which is treated by Windows as a batch file in this context).
So for virtualenv on Ubuntu I did the below where my virtual environement names is my_env and my environmental variables I want to persist were VAR_A and VAR_B:
virtualenv my_env
vim my_env/bin/activate
This opens the file and you can append your env variables to the end of the file like the below:
# This is me env variables to persist
export VAR_A=/home/developer/my_workspace/var_a
export VAR_B=/home/developer/my_workspace/var_b
Then exit the file.
Activate your virtualenv with
source my_env/bin/activate
Then your env variables should be good. Can verify like the below:
printenv | grep VAR_
VAR_B=/home/developer/my_workspace/var_b
VAR_A=/home/developer/my_workspace/var_a