Oct 12, 2013 The env will only display a list of environment variables that have been exported and it will not show all bash variables. The set command allows you to change the values of shell options and set the positional parameters, or to display the names and values of shell variables. If no options or arguments are supplied, set displays the names. Paths set in /etc/paths are added to the PATH at startup in all shells on Mac OS X. /.bashprofile is just one of several shell scripts run by Bash at startup, and several of these are Bash-specific. Therefore, if you change your shell — Mac OS X also ships tcsh and zsh, for example — changes made to /etc/bashrc don't apply to your new shell.
Set environment variables on Mac OS X Lion (10)
![Mac os x show all environment variables for processing Mac os x show all environment variables for processing](/uploads/1/2/6/5/126583908/401419057.png)
![Mac get all environment variables Mac get all environment variables](/uploads/1/2/6/5/126583908/466487687.png)
When someone says 'edit your .plist file' or 'your .profile' or '.bash_profile' etc, this just confuses me. I have no idea where these files are, how to create them if I have to do that, etc, and also why there seem to be so many different ones (why? Do they do different things?)
So could someone please explain very patiently to a previous Windows user (wanting desperately to become more familiar with the pleasant if initially somewhat confusing OS X world) how to do this step by step?
I need the variables to be set both for GUI applications and command line applications, and at the moment it's for an ant script that needs the variables, but there will most likely be other needs as well.
Please note that I have Lion too, since many of the answers you get Googling seem to be outdated for Lion...
Mac Os X Show Environment Variables
Also note that I have practically zero experience using the Terminal. I'm willing to learn, but please explain for a novice...
This was pretty straight forward and worked for me, in terminal:
A similar response was here: http://www.mac-forums.com/forums/os-x-operating-system/255324-problems-setting-path-variable-lion.html#post1317516
by Richard Burton Son Of Mac OS X Variables Part XI of this series... July 12th, 2002
This series is designed to help you learn more about the Mac OS X command line. If you have any questions about what you read here, check out the earlier columns, write back in the comments below, or join us in the Hardcore X! forum. In our previous column, we looked at shell variables: what they are, how to set them and unset them, etc. We ended with a quick perusal of reserved shell variables that the shell uses to hold certain values that are used for different parts of the shell. Normally, these are stored in environment variables. Environment variables are a special type of variable that are used to hold certain system-wide settings for a user. As an example, let's say that you are familiar and comfortable with the vi editor or the emacs editor (not to be mistaken for Apple's new eMac computer). Occasionally, a command-line program will want you to enter data and will use a built-in editor to provide a way to do this. Often a command-line program's default is to use either ed or ex, which shouldn't happen to a dog. It would be nice if this program would be able to say 'Okay, operating system, fire off a new process using the user's preferred editor,' at which point the operating system says 'Right-ho!,' looks up your preference, and fires up the appropriate editor. In Unix operating systems, this is done via environment variables. When the program wants to fire up an editor, and wants you to decide which to use, the system goes to a lookup table where it finds where you have set your editor of choice and starts it. Unix shells allow users to access and alter the values in this lookup table via environment variables. By convention, environment variables are in all capital letters, while shell variables are all lower case. You don't have to follow this convention, of course, when defining your own environment variables. However, it is a de facto standard; all of the 'built-in' environment variables are in all caps. Also, it does prevent confusion ... well, lessens it. So, like a good libertarian, I'm not saying that you have to do it, but I am saying that you really should. To find out which environment variables are defined in your current shell, either by you or for you, simply use the env Unix command. You will see: ... or something like it. You can see that there are quite a few environment variables set when you open a terminal window. What some of them represent should be fairly obvious, such as OSTYPE=darwin, VENDOR=apple, USER=dr_unix, and so on. On the other hand, there is that big, ugly, massive value for TERMCAP. If that one is obvious to you, seek professional help. Now.(In case you are curious, TERMCAP holds a multitude of settings about your terminal ... which type of terminal you are emulating; what functions do various keys perform, like linking the delete key to the delete action; and so on. Don't worry about it, and don't change it; otherwise, you might do yourself mischief.) You can create a new environment variable, or change the value of a current environment variable, with the csh/tcsh command setenv: For example,Notice that you can use the value of an environment variable just like a shell variable, with the '$' or the '${}' construct to avoid confusion.[Author's note: Uncle B.S. is copyright Tim Wilson.]Likewise, you can create an environment variable without assigning it a value. This distinction can be important in scripts, because 'undefined' is not quite the same as 'defined but with no value'. Furthermore, if you provide setenv with no arguments, it lists all the environment variables and their values, just like env:Note that $FRED and $JOE have now shown up. Now, given that you can set an environment variable, you might suspect that you can also unset a variable; and you would be right, you clever person. The unsetenv command does this:As you might imagine, there are quite a few environment variables that are reserved to have particular meanings in tcsh and csh. The most useful ones in my experience, are:
$PATH deserves special mention. When you type a command at the command line, or in a shell script, tcsh will use $PATH to find the command. $PATH contains a list of directories, seperated by colons. tcsh will look in the first directory; if it finds the command, it runs it, otherwise it moves to the next directory. If it is not found at all, tcsh prints an error message. Consider an example using my $PATH: If, at the command line, I tell tcsh to run the command my_script,tcsh will look for the file /Users/dr_unix/bin/powerpc-apple-darwin/my_script. If there is no such file, it looks for /Users/dr_unix/bin/my_script, then /usr/local/bin/my_script, and so on, until it finds it or gets through the last directory listed, ./my_script. (Remember that '.' here means 'my current working directory', so the shell is looking for the same as ${PWD}/my_script.) If I don't have a file 'my_script' in any of these directories, the shell prints an error:Also, if you create a shell script that is the same name as another script in your $PATH, which one is run first depends on which is encountered first as the shell sequentially searches the directories listed in $PATH. So not only is it sensible not to create a shell script called ls because it is a standard tool, you can see now exactly how this can cause confusion. If this situation does arise, the which command is useful. It tells you which particular file will be run, if any, when you type in a command:One of the primary reasons that csh was created was that the syntax is similar to the C programming language. The idea was that, by creating a shell with syntax similar to C, the learning curve would be much smaller and less steep. C and the Bourne shell (the first Unix shell) are obviously quite different languages. One of the features of C is that global variables (which are sort of analogous to a shell's environment variables) are not, generally, lower case; in C, those are generally used for macros and definitions. To reconcile this feature of C with this feature of Unix shells, csh has something called 'paired variables'.Paired variables are a combination of a reserved shell variable and a reserved environment variable whose values are tied together. Both variables are set to point to the same spot in memory, so changing the value of one will also change the value of the other. For example, $term and $TERM both refer to the type of terminal one is emulating. Note that, though the two values are tied together, the shell variable is still used and manipulated like a normal shell variable; ditto for the environment variable. Note, in the following example, how $PATH and $path are tied together, but each uses its own particular syntax. If we modify $path it alters $PATH as well.Personally, I don't depend on paired variables because other shells don't use them. Since I use ksh at work and the default on OS X is tcsh, I prefer to use the environment variables for anything environment-related. Again, you don't have to do this, but you will find it easier to move between shells and Unixes (Unici?) if you do so. And this is supposed to be about making life easy, isn't it?By now you are probably ready to jump in and modify/create your .cshrc and .login files. However, you first must know how to edit files on the command line, which we will start in the next column. You are encouraged to send Richard your comments, or to post them below. Most Recent Mac OS X Command Line 101 Columns Command Line History & Editing Your Commands November 22nd Pico: An Easy To Use Command Line Editor November 1st Understanding The 'grep' Command In Mac OS X October 4th Command Line History & Editing Your Commands September 6th Mac OS X Command Line 101 Archives Back to The Mac Observer For More Mac News! Richard Burton is a longtime Unix programmer and a handsome brute. He spends his spare time yelling at the television during Colts and Pacers games, writing politically incorrect short stories, and trying to shoot the neighbor's cat (not really) nesting in his garage. He can be seen running roughshod over the TMO forums under the alias tbone1. |