I have a below properties in my spring boot application.properties
qs.cloud.region=${awsRegion}
I am using ubuntu and tried below in terminal.
export awsRegion=ap-southeast-1
When I did echo $awsRegion I am able to get the value in terminal
But when start my spring boot application I am getting
Could not resolve placeholder 'awsRegion' in value "${awsRegion}"
Please help me on this.
First: Environment variables are case-sensitive. By convention, but not rule, environment variable names are always capitalized.
Second: export is a command Bash that used to set a variable. The variable will be visible only for any subprocesses started from that instance of Bash.
Third:
To make it more permanent, you can add it to your shell configuration file: $HOME/.bashrc or more globally in /etc/environment.
For example, AWS_REGION=ap-southeast-1
After adding this line, the changes won't reflect instantly in GUI-based systems. You have to exit the terminal or create a new one and on the server, log out the session and log in to reflect these changes.
Related
OSX Catalina & zsh as my terminal.
I have a command to start a psql connection :
db, err := pgx.Connect(context.Background(), os.Getenv("PSQL_URL"))
But the os.Getenv("PSQL_URL") is an empty string.
How to make sure go program can read my environment variable ?
In the terminal, if I echo $PSQL_URL I get the proper postgresql://aod:toto#localhost/dbname
If I export PSQL_URL="postgresql://aod:toto#localhost/dbname" before running main.go it works fine
I'm looking for a persistent way of doing it.
UPDATE
My mistake was as follow :
Inside ~/.zhsrc I did set
PSQL_URL="postgresql://aod:toto#localhost
instead of
export PSQL_URL="postgresql://aod:toto#localhost"
That's the correct way of reading an env variable in go.
The only thing that comes to my mind about what might be happening is that you have two different terminal sessions. In one of them you set PSQL_URL (you are running the echo in this one) and in the other not (you are running your go app here).
EDIT
Expanded now with the your comments and Felix's, the problem here is that you export a variable, but don't make it permanent, so when you start a new session the variable doesn't exist. What you need to do is edit your ~/.zshrc and add export PSQL_URL=foo, this way, whenever you start a new terminal session, the variable will be loaded.
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.
I'm using docker-maven-plugin. And it said -
"By default the plugin will try to connect to docker on localhost:2375. Set the DOCKER_HOST environment variable to connect elsewhere.
DOCKER_HOST=tcp://<host>:2375
Other docker-standard environment variables are honored too such as TLS and certificates.".
After I protect the Docker daemon socket reference to https://docs.docker.com/engine/security/https/. I think I need to set some variables like DOCKER_TLS_VERIFY="1" and also variable which is used to locate ca.pem file. So where could I find these docker-standerd environment variables?
You would find (and set) them on the same user that is running the docker-client.
EG:
nick#primestorage01:~$ set | grep DOCKER
DOCKER_HOST=terrorbyte:2376
DOCKER_TLS_VERIFY=true
You can do that many ways for an interactive login. One way is via a .bashrc file. (assuming you are using bash)
In .bashrc, you can add these lines:
#docker
export DOCKER_HOST=terrorbyte:2376
export DOCKER_TLS_VERIFY=true
If this is some sort of automation, depending on your methodology .bashrc won't be called (Specifically, if it's a non interactive shell such as via ssh host COMMAND. In this case, you'll need to set the environment variables another way.
PS, make sure you also put the certificates in the expected directory to make your life easier. The expected directory is ~/.docker
I've been having proxy issues with npm and git.
Looks like the proxy is set as an environment variable in Bash
If I check with
env | grep -i proxy
I can see the proxy settings.
I can unset the proxy with
unset http_proxy
unset https_proxy
unset ftp_proxy
This only appears to last as long as the terminal window is open.
If I close and reopen the terminal the proxy is back again.
Is is it possible to delete the proxies when I'm out of office and then recreate them when I need them?
You first need to find out where these environment variables are defined in your case.
Typically they are set in the ~/.bash_profile file (Mac OS X) or ~/.bashrc file (Linux). Since you tagged the question with osx, I assume that in your case they are set in ~/.bash_profile.
Please check whether this file defines these variables. You can either do that using Finder (you need to show hidden files), or from a terminal by running cat ~/.bash_profile. Feel free to post the output in your question.
There's a small chance that they are defined in a system-wide file like /etc/bashrc. Feel free to check that file as well.
If you need to define/undefine the variables on a regular basis, I recommend that you create a script for each defining/undefining and place it in a location like ~/bin. Then you can simply call the respective script when you open a new shell.
I handle this through the Bash-it framework. In my fork, I have added a proxy plugin that provides functions for this. Feel free to give this a try: https://github.com/nwinkler/bash-it/blob/master/plugins/available/proxy.plugin.bash
To answer your other question: There's no easy way to automatically detect and change the presence of a proxy from a shell window.
What we're doing:
We're doing an automated deployment using a tool called Nolio. One of the steps we need to do is to set a few environment variables for applications that are being deployed - for example, JAVA_HOME pointing to our preferred java install directory.
We're using the SET command to permanently set the environment variables - and in most ways, it works great. If I right click on my computer and go into environment variables, they all appear perfectly.
The problem:
Unfortunately, later in the deployment, some command line commands are executed that rely on the environment variables, and the environment variables appear to not be set. Using SET without parameters verifies this by displaying all currently available variables.
Now, if I restart the computer, the command line commands work fine. So, the issue is that while the variables are permanently set and do appear in the GUI, they are not propagated to the command prompts until I reboot.
Another interesting tidbit: If I put the commands in a BAT file and double click it, it runs fine, but if I execute it in the command prompt the variables don't resolve prior to a reboot.
Does anyone know a way around this?
First, what version of Nolio do you use?
The Environment variables to which you set value, in the context of one Nolio action, stay in the scope of this action. (It's like opening two different shells on every action)
The best practice for this case would be using the environment variables arrays inputs in the Nolio 'Run Command Line' action. You should write two arrays of parallel Env variable names and values, and give them as input to the 'Run Command Line' action.
It appears your variables are not in scope for the command prompt. At what point in your deployment process are you using the SET command? Interesting that the GUI recognizes the values, but the command prompt doesn't until you've restarted.
Also, I'm not clear as to why using a .bat file is undesired. I can come up with my own reasons, but what are yours?
EDIT
I've found this article that shows a step that you didn't mention. Have you tried:
rem Set the JAVA_HOME environment variable and insert it into the system path.
rem This will make the javac and java commands reachable from the command line.
set JAVA_HOME="C:\Program Files\Java\jdk1.5.0_14"
set PATH=%JAVA_HOME%\bin;%PATH%
I'm not entirely sure why the command prompt won't recognise commands and the batch files will, but you could use SETX as an alternative to SET to see if that resolves your issues.