I am very new to Linux and I put the following command at the end of the file .profile under my home folder:

export PATH="~/.composer/vendor/bin:$PATH"

I know the issues of environment variables and their values a bit from Windows, but in this case I want to understand what this command does, and what are the parts that it comprises:

  1. What is this "export" phrase at the start? Is it exporting the data to be available for Bash?

  2. What is the first PATH and what is the second $PATH, and why do we need two?

  • Some technical differences between the OSes aside, it's equivalent to this process on Windows: windowsitpro.com/systems-management/… Jan 13, 2016 at 18:36
  • 1
    "export" makes the change visible to new programs launched by bash. Jan 14, 2016 at 1:16
  • 1
    @ThorbjørnRavnAndersen: no, that happens whether or not you use the export command, because the PATH variable is already marked as exported. (Try it both ways if you don't believe me!)
    – David
    Jan 14, 2016 at 17:18

6 Answers 6


What is this "export" phrase at the start?

export is a command (more precisely it's a Bash builtin, i.e. it's not an executable present in PATH, it's a command that Bash has built-in in itself).

Is it exporting the data to be available for Bash?

export sets the environment variable on the left side of the assignment to the value on the right side of the assignment; such environment variable is visible to the process that sets it and to all the subprocesses spawned in the same environment, i.e. in this case to the Bash instance that sources ~/.profile and to all the subprocesses spawned in the same environment (which may include e.g. also other shells, which will in turn be able to access it).

What is the first PATH and what is the second $PATH, and why do we need two?

The first PATH as explained above is the environment variable to be set using export.

Since PATH normally contains something when ~/.profile is sourced (by default it contains /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games), simply setting PATH to ~/.composer/vendor/bin would make PATH contain only ~/.composer/vendor/bin.

So since references to a variable in a command are replaced with (or "expanded" to) the variable's value by Bash at the time of the command's evaluation, :$PATH is put at the end of the value to be assigned to PATH so that PATH ends up containing ~/.composer/vendor/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games (i.e. what PATH contains already plus ~/.composer/vendor/bin: at the start).

  • 2
    Terrific explanation. Dec 1, 2017 at 16:55
  • 2
    So does the colon ":" serve as delimiter in Bash?
    – Sean
    Jul 9, 2020 at 7:01
  • @Sean: yes, it separates the different paths from one another.
    – GeertVc
    Apr 30 at 14:42

https://help.ubuntu.com/community/EnvironmentVariables will probably help you. Also man bash may be very helpful with understanding how that works (at least in Bash)

Anyway - as for PATH= you're basically setting the PATH variable, adding some new paths to search through, adding at the end already / previously set paths, with $PATH (which is basically a reference to the PATH variable).

So, say your PATH was so far set to something like:


and then you set


your PATH after that will be like:


I hope that makes sense.

And on top of that you export the new variable so it's known in your environment including also child processes / subshells.

Just be aware also that the order of the directories as set in PATH can be important. And something like PATH="$PATH:a:b:c" will give you the result:


which will affect the order of directories / paths while searching for a command (if you have your command in more than one of directories, the first found will be used - which may give you some unexpected results sometimes).


Here's the command so that everybody can follow along as they go through the bullet points. export PATH="~/.composer/vendor/bin:$PATH"

  • export shell built-in (meaning there is no /bin/export ,it's a shell thing) command basically makes environment variables available to other programs called from bash ( see the linked question in Extra Reading ) and the subshells.
  • Assignment in shell will take expansion first , then assignment will take place second. So what is inside double quotes gets expanded first, saved to PATH variable later.
  • $PATH is the default PATH assignment ( or at least what the variable looks like up till this command appears in your .bashrc or .profile), and expand it.
  • ~/.composer/vendor/bin is going to expand to /home/username/.composer/vendor/bin , where .composer is hidden folder due to the leading dot.
  • That short ~/.composer/vendor/bin:$PATH have now transformed into long list of folders, separated by :. Everything is enclosed into double quotes so that we include folders with spaces in their path.
  • Finally everything is stored into PATH variable and external commands allowed to use it

Simple Example

My interactive shell is actually mksh , which happens to also have export builtin. By using export to set VAR, my variable can be passed to and used by subsequent chain of commands/subprocesses, where I exported that same variable

$ echo $SHELL            
$ VAR="HelloAskUbuntu"
$ bash -c 'echo $VAR' 
$ export VAR="HelloAskUbuntu"                                                  
$ bash -c 'echo $VAR'                                                          

Extra Reading

  • 3
    No, the ~ in ~/.composer/vendor/bin will not be expanded! The tilde is only expanded in few special places, like directly after the = sign. PATH="~/.foo:$PATH" results in ~/.foo:/other/path/dirs.... But ~ would be expanded in PATH=~"/.foo:$PATH", which results in /home/user/.foo:/other/path/dirs.... Jan 14, 2016 at 3:49

I have read here and in other places in the web, spoke with a friend about this and decided that as a freshman (maybe more of an Ubuntu freshman then some here might think), I should map this command - I should make a map and thus learn it's whatabouts and whereabouts:

Preliminary data

If for now you didn't understand something in this chapter - don't worry, it will get clearer as you will keep reading, but to understand this matter you do need to read on Environment variables (EVs), their values, and purpose. I will now try to explain the command in simple words and in a method of mapping, for newcomers like me, and only for newcomers. Tried to do my best here...


export PATH="~/.composer/vendor/bin:$PATH"

The original value of the EV "PATH" as it comes with Ubuntu 15.10, is:


In the command itself note we have two PATH phrases. The last one is $PATH - The $ says "print the original value or values of the EV next to you"; The EV next to it is the PATH EV.

We exported the path variable itself (made it available for sub processes as well, I.E processes that run in the CLI which are not actually the Bash shell, but run inside it (such as Drush, which is the Drupal CLI).

Besides the export we also expanded it: The first PATH phrase (PATH=) used us to add an extra value (~/.composer/vendor/bin:) to the original value (represented by $PATH).

  • The colon (:) in the end of the new value I mentioned in the above paragraph, uses to distinct the new value from the original one.

  • The "" are the area in which the value/s reside.

  • The ~ is the home folder.

I hope that after this mapping I did, the command will be clearer to freshmen like myself.


The export command makes variables available in subshells. That is, without it, the variable PATH would not be visible in subshells.

PATH is mentioned twice:

  • As variable the value is being assigned to, left of the = sign.
  • As variable name being replaced by its value right of the = sign. This makes the old value be part of the new value.
  • 1
    "That is, without it, the variable PATH would not be visible in subshells." This is incorrect; PATH is an environment variable (which is not quite the same thing as a shell variable) so it is automatically exported, and the export command is unnecessary.
    – David
    Jan 14, 2016 at 16:24
  • The Bourne shell family does not really distinguish between shell and environment variables. (sc.tamu.edu/help/general/unix/vars.html) On my system (Arch Linux), bash does not even know the setenv command. Jan 14, 2016 at 16:41
  • 1
    There's still a difference between environment variables which the kernel knows about, and shell variables which are internal to bash. Since PATH originates from the environment, it is automatically exported, so you don't need to run export for changes to be propagated to child processes (contrary to what the page you linked says).
    – David
    Jan 14, 2016 at 17:16
  • Environment variables are not a property of the kernel, but of the process. Since the process we are talking about here is sh, bash (does Ubuntu use zsh?), I think we can leave them being equal to shell variables. But, of course, shell variables are not passed to any random programs as environment variables are. Jan 14, 2016 at 17:38
  • I think we're getting bogged down in semantics at this point. All I was trying to say was that in bash, PATH=foo and export PATH=foo have identical behavior.
    – David
    Jan 14, 2016 at 20:17
export PATH="~/.composer/vendor/bin:$PATH"
  1. the export is a buildin command of bash, means export variables to be envirement variable. (you could type help export to lean more

    (the charactors follow the command are parammeters, splited by space, so in this case, there only one parameter)

  2. the PATH is the variable name, usually, predefined varibale by bash, be named in Uppercase.

  3. the = means assign value to this variable.

  4. all the string is the value of the varibale

  5. the $PATH is a kind of funciton of bash, named variable expantion, bash will replace the value of the exist PATH in the parameter string, BEFORE send the string to export command

  6. the : in a spcial char in PATH variable and understooded by all application that want to use this variable. it means seperator. so they will have a lot of directories in the PATH variable.

You must log in to answer this question.