I am new to cygwin & I want to print the list of include paths cygwin will search for header files.
Is there a cygwin bash shell command to print the include path list?
if so, what it is ?
if there is n't any, how can I know the include path list cygwin will search for?
echo $PATH (echo ${PATH}) would be one possibility. To show all environment variables type env.
Normally, include paths are defined by the Make-Environment, either in the makefile, along with the compiler call or within the cmake environment. This is better than to put it in the PATH environment because if someone compiles something different, the "old" include definition in the PATH environment variable maybe in the way (which is not, if you specify it for every project, e.g. in the Makefile or threw the cmake environment).
If someone still wants to define it in the PATH variable, it can be done on the command prompt (if your cygwin(64) resides on "cygdrive/c":
export PATH=/cygdrive/c/cygwin64/usr/include:$PATH
Related
This question is specific to using cmake as part of Android Studio build process.
I'm using Android Studio 2.2 preview 7 on linux (ubuntu)
Inside the CMakeLists.txt I am able to access the Android NDK path using: ${ANDROID_NDK}
But how can I access:
Any environment variable ?
If not possible, at least the Android SDK path ?
I already tried to used $ENV{name_of_the_environment_variable_here} but it's always empty, even if the environment variable exist. I guess that when gradle invoke cmake it "hide" the env var somehow.
I don't think you can use $ENV, it's just an example of a variable because they're environment variables. However, you should be able to type env and hit enter for a list of the variables you currently have set. Then, the ones you see in the list, you can invoke by typing $VARIABLE_NAME, using a command before them to get them to do something. E.g. echo $VARIABLE will echo your variable to stdout.
I'm not sure how $ANDROID_SDK was set, if it was part of an install process, etc. but generally you would set user environment variables in .profile, .bash_profile or .bashrc configuration files. These files are read by the shell in that order. System-wide variables are set in /etc/environment, /etc/profile, and /etc/bash.bashrc, but you probably don't want to mess with those (most distros encourage making ancillary additions in /etc/profile.local, but that's a story for another answer).
It doesn't particularly matter which one of these files you use, unless what you're trying to do interacts with the order in which they are loaded. Generally, I look for where the variables have been set by either the OS or other stuff I've added and put them near those. You can find where environment variables are set by typing:
% for i in .profile .bash_profile .bashrc; do grep -H PATH $HOME/$i; done
(% is the prompt, don't type %)
.. and this will loop through the 3 files and show you if a user $PATH is set in any of them.
Bash uses the export ENV command as opposed to set ENV, which is from the original sh, which AFAIK is only default on FreeBSD and derivatives like pfSense anymore. Almost all other OS use Bash by default, except MacOS which recently moved to zsh and also uses export, and OpenBSD which uses ksh (nobody uses OpenBSD).
If you want to verify which shell you are using, type echo $SHELL, or echo $0 and hit enter, and it should let you know.
You can add the environment variable ephemerally by typing this command in your bash terminal and pressing enter:
% export ANDROID_SDK_ROOT=/home/username/AndroidSDK
To be clear, this is an example path, so it'd be best to use the actual path in which your android SDK files reside. However, this example was a default install location Android Studio tried to use when I installed it recently, so if you're not sure where they are, it's probably a good place to check.
To have a more permanent setting of your environment variable, open a text editor and add the line above to one of the configuration files I mentioned in the first paragraph (they'll be in your $HOME folder). Or, you can run this from the prompt and it'll add it to your file automatically:
% echo 'export ANDROID_SDK_ROOT=/home/username/AndroidSDK' >> $HOME/.bashrc
Take care to use two angle brackets and not one, as one angle bracket will overwrite the entire file with the single line.
How can I access Any environment variable ?
If you're not sure which folder is $HOME, try typing cd $HOME and hitting enter - that'll take you there. That's how you access environment variables - use a command with the invocation of the variable and it should act as if you had typed out the entire thing.
To access environment variables, type echo $NAME_OF_VARIABLE and it should echo it to the screen. If you want to search your three config files I mentioned in the beginning for where an environment variable is set, you can use grep as I did earlier, just changing the search string for whatever you're looking for. E.g. (while in $HOME):
% grep SDK_ROOT .bashrc .profile .bash_profile
Or you can type env to list all the currently set variables and filter them by piping the output to the grep command:
% env | grep SDK
If you want to just list all of the set variables and root around the entire thing, just type env instead of piping it to grep (grep's a filter).
Lastly, I'll give you an example of my $ANDROID_SDK_ROOT $ANDROID_SDK and $SDK_ROOT variables in my .bashrc - I noticed while installing these tools, they use all three (isn't that fun?):
% grep ANDROID .bashrc
export ANDROID_SDK=$HOME/development/Android/SDK
export ANDROID_SDK_ROOT=$HOME/development/Android/SDK
export PATH=$PATH:$ANDROID_SDK:$JAVA_HOME:$ANDROID_SDK/cmdline-tools/latest/bin:$ANDROID_SDK/build-tools/32.0.0:$ANDROID_SDK/emulator:$ANDROID_SDK/emulator/bin64:$ANDROID_SDK/tools:$ANDROID_SDK/tools/bin:$ANDROID_SDK/extras:$ANDROID_SDK/platform-tools:$HOME/development/AndroidStudio/bin
export ANDROID_STUDIO=$HOME/development/AndroidStudio
% grep SDK_ROOT .bashrc
export SDK_ROOT=$HOME/development/Android/SDK
export ANDROID_SDK_ROOT=$HOME/development/Android/SDK
Hope that answers some questions, sorry it took so long to give you a response.
I'm on a customized Linux distribution.
I'm trying to print from a Qt project file (using message() directive) an environment variable which is correctly printed in the shell. When qmake runs from the same shell instance, in the printed message is looks like the variable is empty.
I'm using the command message($$(ENVI_VAR)) which according to the Qt website, should get the value of the variable when qmake runs (there is also the $(ENVI_VAR) syntax which is instead evaluated when the Makefile runs)
What am I missing?
Thanks
Edit:
Actually, not only qmake, but every process I run, also a script execution, can't see the environment variables. Only the shell can.
I had only defined the variables in the .bashrc file, but I was missing the export
Usually global variables values are used as custom variables inside the .pro files. I'm putting here reference to Qt doc with specific details how to do this:
"Variables can be used to store the contents of environment variables. These can be evaluated at the time that qmake is run, or included in the generated Makefile for evaluation when the project is built.
To obtain the contents of an environment value when qmakeis run, use the $$(...) operator:
DESTDIR = $$(PWD)
message(The project will be installed in $$DESTDIR)
In the above assignment, the value of the PWD environment variable is read when the project file is processed.
To obtain the contents of an environment value at the time when the generated Makefile is processed, use the $(...) operator:
DESTDIR = $$(PWD)
message(The project will be installed in $$DESTDIR)
DESTDIR = $(PWD)
message(The project will be installed in the value of PWD)
message(when the Makefile is processed.)
In the above assignment, the value of PWD is read immediately when the project file is processed, but $(PWD) is assigned to DESTDIR in the generated Makefile. This makes the build process more flexible as long as the environment variable is set correctly when the Makefile is processed."
In message() need to use different notation for some reason:
message(DESTDIR: ($$DESTDIR))
I had such problem today. Solved only by looking at qmake .pro files examples in Qt mailing list. Another possible problem - clue variables:
# ${VAR} notation allows to append the contents of the variable to another value
# without separating the two with a space
isEmpty(DESTDIR): DESTDIR = $${IDE_BUILD_TREE}/lib/qtcreator/plugins
Without such notation I got empty DESTDIR variable.
I have a few questions on this $PATH in Linux.
I know it tells the shell which directories to search for executable files, so:
What does it mean an environmental variable?
How to change its path? and is it recommended to change it?
IF i change it what are the consequences?
To get your path current $PATH variable type in:
echo $PATH
It tells your shell where to look for binaries.
Yes, you can change it - for example add to the $PATH folder with your custom scripts.
So: if your scripts are in /usr/local/myscripts to execute them you will have to type in a full path to the script: /usr/local/myscripts/myscript.sh
After changing your $PATH variable you can just type in myscript.sh to execute script.
Here is an example of $PATH from RHEL:
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/user/bin
To change your $PATH you have to either edit ~/.profile (or ~/.bash_profile) for user or global $PATH setting in /etc/profile.
One of the consequences of having inaccurate $PATH variables is that shell will not be able to find and execute programs without a full $PATH.
Firstly, you are correct in your statement of what $PATH does. If you were to break it somehow (as per your third point), you will have to manually type in /usr/bin/xyz if you want to run a program in /usr/bin from the terminal. Depending on how individual programs work, this might break some programs that invoke other ones, as they will expect to just be able to run ls or something.
So if you were to play around with $PATH, I would suggest saving it somewhere first. Use the command line instruction
echo $PATH > someRandomFile.txt
to save it in someRandomFile.txt
You can change $PATH using the export command. So
export PATH=someNewPath
HOWEVER, this will completely replace $PATH with someNewPath. Since items in path are separated by a ":", you can add items to it (best not to remove, see above) by executing
export PATH=$PATH:newPath
The fact that it is an environmental variable means that programs can find out its value, ie it is something that is set about the environment that the program is running in. Other environmental variables include things like the current directory and the address of the current proxy.
this is simple and i do like this way.
Open the linux bash shell and print the environment variables:
printenv
I copy "PATH" variable to a text editor and edit as I want. Then update the PATH like this
export PATH= /variable dir list/
It Works.
or if you want to add an single variable use this command.
export PATH = $PATH:/variable_dir_path/
This will extends the PATH with your new directory path.
I have an old version of a program sitting on my machine. This program recently had a version upgrade. The way I used to run my old program was by typing "runProgram". The path to the runscript of my program was specified in my PATH variable as
PATH = ....:/path/to/my/old/programs/bin
I want to run the new version of this same program alongside my old program and the way I was thinking of doing it was by modifying my PATH variable as follows:
PATH = ....:/path/to/my/old/programs/bin:/path/to/my/new/programs/bin
What I want to achieve is some way to alias these two paths so that when I type 'runVersion1', the previous version is executed and when I type 'runVersion2', the new version is executed?
Is there a way to achieve that?
Thanks
If the program itself runs other programs from the bin directory, then when you run a version 1 program, you want to ensure that the version 1 directory is on the PATH ahead of the version 2 directory, and vice versa when you run a version 2 program. That is something I deal with all the time, and I deal with it by ensuring that the PATH is set appropriately.
In my $HOME/bin, I would place two scripts:
RunVersion1
export PATH=/path/to/my/old/programs/bin:$PATH
# Set other environment variables as needed
exec runProgram "$#"
RunVersion2
export PATH=/path/to/my/new/programs/bin:$PATH
# Set other environment variables as needed
exec runProgram "$#"
This technique of placing shell scripts on my PATH ahead of other programs allows me to pick which programs I run.
Semi-Generic Version
Often, I'll use a single program to set the environment and then link it to the various program names that I want to handle. It then looks at $0 and runs that:
export PATH=/path/to/my/new/programs/bin:$PATH
# Set other environment variables as needed
exec $(basename $0 2) "$#"
If this script is linked to RunProgram2, the basename command lops off the 2 from the end of RunProgram2 and then executes RunProgram from the more recent directory.
I've used this general technique for accessing 32-bit and 64-bit versions of the software on a single machine, too. The programs I deal with tend to have more complex environments than just a setting of $PATH, so the scripts are bigger.
One of the main advantages of scripts in $HOME/bin over aliases and the like is that it doesn't much matter which shell I'm stuck with using; it works the same way. Plus I don't have so many places to look to find where the alias is defined (because it isn't defined).
I would put two alias definitions in your ~/.bashrc (depending what shell you are using).
alias runVersion1='/path/to/my/old/programs/bin/program'
alias runVersion2='/path/to/my/new/programs/bin/program'
After editing that file you need to relogin or simply execute
. ~/.bashrc
The way you suggest with $PATH won't do what you want. One way that might:
Given that usually, /usr/local/bin is in $PATH, and that that is the standard location for "local binaries", you do the following:
sudo ln -s /path/to/my/old/programs/bin/myprogram /usr/local/bin/runVersion1
sudo ln -s /path/to/my/new/programs/bin/myprogram /usr/local/bin/runVersion2
Alternatively, if you don't want it to be system-wide (i.e. instead, just for your user), you could:
ln -s /path/to/my/old/programs/bin/myprogram $HOME/bin/runVersion1
ln -s /path/to/my/new/programs/bin/myprogram $HOME/bin/runVersion2
(assuming $HOME/bin is in your $PATH)
Now this won't necessarily fix your problem - could use a little more information in the question, BUT it should help you get further with what you're trying to do.
I am looking to set up the path for the source code when debugging with gdb. I chose to do that with a .gdbinit file.
Basically, it contains a command:
directory="/path/to/src".
However, I would like to be able to specify that command as:
directory="$SOURCESROOT/src"
where SOURCESROOT is an environment variable. And, if possible, being able to do that inside gdb debuuging session too, by entering directory=$SOURCESROOT/folder.
Basically, I am looking to access inside gdb (or inside .gdbinit) the environment variables.
But not the environment of the debugee (set env and so on), but the environment of the gdb itself (ie. of the bash prompt where I type in the first place "gdb program").
While typing shell $SOURCESROOT inside gdb session shows the content of the environment variable, this is quite useless, as I cannot enter: directory=shell $SOURCESROOT.
PS: Anybody found an ideal setup for Linux (Debian) to download the sources with "apt-get source", to update those with some kind of "apt-get update" utopic command and to install them so that gdb will automatically find these sources?
Nevermind, I found how to do it by using Python scripting.
My .gdbinit file is now:
python
import os
gdb.execute('directory' + os.environ['SOURCES'] + '/package_name/src')
end
show directories
(6 year late!)
Don't use .gdbinit for this purpose. It does not expand env vars. Instead, use this commandline to launch gdb:
gdb --init-eval-command="set dir $SOURCESROOT/src"
(gdb) show dir
/path/to/src
FYI this technique can be used to set other critical variables, e.g
gdb --eval-command="set sysroot $SYSROOTDIR"
Which sets sysroot and solib-absolute-prefix in gdb
If you don't want to involve python, then this could work?
"show environment [varname]
Print the value of environment variable varname to be given to your program when it starts. If you do not supply varname, print the names and values of all environment variables to be given to your program. You can abbreviate environment as env."
ftp://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_19.html
Maybe they could be used for conditions as well:
https://www.adacore.com/gems/gem-119-gdb-scripting-part-1
In my case I'd like to set global history in common $HOME/.gdbinit, so I used
set history filename ~/.gdb_history
instead of
set history filename $HOME/.gdb_history