What is the difference between sourcing ('.' or 'source') and executing a file in bash?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
62
down vote

favorite
27












What's the difference between executing a script like this:



./test.sh



and executing a script like this:



. test.sh?



I tried a simple, two-line script to see if I could find if there was a difference:



#!/bin/bash
ls


But both . test.sh and ./test.sh returned the same information.







share|improve this question






















  • Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
    – Natan
    Jul 25 '12 at 6:32






  • 3




    Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh.
    – jw013
    Jul 30 '12 at 21:13














up vote
62
down vote

favorite
27












What's the difference between executing a script like this:



./test.sh



and executing a script like this:



. test.sh?



I tried a simple, two-line script to see if I could find if there was a difference:



#!/bin/bash
ls


But both . test.sh and ./test.sh returned the same information.







share|improve this question






















  • Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
    – Natan
    Jul 25 '12 at 6:32






  • 3




    Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh.
    – jw013
    Jul 30 '12 at 21:13












up vote
62
down vote

favorite
27









up vote
62
down vote

favorite
27






27





What's the difference between executing a script like this:



./test.sh



and executing a script like this:



. test.sh?



I tried a simple, two-line script to see if I could find if there was a difference:



#!/bin/bash
ls


But both . test.sh and ./test.sh returned the same information.







share|improve this question














What's the difference between executing a script like this:



./test.sh



and executing a script like this:



. test.sh?



I tried a simple, two-line script to see if I could find if there was a difference:



#!/bin/bash
ls


But both . test.sh and ./test.sh returned the same information.









share|improve this question













share|improve this question




share|improve this question








edited Sep 14 '16 at 9:32









terdon♦

122k28230401




122k28230401










asked Jul 25 '12 at 1:11









Natan

415159




415159











  • Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
    – Natan
    Jul 25 '12 at 6:32






  • 3




    Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh.
    – jw013
    Jul 30 '12 at 21:13
















  • Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
    – Natan
    Jul 25 '12 at 6:32






  • 3




    Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh.
    – jw013
    Jul 30 '12 at 21:13















Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
– Natan
Jul 25 '12 at 6:32




Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
– Natan
Jul 25 '12 at 6:32




3




3




Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh.
– jw013
Jul 30 '12 at 21:13




Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh.
– jw013
Jul 30 '12 at 21:13










4 Answers
4






active

oldest

votes

















up vote
69
down vote



accepted










./test.sh runs test.sh as a separate program. It may happen to be a bash script, if the file test.sh starts with #!/bin/bash. But it could be something else altogether.



. ./test.sh executes the code of the file test.sh inside the running instance of bash. It works as if the content file test.sh had been included textually instead of the . ./test.sh line. (Almost: there are a few details that differ, such as the value of $BASH_LINENO, and the behavior of the return builtin.)



source ./test.sh is identical to . ./test.sh in bash (in other shells, source may be slightly different or not exist altogether; . for inclusion is in the POSIX standard).



The most commonly visible difference between running a separate script with ./test.sh and including a script with the . builtin is that if the test.sh script sets some environment variables, with a separate process, only the environment of the child process is set, whereas with script inclusion, the environment of the sole shell process is set. If you add a line foo=bar in test.sh and echo $foo at the end of the calling script, you'll see the difference:



$ cat test.sh
#!/bin/sh
foo=bar
$ ./test.sh
$ echo $foo

$ . ./test.sh
$ echo $foo
bar





share|improve this answer


















  • 17




    Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
    – user13742
    Jul 25 '12 at 10:15






  • 1




    Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
    – Rqomey
    Jul 31 '12 at 8:33

















up vote
9
down vote













Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, runs the script as if you entered all its commands into the current shell - if the script sets a variable, it will remain set, if the script exits, your session will exit. See help . for documentation.






share|improve this answer





























    up vote
    3
    down vote













    Another thing that I note is that if you have an alias like this:



    # add into .bashrc_aliases
    alias ls='ls -lht'


    With ./test.sh you'll get a normal ls output (and a different PID than current shell):



    auraham@pandora:~/iso$ ./test.sh 
    dsl-4.4.10.iso test.sh
    3136 # PID


    With . test.sh or . ./test.sh you'll get a more detailed output (and the same PID than current shell):



    auraham@pandora:~/iso$ echo $$
    2767 # shell PID

    auraham@pandora:~/iso$ . test.sh
    total 50M
    drwxrwxr-x 2 auraham auraham 4.0K Jul 30 15:41 .
    -rwxrwxr-x 1 auraham auraham 32 Jul 30 15:41 test.sh
    drwxr-xr-x 50 auraham auraham 4.0K Jul 30 15:30 ..
    -rw-rw-r-- 1 auraham auraham 50M Jul 28 17:24 dsl-4.4.10.iso
    2767 # PID





    share|improve this answer






















    • You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
      – auraham
      Aug 1 '12 at 1:17











    • Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
      – Emanuel Berg
      Aug 1 '12 at 10:26










    • totally correct, my mistake. Thanks @EmanuelBerg
      – auraham
      Aug 1 '12 at 18:40

















    up vote
    -1
    down vote













    The main usage to me for source (or .) is bash functions.



    I have scripts with many functions and I execute all of them with my .bashrc. The functions "become" commands, which I use often.






    share|improve this answer






















    • I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
      – Emanuel Berg
      Jul 31 '12 at 0:16










    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f43882%2fwhat-is-the-difference-between-sourcing-or-source-and-executing-a-file-i%23new-answer', 'question_page');

    );

    Post as a guest






























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    69
    down vote



    accepted










    ./test.sh runs test.sh as a separate program. It may happen to be a bash script, if the file test.sh starts with #!/bin/bash. But it could be something else altogether.



    . ./test.sh executes the code of the file test.sh inside the running instance of bash. It works as if the content file test.sh had been included textually instead of the . ./test.sh line. (Almost: there are a few details that differ, such as the value of $BASH_LINENO, and the behavior of the return builtin.)



    source ./test.sh is identical to . ./test.sh in bash (in other shells, source may be slightly different or not exist altogether; . for inclusion is in the POSIX standard).



    The most commonly visible difference between running a separate script with ./test.sh and including a script with the . builtin is that if the test.sh script sets some environment variables, with a separate process, only the environment of the child process is set, whereas with script inclusion, the environment of the sole shell process is set. If you add a line foo=bar in test.sh and echo $foo at the end of the calling script, you'll see the difference:



    $ cat test.sh
    #!/bin/sh
    foo=bar
    $ ./test.sh
    $ echo $foo

    $ . ./test.sh
    $ echo $foo
    bar





    share|improve this answer


















    • 17




      Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
      – user13742
      Jul 25 '12 at 10:15






    • 1




      Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
      – Rqomey
      Jul 31 '12 at 8:33














    up vote
    69
    down vote



    accepted










    ./test.sh runs test.sh as a separate program. It may happen to be a bash script, if the file test.sh starts with #!/bin/bash. But it could be something else altogether.



    . ./test.sh executes the code of the file test.sh inside the running instance of bash. It works as if the content file test.sh had been included textually instead of the . ./test.sh line. (Almost: there are a few details that differ, such as the value of $BASH_LINENO, and the behavior of the return builtin.)



    source ./test.sh is identical to . ./test.sh in bash (in other shells, source may be slightly different or not exist altogether; . for inclusion is in the POSIX standard).



    The most commonly visible difference between running a separate script with ./test.sh and including a script with the . builtin is that if the test.sh script sets some environment variables, with a separate process, only the environment of the child process is set, whereas with script inclusion, the environment of the sole shell process is set. If you add a line foo=bar in test.sh and echo $foo at the end of the calling script, you'll see the difference:



    $ cat test.sh
    #!/bin/sh
    foo=bar
    $ ./test.sh
    $ echo $foo

    $ . ./test.sh
    $ echo $foo
    bar





    share|improve this answer


















    • 17




      Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
      – user13742
      Jul 25 '12 at 10:15






    • 1




      Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
      – Rqomey
      Jul 31 '12 at 8:33












    up vote
    69
    down vote



    accepted







    up vote
    69
    down vote



    accepted






    ./test.sh runs test.sh as a separate program. It may happen to be a bash script, if the file test.sh starts with #!/bin/bash. But it could be something else altogether.



    . ./test.sh executes the code of the file test.sh inside the running instance of bash. It works as if the content file test.sh had been included textually instead of the . ./test.sh line. (Almost: there are a few details that differ, such as the value of $BASH_LINENO, and the behavior of the return builtin.)



    source ./test.sh is identical to . ./test.sh in bash (in other shells, source may be slightly different or not exist altogether; . for inclusion is in the POSIX standard).



    The most commonly visible difference between running a separate script with ./test.sh and including a script with the . builtin is that if the test.sh script sets some environment variables, with a separate process, only the environment of the child process is set, whereas with script inclusion, the environment of the sole shell process is set. If you add a line foo=bar in test.sh and echo $foo at the end of the calling script, you'll see the difference:



    $ cat test.sh
    #!/bin/sh
    foo=bar
    $ ./test.sh
    $ echo $foo

    $ . ./test.sh
    $ echo $foo
    bar





    share|improve this answer














    ./test.sh runs test.sh as a separate program. It may happen to be a bash script, if the file test.sh starts with #!/bin/bash. But it could be something else altogether.



    . ./test.sh executes the code of the file test.sh inside the running instance of bash. It works as if the content file test.sh had been included textually instead of the . ./test.sh line. (Almost: there are a few details that differ, such as the value of $BASH_LINENO, and the behavior of the return builtin.)



    source ./test.sh is identical to . ./test.sh in bash (in other shells, source may be slightly different or not exist altogether; . for inclusion is in the POSIX standard).



    The most commonly visible difference between running a separate script with ./test.sh and including a script with the . builtin is that if the test.sh script sets some environment variables, with a separate process, only the environment of the child process is set, whereas with script inclusion, the environment of the sole shell process is set. If you add a line foo=bar in test.sh and echo $foo at the end of the calling script, you'll see the difference:



    $ cat test.sh
    #!/bin/sh
    foo=bar
    $ ./test.sh
    $ echo $foo

    $ . ./test.sh
    $ echo $foo
    bar






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 18 '17 at 18:29









    Jeff Schaller

    31.2k846105




    31.2k846105










    answered Jul 25 '12 at 1:27









    Gilles

    505k1199991527




    505k1199991527







    • 17




      Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
      – user13742
      Jul 25 '12 at 10:15






    • 1




      Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
      – Rqomey
      Jul 31 '12 at 8:33












    • 17




      Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
      – user13742
      Jul 25 '12 at 10:15






    • 1




      Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
      – Rqomey
      Jul 31 '12 at 8:33







    17




    17




    Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
    – user13742
    Jul 25 '12 at 10:15




    Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell.
    – user13742
    Jul 25 '12 at 10:15




    1




    1




    Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
    – Rqomey
    Jul 31 '12 at 8:33




    Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable"
    – Rqomey
    Jul 31 '12 at 8:33












    up vote
    9
    down vote













    Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, runs the script as if you entered all its commands into the current shell - if the script sets a variable, it will remain set, if the script exits, your session will exit. See help . for documentation.






    share|improve this answer


























      up vote
      9
      down vote













      Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, runs the script as if you entered all its commands into the current shell - if the script sets a variable, it will remain set, if the script exits, your session will exit. See help . for documentation.






      share|improve this answer
























        up vote
        9
        down vote










        up vote
        9
        down vote









        Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, runs the script as if you entered all its commands into the current shell - if the script sets a variable, it will remain set, if the script exits, your session will exit. See help . for documentation.






        share|improve this answer














        Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, runs the script as if you entered all its commands into the current shell - if the script sets a variable, it will remain set, if the script exits, your session will exit. See help . for documentation.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 9 at 12:45

























        answered Jul 25 '12 at 1:17









        choroba

        24.3k33967




        24.3k33967




















            up vote
            3
            down vote













            Another thing that I note is that if you have an alias like this:



            # add into .bashrc_aliases
            alias ls='ls -lht'


            With ./test.sh you'll get a normal ls output (and a different PID than current shell):



            auraham@pandora:~/iso$ ./test.sh 
            dsl-4.4.10.iso test.sh
            3136 # PID


            With . test.sh or . ./test.sh you'll get a more detailed output (and the same PID than current shell):



            auraham@pandora:~/iso$ echo $$
            2767 # shell PID

            auraham@pandora:~/iso$ . test.sh
            total 50M
            drwxrwxr-x 2 auraham auraham 4.0K Jul 30 15:41 .
            -rwxrwxr-x 1 auraham auraham 32 Jul 30 15:41 test.sh
            drwxr-xr-x 50 auraham auraham 4.0K Jul 30 15:30 ..
            -rw-rw-r-- 1 auraham auraham 50M Jul 28 17:24 dsl-4.4.10.iso
            2767 # PID





            share|improve this answer






















            • You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
              – auraham
              Aug 1 '12 at 1:17











            • Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
              – Emanuel Berg
              Aug 1 '12 at 10:26










            • totally correct, my mistake. Thanks @EmanuelBerg
              – auraham
              Aug 1 '12 at 18:40














            up vote
            3
            down vote













            Another thing that I note is that if you have an alias like this:



            # add into .bashrc_aliases
            alias ls='ls -lht'


            With ./test.sh you'll get a normal ls output (and a different PID than current shell):



            auraham@pandora:~/iso$ ./test.sh 
            dsl-4.4.10.iso test.sh
            3136 # PID


            With . test.sh or . ./test.sh you'll get a more detailed output (and the same PID than current shell):



            auraham@pandora:~/iso$ echo $$
            2767 # shell PID

            auraham@pandora:~/iso$ . test.sh
            total 50M
            drwxrwxr-x 2 auraham auraham 4.0K Jul 30 15:41 .
            -rwxrwxr-x 1 auraham auraham 32 Jul 30 15:41 test.sh
            drwxr-xr-x 50 auraham auraham 4.0K Jul 30 15:30 ..
            -rw-rw-r-- 1 auraham auraham 50M Jul 28 17:24 dsl-4.4.10.iso
            2767 # PID





            share|improve this answer






















            • You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
              – auraham
              Aug 1 '12 at 1:17











            • Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
              – Emanuel Berg
              Aug 1 '12 at 10:26










            • totally correct, my mistake. Thanks @EmanuelBerg
              – auraham
              Aug 1 '12 at 18:40












            up vote
            3
            down vote










            up vote
            3
            down vote









            Another thing that I note is that if you have an alias like this:



            # add into .bashrc_aliases
            alias ls='ls -lht'


            With ./test.sh you'll get a normal ls output (and a different PID than current shell):



            auraham@pandora:~/iso$ ./test.sh 
            dsl-4.4.10.iso test.sh
            3136 # PID


            With . test.sh or . ./test.sh you'll get a more detailed output (and the same PID than current shell):



            auraham@pandora:~/iso$ echo $$
            2767 # shell PID

            auraham@pandora:~/iso$ . test.sh
            total 50M
            drwxrwxr-x 2 auraham auraham 4.0K Jul 30 15:41 .
            -rwxrwxr-x 1 auraham auraham 32 Jul 30 15:41 test.sh
            drwxr-xr-x 50 auraham auraham 4.0K Jul 30 15:30 ..
            -rw-rw-r-- 1 auraham auraham 50M Jul 28 17:24 dsl-4.4.10.iso
            2767 # PID





            share|improve this answer














            Another thing that I note is that if you have an alias like this:



            # add into .bashrc_aliases
            alias ls='ls -lht'


            With ./test.sh you'll get a normal ls output (and a different PID than current shell):



            auraham@pandora:~/iso$ ./test.sh 
            dsl-4.4.10.iso test.sh
            3136 # PID


            With . test.sh or . ./test.sh you'll get a more detailed output (and the same PID than current shell):



            auraham@pandora:~/iso$ echo $$
            2767 # shell PID

            auraham@pandora:~/iso$ . test.sh
            total 50M
            drwxrwxr-x 2 auraham auraham 4.0K Jul 30 15:41 .
            -rwxrwxr-x 1 auraham auraham 32 Jul 30 15:41 test.sh
            drwxr-xr-x 50 auraham auraham 4.0K Jul 30 15:30 ..
            -rw-rw-r-- 1 auraham auraham 50M Jul 28 17:24 dsl-4.4.10.iso
            2767 # PID






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Aug 1 '12 at 18:39

























            answered Jul 30 '12 at 20:44









            auraham

            1313




            1313











            • You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
              – auraham
              Aug 1 '12 at 1:17











            • Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
              – Emanuel Berg
              Aug 1 '12 at 10:26










            • totally correct, my mistake. Thanks @EmanuelBerg
              – auraham
              Aug 1 '12 at 18:40
















            • You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
              – auraham
              Aug 1 '12 at 1:17











            • Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
              – Emanuel Berg
              Aug 1 '12 at 10:26










            • totally correct, my mistake. Thanks @EmanuelBerg
              – auraham
              Aug 1 '12 at 18:40















            You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
            – auraham
            Aug 1 '12 at 1:17





            You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases.
            – auraham
            Aug 1 '12 at 1:17













            Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
            – Emanuel Berg
            Aug 1 '12 at 10:26




            Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?)
            – Emanuel Berg
            Aug 1 '12 at 10:26












            totally correct, my mistake. Thanks @EmanuelBerg
            – auraham
            Aug 1 '12 at 18:40




            totally correct, my mistake. Thanks @EmanuelBerg
            – auraham
            Aug 1 '12 at 18:40










            up vote
            -1
            down vote













            The main usage to me for source (or .) is bash functions.



            I have scripts with many functions and I execute all of them with my .bashrc. The functions "become" commands, which I use often.






            share|improve this answer






















            • I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
              – Emanuel Berg
              Jul 31 '12 at 0:16














            up vote
            -1
            down vote













            The main usage to me for source (or .) is bash functions.



            I have scripts with many functions and I execute all of them with my .bashrc. The functions "become" commands, which I use often.






            share|improve this answer






















            • I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
              – Emanuel Berg
              Jul 31 '12 at 0:16












            up vote
            -1
            down vote










            up vote
            -1
            down vote









            The main usage to me for source (or .) is bash functions.



            I have scripts with many functions and I execute all of them with my .bashrc. The functions "become" commands, which I use often.






            share|improve this answer














            The main usage to me for source (or .) is bash functions.



            I have scripts with many functions and I execute all of them with my .bashrc. The functions "become" commands, which I use often.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 29 '12 at 8:40









            Mat

            37.6k7114123




            37.6k7114123










            answered Jul 25 '12 at 2:29









            Willian Paixao

            1,42711029




            1,42711029











            • I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
              – Emanuel Berg
              Jul 31 '12 at 0:16
















            • I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
              – Emanuel Berg
              Jul 31 '12 at 0:16















            I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
            – Emanuel Berg
            Jul 31 '12 at 0:16




            I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked.
            – Emanuel Berg
            Jul 31 '12 at 0:16












             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f43882%2fwhat-is-the-difference-between-sourcing-or-source-and-executing-a-file-i%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay