I'm trying to setup a project, storm from git:
https://github.com/nathanmarz/storm/wiki/Setting-up-development-environment
Download a Storm release , unpack it, and put the unpacked bin/ directory on your PATH
My question is: What does PATH mean? What exactly do they want me to do?
Sometimes I see some /bin/path, $PATH, or echo PATH.
Can someone explain the concept of PATH, so I can setup everything easily in the future without just blindly following the instructions?
PATH is a special environment variable in UNIX (and UNIX-like, e.g. GNU/Linux) systems, which is frequently used and manipulated by the shell (though other things can use it, as well).
There's a somewhat terse explanation on wikipedia, but basically it's used to define where to search for executable files (whether binaries, shell scripts, whatever).
You can find out what your current PATH is set to with a simple shell command:
: $; echo $PATH
(Note: the : $; is meant to represent your shell prompt; it may be something very different for you; just know that whatever your prompt is, that's what I'm representing with that string.)
Depending on your system and prior configuration, the value will vary, but a very simple example of the output might be something like:
/usr/bin:/bin:/usr/local/bin
This is a colon(:)-separated list of directories in which to search for executable files (things like ls, et cetera.) In short, when you try to execute a command from your shell (or from within some other program in certain ways), it will search through each of the directories in this list, in order, looking for an executable file of the name you're provided, and run the first one it finds. So that's the concept, per your question.
From there, what this documentation is telling you to do is to add the directory where you've unpacked the software, and in particular its bin subdirectory, into your $PATH variable. How to do this depends a bit on which shell you're using, but for most (Bourne-compatible) shells, you should be able to do something like this, if you're in the directory where that bin directory is:
: $; PATH="$PATH:$PWD/bin"; export PATH
In just about all but an actual Bourne shell, this can be shortened to:
: $; export PATH="$PATH:$PWD/bin"
(I won't bother explaining for CSH-compatible shells (because: I agree with other advice that you don't use them), but something similar can be done in them, as well, if that happens to be your environment of choice for some reason.)
Presumably, though, you'll want to save this to a shell-specific configuration file (could be ~/.profile, ~/.bashrc, ~/.zshrc... depending on your shell), and without reference to $PWD, but rather to whatever it expanded to. One way you might accomplish this would be to do something like this:
: $; echo "export PATH=\"\$PATH:$PWD/bin\""
and then copy/paste the resulting line into the appropriate configuration file.
Of course you could also generate the appropriate command in other ways, especially if your $PWD isn't currently where that bin directory is.
See also:
An article about $PATH (and more)
a related question on superuser.com
Related
I'm sure this is one of the dumbest problems asked on this site, but I am very new to linux, and a little out of my depths. I'm working off of this tutorial here and am stuck on the "add the path" and verify steps.
For this one the tutorial told me to use this:
export PATH=${PATH}:${DTITK_ROOT}/bin:${DTITK_ROOT}/utilities:${DTITK_ROOT}/scripts
I have already defined DTITK_ROOT, and have a few questions about the above instructions.
Should the ${} be left around the DTITK_ROOT?
My DTITK_ROOT is the full path (I think that's the right term) to the file I extracted the program to, should I change that?
What do I write for ${PATH} in that case? I understand that I'm supposed to replace it with something, but I don't know what. Everything I've tried doesn't pass the verify step.
I'm sorry if it seems like a dumb or really simple question, but I don't even know any keywords to google in order to find how to get the answer.
Yes. This is how you access the path stored in DTITK_ROOT. This is called parameter expansion. You can read more about it here.
No, don't change anything. Also, a more commonly used term is absolute path, in comparison to relative path. The absolute path is a path from the root directory, /. Relative path is a path from your current working directory. You can read more about paths in general and the difference between absolute and relative paths here.
You don't replace it with anything. Once again, parameter expansion comes into play and this will be replaced with what is already stored in your path variable. So really all this command is doing is taking your path variable, adding some more paths to it, and then storing it back into your path variable. If you didn't know, the path variable contains paths to all executable files that you would like to execute without typing the full path. Here is a good discussion on path variables, along with other environment variables.
1st command takes care of path
export DTITK_ROOT=mypathonSystem/dtitk
2nd command
export PATH=${PATH}:${DTITK_ROOT}/bin:${DTITK_ROOT}/utilities:${DTITK_ROOT}/scripts
I am not too sure but I think second command should run as is since you defined DDTITK_ROOT in first command
${PATH} is letting the system know where the resources can be found at
have you tried running first command, then running second command unmodified?
Should the ${} be left around the DTITK_ROOT?
Yes. In the case of the shell, it is not essential here because the / that follows the $DTITK_ROOT is enough to signal that we have reached the end of the variable name, but doing ${DTITK_ROOT} explicitly says that the variable name is DTITK_ROOT and not that plus whatever characters might be on the end of it. Other programs (such as make) which allow you to write shell commands to execute might not be so accommodating - make would think that $DTITK_ROOT would be the value of $D followed by the literal characters TITK_ROOT. So, it is a good practice to just get used to putting {} around shell variable names that are longer than a single character.
My DTITK_ROOT is the full path to the file I extracted the program to, should I change that?
If you mean the full path to the directory that you extracted the program to, then that is what you should use. I am assuming that you have something like "export DTITK_ROOT=/Users/huiz/unix/dtitk" (per the example).
On thing you can do is to verify that the value of DTITK_ROOT is available by executing a "echo ${DTITK_ROOT}" to verify that it has the proper value.
This came up in coursework, and I'm stuck:
Many systems have more than one version of a utility program so that users can choose the one they want. Suggest a command to find all the versions of make on a system. What determines which one a user actually gets? How might a user override the defaults?
How would you do that?
How UNIX finds programs
Unix-like systems store their executable programs in various directories for historical reasons.
The directories that are searched when you want to run a command are stored in an environment variable called $PATH, separated by colons (:). To see its contents, type echo "$PATH" in a terminal window. On my system, that shows (split to avoid a long line)
/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:
/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
They're searched in that order. If I want to run make, the system will first check /usr/local/sbin/make (which doesn't exist), then /usr/local/bin/make (also non-existant), then /usr/bin/make (which does exist, so it runs that).
How to figure out which one would run
The program which can be used to look through $PATH to figure out what program would be chosen. Running which make on my system produces the output /usr/bin/make.
Conveniently, which has a -a flag to print all executables that match, not just the first one. (I found this by consulting its manual, by running man which.) So which -a java should tell you where all of the versions of java are.
Changing the defaults
If you like, you can change the contents of the $PATH variable, like you can change any environment variable: If I run PATH="$PATH:/home/anko/bin", the next time the system needs to find a program, it will check through all of what $PATH used to be, plus a directory called bin in my home directory if it couldn't find anything else.
I could also prepend the directory, to make it take precedence over anything else, by doing PATH="/home/anko/bin:$PATH".
Can I force BASH to see certain folder (let's call it main_folder) as the root of my file-system? I need BASH to behave this way at least during auto-completion of parameter names and command names, while inside the folder.
Let's say that I have directory tree that looks like this:
/z/y/main_folder/a.txt
/z/y/main_folder/bin/b.txt
/z/y/main_folder/bin/c.txt
/z/y/main_folder/bin/d.sh
Now that I call this custom version of bash, I could simply type:
/> /bi(TAB)/(TAB) /a(TAB)
What would expand to:
/> /bin/d.sh /a.txt
Where d.sh is command to be run and a.txt is it's first parameter. If I was CDed into /bin/ I could do:
/bin/> ./(TAB) (TAB)(TAB)
What would expand the command d.sh, and would give three options for the first parameter (namely: b.txt, c.txt, d.sh).
Few brief additional points:
I do not care if the original root of the file-system is inaccessible or is accessible via hard/soft link.
I do not care if I am able to run any commands that are out of scope for main_folder (I will change the $PATH variable anyway) or any shell builtins.
I do not care what the $PS#, $PWD, etc. variables actually hold.
I do not want to make my own version of BASH (changing source-code). My application should (probably) be started via some script (sh) or program (C/C++/C#) that setups the environment and either continues in interactive mode or runs interactive shell on one of it's last lines.
I want to run this as an unprivileged user. I do not want to allow the user to chroot.
I am not concerned with security, and I am not intending to jail anyone. I simply need BASH to auto-complete.
I would not mind to 'trap' BASH during directory lookups.
I have a feeling that set, compgen, complete and compopt builtins are what I need to utilize, but I do not know how. It does not seem that the examples I have found about these commands show all the features, and man pages are quite chaotic.
Thanks, Kupto :)
I want to create some bash scripts. They're actually going to be build scripts for Scala, so I'm going to identify them with my own .bld extension. They will be a sort of sub type of a shell script. Hence I want them to be easily recognised as a shell script. Should I call them
ProjectA.bld.sh //or
ProjectA.sh.bld
Edit: My natural inclination would be to go for the former but .tar.gz files seem to follow the latter naming convention.
A shell script doesn't mind what you call it.
It just needs to be..
executable (chmod +x)
in your path
contain a "shebang" as it's first line #!/bin/sh
The shebang determines which program is used to execute your script.
Call it ProjectA.bld.sh (or preferably buildProjectA.sh).
The .sh extension (although not necessary for the script to run) will allow you and everyone else to easily recognise it as a shell script.
While for the most part, naming conventions like this don't really matter at all to Unix/Linux, the usual convention is for the "extensions" to be in the order of the steps used to create the file. So, for example, a file named foo.tar.bz2.gpg.part01 would indicate a sequence of operations like the following:
Use tar to create foo.tar, which contains some other files
Use bzip2 to compress foo.tar into foo.tar.bz2
Use gnupg to encrypt foo.tar.bz2 into foo.tar.bz2.gpg
Use split or something similar to break the file into chunks for transmission/storage, resulting in one or more foo.tar.bz2.gpg.part* files.
The naming conventions are mostly just for human semantic meaning, though, and there's nothing stopping you from doing exactly the opposite, or even something completely random, except your own ability to remember exactly what you did...
On Linux and other Unix-likes, how do I find the path to a specific file that I can use because of the PATH environment variable? For example, if I can use, from the command line:
ls # technically the file name is "ls.exe"
is there a way I can find the path of the ls.exe file explicitly without looking through the PATH variable myself (i.e. maybe have a program search through it but not look myself)?
I understand there are many pitfalls/caveats of doing this, for example a PATH can be a file or even part of a file (I think), plus symlinks, etc. could make it unreliable, but I'm looking for general use cases.
The reason I am asking is I have Windows with msysgit so I have A LOT of folders in my path, and searching every one would be annoying & time-consuming, not to mention harder because of Windows limitations, but I can still presumably use almost anything Linux can use.
$ type ls.exe
ls.exe is /usr/bin/ls.exe