Environment Variables vs Positional Parameters
Before we begin discussing
$INTEGER type of variables, we need to understand what they really are and how they differ from environment variables.Variables such as
$INTEGER are called positional parameters. This is described in the POSIX (Portable Operating System Interface) standard, section 2.1 (emphasis mine):
- The shell executes a function (see Function Definition Command), built-in (see Special Built-In Utilities), executable file, or script, giving the names of the arguments as positional parameters numbered 1 to n, and the name of the command (or in the case of a function within a script, the name of the script) as the positional parameter numbered 0 (see Command Search and Execution).
By contrast, variables such as
$PATH are environment variables. Their definition is described in section 8 of the standard:
Environment variables defined in this chapter affect the operation of multiple utilities, functions, and applications. There are other environment variables that are of interest only to specific utilities. Environment variables that apply to a single utility only are defined as part of the utility description.
Notice their description. Positional parameters are meant to appear in front of a command, i.e.
command positional_arg_1 positional_arg_2.... They are meant to be provided by user to tell command what specifically to do. When you do
echo 'Hello' 'World', it will print out the
World strings, because these are positional parameters to
echo - the things you want
echo to operate on. And
echo is built such that it understands positional parameters as strings to be printed (unless they're one of the optional flags like
-n ). If you do this with different command it might not understand what
World is because perhaps it expects a number. Notice that positional parameters are not "inherited" - a child process does not know about positional parameters of the parent unless explicitly passed to the child process. Often you see positional parameters being passed with wrapper scripts - the ones that maybe check for already existing instance of a command or add additional positional parameters to the real command that will be called.
By contrast, environment variables are meant to affect multiple programs. They are environment variables, because they're set outside of the program itself (more on this below). Certain environment variables such as
PATH have specific format, specific meaning, and they'll mean the same to each program.
HOME variable will mean same to either external utility like
/usr/bin/find or your shell ( and consequently to a script ) - it's the home directory of the username under which process runs. Notice that environmental variables can be used to account for specific command behavior, for instance
UID environment variable can be used to check whether the script runs with root privileges or not and branch to specific actions accordingly. Environment variables are inheritable - child processes get copy of parent's environment. See also If processes inherit the parent's environment, why do we need export?
In short, the main distinction is that environment variables are set outside of the command and not meant to be varied (usually), while positional parameters are things that are meant to be processed by the command and they change.
Not just shell concepts
What I've noticed from comments is that you're mixing up terminal and shell, and would really recommend you read about real terminals that once upon a time were physical devices. Nowadays, the "terminal" that we're typically referring to, that window with black background and green text is actually software, a process. Terminal is a program that runs a shell, while shell is also a program but the one that reads what you type in to execute ( that is, if it is interactive shell; non-interactive shells are scripts and
sh -c 'echo foo' types of invocations). More on shells here.
This is an important distinction, but also important to recognize that terminal is a program and therefore adheres to the same rules of environment and positional parameters. Your
gnome-terminal when started will look at your
SHELL environment variable, and spawn the appropriate default shell for you, unless you specify some other command with
-e. Let's say I changed my default shell to
ksh - gnome-terminal will then spawn
ksh instead of
bash. That's also an example of how environment is used by programs. If I explicitly tell
-e to run specific shell - it will do it, but it won't be permanent. By contrast, environment is meant to be mostly unaltered (more on that later).
So as you can see, environment and positional variables are both properties of a process/command, not just shell. When it comes to shell scripts, they also follow the model that was set by C programming language. Take for instance the C
main function which typically looks like
int main(int argc, char **argv)
argc is number of command-line arguments and
argv is effectively array of command-line parameters, and then there's
environ function ( on Linux that's
man -e 7 environ ) to access things like user's home directory path, list of directories in
PATH where we can look for executables, etc. Shell scripts are also modeled in the similar way. In shell terminology, we have positional parameters
$2 and so forth, while
$# is number of positional parameters. What about
$0 ? That's the name of the executable itself, which is again also modeled from C programming language -
argv would be name of your C "executable". And this is fairly true for most programming and scripting languages.
Interactive vs Non-interactive shells
One of the things I've already hinted is the distinction between interactive and non-interactive shells. The prompt where you type in commands - that's interactive, it interacts with the user. By contrast when you have a shell script or you run
bash -c'' that's non-interactive.
And this is where distinction becomes important. The shell that you run already is a process, which was spawned with positional parameters ( for
bash login shell is one "...whose first character of argument zero is a -, or one started with the --login option." (reference ) )
By contrast, scripts and shells launched with
-c option can take advantage of
$2 arguments. For instance,
$ bash -c 'echo $1; stat $2' sh 'Hello World' /etc/passwd
Size: 2913 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 6035604 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-08-12 14:48:37.125879962 -0600
Modify: 2017-08-12 14:48:37.125879962 -0600
Change: 2017-08-12 14:48:37.137879811 -0600
Notice that I've also used
sh there, because small quirk of
-c option is to take first positional parameter and assign it to
$0, unlike typically being a name of the program.
Another thing that is important to notice is that positional parameters are what I call "framable". Notice how, we first launched
bash with its own positional parameters, but those positional parameters became parameters to
stat. And each program understands it in its own way. If we gave to
stat a string
Hello World and there's no file
Hello World it would produce an error;
bash treats it just as a simple string but
stat expects that string to be an existing filename. By contrast, all programs would agree that environment variable
HOME is a directory ( unless the programmer coded it in an unreasonable way).
Can we mess around with environment variables and positional parameters ?
Technically, we can mess around with both, but we shouldn't mess around with environment variables, while we often have to provide positional parameters. We can run commands in shell with prepending a variable, for instance:
$ hello=world bash -c 'echo $hello'
We can also place variables into environment simply using
export variable=value from within shell or script. Or we can run a command with completely empty environment with
env -c command arg1 arg2. However, typically it is not recommended to mess around with environment, especially using upper-case variables or overwriting already existing environment variables. Notice that's recommended although not a standard.
For positional parameters, the way to set them is obvious, just prepend them to the command, but also there are ways to set them other wise, as well as change the list of those parameters via
In conclusion, purpose of these two is different, and they exist for a reason. I hope people gained some insight from this answer, and it was fun reading it just as it was for me to write this answer.
Note on set command
set command, according to manual behaves like so (from bash manual, emphasis added):
Without options, the name and value of each shell variable are displayed in a format that can be reused as input for setting or resetting the currently-set variables.
In other words
set looks at variables specific to shell, some of which happen to be in the environment, for example
HOME. By contrast commands like
printenv look at actual environment variable with which a command runs. See also this.