I'm installing 'THERMUS: A Thermal Model Package for ROOT' on macOs Mojave. One of the steps is (after unzipping) the following: "Set an environment variable `THERMUS' to point at the top-level directory containing the THERMUS code". I really don't know what to do.
I've seen the other post on stackoverflow: 'no rule to make target' with no reason, but, as I am a beginner, I really don't understand how I should set it. Please help me
To set an environment variable on Mac OSX, first open a terminal window.
If you are setting the environment variable to run jobs from the command line, use the following command:
export variable=value
where variable is the name of the environment variable (such as programmer) and value is the value you want to assign to the variable, (such as /opt/programmer/suites2013). You can find out which environment variables have been set with the env command.
If you are setting the environment variable globally to use with applications, use the commands given below. The environment variables set by these commands are inherited by any shell or application.
OS X 10.10
# To set an environment variable, enter the following command:
launchctl setenv variable "value"
# To find out if an environment variable is set, use the following command:
launchctl getenv variable
# To clear an environment variable, use the following command:
launchctl unsetenv variable
Related
I have a cmd batch script that sets some variables. I tried the command SET, but it lists all the environment variables, including the system default ones (or Global ones). I am interested in knowing exactly the ones which are being set inside that script. Is there any way to do that from the command line?
Also, let's say I exported all the environment variables in a text file. Can I set them all at once in a new cmd.exe instance by providing the file path? Or, looping through each one of them is the only option?
Edit: I can't modify the original batch script and don't have any control over it's future changes.
I have a program that creates a environment variable called $EGG with this code
memcpy(buff,"EGG=",4);
putenv(buff);
system("/bin/bash");
And the value of buff is used to create an environment variable, and I use it through $EGG variable, but for use it I see that I must use the call system("/bin/bash");. Otherwise, if I don't use /bin/bash call I don't find my $EGG variable.
Is there a way to save my environment variable without calling /bin/bash?
Short answer: You cannot modify an existing environment the way you try.
Background: The program you use to create the environment variable EGG in gets its own environment on start-up (typically as copy of the environment of the process that starts the program). Inside the program's very own environment EGG is created.
When a program ends its environment is also gone and with it would had been created in there.
To modify an environment programmatically do not write a (C) program but use a script.
Using bash this could look like this:
#!/bin/bash
export EGG=4
save this as for example set_egg_to_4.sh and adjust the files mode do be able to execute the it:
$ chmod +x set_egg_to_4.sh
Then run the script:
$ ./set_egg_to_4.sh
and test for EGG, by doing
$ echo $EGG
4
To "permanently" set an environment variable, add it to your .bash_profile file.
export EGG=4
This file is sourced each time you start a login session, so that EGG is added to your environment each time. Any that inherit (directly or indirectly) from this shell will also have EGG in its environment.
There may be other files on your system that are sourced immediately on startup, so that a variable set in such a file is available to all processes (regardless of the user). (One I'm think of is /etc/environment.)
Yes, I have found other questions asking the same:
TERM environment variable not set on mac
TERM environment variable not set
how to remove "TERM environment variable not set"
...
However, my environment variable is set:
$ echo $TERM
xterm-256color
But LLDB does not recognize so:
$ lldb myexecutable
(lldb) target create "myexecutable"
Current executable set to 'myexecutable' (x86_64).
(lldb) platform shell clear
TERM environment variable not set.
error: command returned with status 1
I have my environment variables set up for GUI programs too:
envars.app (applescript application run on logon.)
...
set ENV_TERM to "/bin/launchctl setenv TERM xterm-256color;"
...
do shell script ... & ENV_TERM & ...
or
...
set ENV_TERM to "/bin/launchctl setenv TERM xterm-256color:-dumb;"
...
do shell script ... & ENV_TERM & ...
What you are seeing is the fact that the "platform shell" command doesn't pass lldb's environment to the shell that it spawns. In lldb, the "platform" could be a remote or a local system - depending on what platform you connected to - so using lldb's environment for "platform shell" execution is not always the right thing to do. By default lldb clears out the shell execution environment by default.
But it would be useful to have a flag to "platform shell" that tells it, to use lldb's environment. Feel free to file a bug to this effect with lldb.llvm.org's bugzilla (or wade in and add this yourself if you're feeling bold - it is an open source project...)
Note that when starting a process for debugging under lldb, you do have control over the environment passed. In Command Line lldb, the target.inherit-env setting controls whether the process will inherit lldb's environment, and target.env-vars or the env command can be used to modify the environment. If you are using Xcode, set the environment in the Run Scheme for whatever target you are debugging.
I have this batch which executes on the server computer. There is a scheduled job which runs the batch. The Batch detects a particular file and then it executes an sqlcmd like below:
if not exist %TRIG_FILE% goto No_Triggers
sqlcmd
-S %WSL_SERVER%
-d %WSL_DATABASE%
-E
-Q "DECLARE #RES integer;DECLARE #RET varchar(1);DECLARE #MSG varchar(65);EXEC Ws_Job_Release 1,'Release Job Unlock Batch','All',0,0,'Unlock_Batch',#RET OUTPUT,#MSG OUTPUT,#RES OUTPUT"
My question is - how did the batch know what the %WSL_SERVER% variable is, because when I look at the script, there is nowhere in there which sets the %WSL_SERVER% variable.
This is the first time I'm reading a .bat script, I know a fair bit of programming, but I can't see how that variable was passed into this script so that it knows which server. There's no other batch calling this, it's from the batch run by the scheduler.
thanks
gemmo
Most likely the WSL_SERVER and WSL_DATABASE are global environment variables initialised every time with your Windows session. That means they exist (are defined) in every CMD session and thus in every batch script. You can open a new Command Prompt window and issue this command
SET WSL
which will (try to) display all environment variables, whether global or local, whose names start with WSL. My guess is the output will show you at least the two WSL variables used in your script.
There is a number of global variables pre-defined and maintained by the OS. Yours, however, are probably user-defined (just my guess based on the fact that my system does not have them). User-defined variables can be created by third-party software or your own (maybe someone else's) batch scripts, as well as with a standalone invocation of the SETX command:
SETX VarName "Value"
You can use that command to change the value of any of your variables globally. Note that you can also change that value temporarily only, for the duration of the script, using the SET command as usual, if global change is undesirable:
SET "VarName=Value"
I want to initialize my Cygwin environment with a variable coming from a batch file
#set myvar=test
%BASH% --login -c "set"
REM hope to see myvar
So I want myvar with its value eventually be available in bash.
You can have the batch file append your variable to your bash.bashrc file to create bash environmental variables, like so:
export croot=/cygdrive/c
Then you access that croot variable like so
export cc=$croot/CC
or
alias cdcc='cd $croot/CC'
The path on my machine is C:\cygwin\etc\bash.bashrc ... yours may differ.
Note that the variable won't be available in running cygwin sessions, only new ones.