difference between two quite-similar Terminal commandsHow can I Open Multiple Customized Terminal Shells?Bash...

How to fill color in logic gates in Tikz?

We are very unlucky in my court

Eww, those bytes are gross

How to explain planetary rings pulsating?

How to prevent users from executing commands through browser URL

What to do when being responsible for data protection in your lab, yet advice is ignored?

Why exactly do action photographers need high fps burst cameras?

What is the most triangles you can make from a capital "H" and 3 straight lines?

Why is working on the same position for more than 15 years not a red flag?

What is a jet (unit) shown in Windows 10 calculator?

What is the lore-based reason that the Spectator has the Create Food and Water trait, instead of simply not requiring food and water?

Parsing a string of key-value pairs as a dictionary

Why does a metal block make a shrill sound but not a wooden block upon hammering?

Magento 2 : Call Helper Without Using __construct in Own Module

Book where aliens are selecting humans for food consumption

A starship is travelling at 0.9c and collides with a small rock. Will it leave a clean hole through, or will more happen?

Why Normality assumption in linear regression

Why did other German political parties disband so fast when Hitler was appointed chancellor?

Injecting creativity into a cookbook

Cryptic with missing capitals

Caruana vs Carlsen game 10 (WCC) why not 18...Nxb6?

Am I a Rude Number?

If I delete my router's history can my ISP still provide it to my parents?

What kind of hardware implements Fourier transform?



difference between two quite-similar Terminal commands


How can I Open Multiple Customized Terminal Shells?Bash Script that will start up second Terminal process?Run AppleScript from bash scriptIn iTerm, why is a command shell's command not picking up things on my $PATH?Upgraded to Yosemite, mkdir now says “permission denied”automatic save before “Run in Terminal” in BBEditMacports force-activate all portsCalling Python 3 script from AppleScriptAutomator: “Run Shell Script” throws error because of missing “on” commandMacports: switching back to the system default version of Python













3















I have a script that I run as part of my development (it's the activation script for a Python venv environment). The way the documentation suggests that we run it is by going to the folder containing our venv folder and running . venv/bin/activate. This works properly (second command in my example).



However, what I would have expected to run is ./venv/bin/activate, i.e. providing a relative path to the activate script (first command in my example). This doesn't work at all (although I am not surprised because the activate file doesn't have "execute" permissions attached to it).



My-MBP:flask-tutorial stephendewey$ ./venv/bin/activate
-bash: ./venv/bin/activate: Permission denied
My-MBP:flask-tutorial stephendewey$ . venv/bin/activate
(venv) My-MBP:flask-tutorial stephendewey$


So my question is, what is the command that works (. venv/bin/activate) actually doing? I've never seen syntax like that before.










share|improve this question



























    3















    I have a script that I run as part of my development (it's the activation script for a Python venv environment). The way the documentation suggests that we run it is by going to the folder containing our venv folder and running . venv/bin/activate. This works properly (second command in my example).



    However, what I would have expected to run is ./venv/bin/activate, i.e. providing a relative path to the activate script (first command in my example). This doesn't work at all (although I am not surprised because the activate file doesn't have "execute" permissions attached to it).



    My-MBP:flask-tutorial stephendewey$ ./venv/bin/activate
    -bash: ./venv/bin/activate: Permission denied
    My-MBP:flask-tutorial stephendewey$ . venv/bin/activate
    (venv) My-MBP:flask-tutorial stephendewey$


    So my question is, what is the command that works (. venv/bin/activate) actually doing? I've never seen syntax like that before.










    share|improve this question

























      3












      3








      3








      I have a script that I run as part of my development (it's the activation script for a Python venv environment). The way the documentation suggests that we run it is by going to the folder containing our venv folder and running . venv/bin/activate. This works properly (second command in my example).



      However, what I would have expected to run is ./venv/bin/activate, i.e. providing a relative path to the activate script (first command in my example). This doesn't work at all (although I am not surprised because the activate file doesn't have "execute" permissions attached to it).



      My-MBP:flask-tutorial stephendewey$ ./venv/bin/activate
      -bash: ./venv/bin/activate: Permission denied
      My-MBP:flask-tutorial stephendewey$ . venv/bin/activate
      (venv) My-MBP:flask-tutorial stephendewey$


      So my question is, what is the command that works (. venv/bin/activate) actually doing? I've never seen syntax like that before.










      share|improve this question














      I have a script that I run as part of my development (it's the activation script for a Python venv environment). The way the documentation suggests that we run it is by going to the folder containing our venv folder and running . venv/bin/activate. This works properly (second command in my example).



      However, what I would have expected to run is ./venv/bin/activate, i.e. providing a relative path to the activate script (first command in my example). This doesn't work at all (although I am not surprised because the activate file doesn't have "execute" permissions attached to it).



      My-MBP:flask-tutorial stephendewey$ ./venv/bin/activate
      -bash: ./venv/bin/activate: Permission denied
      My-MBP:flask-tutorial stephendewey$ . venv/bin/activate
      (venv) My-MBP:flask-tutorial stephendewey$


      So my question is, what is the command that works (. venv/bin/activate) actually doing? I've never seen syntax like that before.







      terminal command-line bash






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 1 hour ago









      StephenStephen

      287315




      287315






















          2 Answers
          2






          active

          oldest

          votes


















          3














          The . command is an alias for source so the two commands are really



          ./venv/bin/activate


          and



          source venv/bin/activate


          Also note that for the system to actually process a file it needs the absolute path ie one beginning with /



          Both files names here are relative ones ie ones that can only be understood with the knowledge of the current directory which is the variable $(CWD)



          The two file names expand to $(CWD)/./venv/bin/activate and $(CWD)/venv/bin/activate . is the current directory and so both are $(CWD)/venv/bin/activate



          The difference between running a command directly or via source is that if run directly as in the first command bash creates a new sub shell and runs the command in that and the commands in the script only affect that sub shell and when the script rends that sub shell is closed and all the changes to environment are lost. source, however, runs the command in the current shell and any changes to the environment remain after the script finishes as if the commands in the script were typed into the current shell.



          The activate script (I assume is from Python virtual environment management) works by changing the $PATH so that the correct python environment is found when you use python script.py To do this you need to alter your current $PATH and so the activate script needs to be run using source.



          Also see https://askubuntu.com/questions/182012/is-there-a-difference-between-and-source-in-bash-after-all and https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it



          Not that running a command requires the command to be executable. The command to be run is always a file and that file has to be marked as executable by the system. That is the executable flag has to be set on the file permissions which you can see by ls -l venv/bin/activate



          source however is in the current shell and just reads the file as text and then executes the commands it sees, So this file only needs to be readable. For more on that see https://unix.stackexchange.com/questions/291404/why-does-bashs-source-not-need-the-execution-bit I like this answer




          It's more of a convenience thing: Let the system run it for me directly if the the bit is set, otherwise I need to do it indirectly







          share|improve this answer


























          • Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

            – Stephen
            39 mins ago



















          3














          From man bash:



          . filename [arguments]
          source filename [arguments]
          Read and execute commands from filename in the current shell environment and
          return the exit status of the last command executed from filename. If filename
          does not contain a slash, filenames in PATH are used to find the directory
          containing filename. The file searched for in PATH need not be executable.


          So basically source runs the code within the script/file as part of the current shell environment (which is different from executing it, which runs it in a separate shell). This is mainly used to set environment variables, aliases etc to be used in the current shell.






          share|improve this answer
























          • Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

            – Stephen
            33 mins ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "118"
          };
          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',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fapple.stackexchange.com%2fquestions%2f352774%2fdifference-between-two-quite-similar-terminal-commands%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          The . command is an alias for source so the two commands are really



          ./venv/bin/activate


          and



          source venv/bin/activate


          Also note that for the system to actually process a file it needs the absolute path ie one beginning with /



          Both files names here are relative ones ie ones that can only be understood with the knowledge of the current directory which is the variable $(CWD)



          The two file names expand to $(CWD)/./venv/bin/activate and $(CWD)/venv/bin/activate . is the current directory and so both are $(CWD)/venv/bin/activate



          The difference between running a command directly or via source is that if run directly as in the first command bash creates a new sub shell and runs the command in that and the commands in the script only affect that sub shell and when the script rends that sub shell is closed and all the changes to environment are lost. source, however, runs the command in the current shell and any changes to the environment remain after the script finishes as if the commands in the script were typed into the current shell.



          The activate script (I assume is from Python virtual environment management) works by changing the $PATH so that the correct python environment is found when you use python script.py To do this you need to alter your current $PATH and so the activate script needs to be run using source.



          Also see https://askubuntu.com/questions/182012/is-there-a-difference-between-and-source-in-bash-after-all and https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it



          Not that running a command requires the command to be executable. The command to be run is always a file and that file has to be marked as executable by the system. That is the executable flag has to be set on the file permissions which you can see by ls -l venv/bin/activate



          source however is in the current shell and just reads the file as text and then executes the commands it sees, So this file only needs to be readable. For more on that see https://unix.stackexchange.com/questions/291404/why-does-bashs-source-not-need-the-execution-bit I like this answer




          It's more of a convenience thing: Let the system run it for me directly if the the bit is set, otherwise I need to do it indirectly







          share|improve this answer


























          • Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

            – Stephen
            39 mins ago
















          3














          The . command is an alias for source so the two commands are really



          ./venv/bin/activate


          and



          source venv/bin/activate


          Also note that for the system to actually process a file it needs the absolute path ie one beginning with /



          Both files names here are relative ones ie ones that can only be understood with the knowledge of the current directory which is the variable $(CWD)



          The two file names expand to $(CWD)/./venv/bin/activate and $(CWD)/venv/bin/activate . is the current directory and so both are $(CWD)/venv/bin/activate



          The difference between running a command directly or via source is that if run directly as in the first command bash creates a new sub shell and runs the command in that and the commands in the script only affect that sub shell and when the script rends that sub shell is closed and all the changes to environment are lost. source, however, runs the command in the current shell and any changes to the environment remain after the script finishes as if the commands in the script were typed into the current shell.



          The activate script (I assume is from Python virtual environment management) works by changing the $PATH so that the correct python environment is found when you use python script.py To do this you need to alter your current $PATH and so the activate script needs to be run using source.



          Also see https://askubuntu.com/questions/182012/is-there-a-difference-between-and-source-in-bash-after-all and https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it



          Not that running a command requires the command to be executable. The command to be run is always a file and that file has to be marked as executable by the system. That is the executable flag has to be set on the file permissions which you can see by ls -l venv/bin/activate



          source however is in the current shell and just reads the file as text and then executes the commands it sees, So this file only needs to be readable. For more on that see https://unix.stackexchange.com/questions/291404/why-does-bashs-source-not-need-the-execution-bit I like this answer




          It's more of a convenience thing: Let the system run it for me directly if the the bit is set, otherwise I need to do it indirectly







          share|improve this answer


























          • Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

            – Stephen
            39 mins ago














          3












          3








          3







          The . command is an alias for source so the two commands are really



          ./venv/bin/activate


          and



          source venv/bin/activate


          Also note that for the system to actually process a file it needs the absolute path ie one beginning with /



          Both files names here are relative ones ie ones that can only be understood with the knowledge of the current directory which is the variable $(CWD)



          The two file names expand to $(CWD)/./venv/bin/activate and $(CWD)/venv/bin/activate . is the current directory and so both are $(CWD)/venv/bin/activate



          The difference between running a command directly or via source is that if run directly as in the first command bash creates a new sub shell and runs the command in that and the commands in the script only affect that sub shell and when the script rends that sub shell is closed and all the changes to environment are lost. source, however, runs the command in the current shell and any changes to the environment remain after the script finishes as if the commands in the script were typed into the current shell.



          The activate script (I assume is from Python virtual environment management) works by changing the $PATH so that the correct python environment is found when you use python script.py To do this you need to alter your current $PATH and so the activate script needs to be run using source.



          Also see https://askubuntu.com/questions/182012/is-there-a-difference-between-and-source-in-bash-after-all and https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it



          Not that running a command requires the command to be executable. The command to be run is always a file and that file has to be marked as executable by the system. That is the executable flag has to be set on the file permissions which you can see by ls -l venv/bin/activate



          source however is in the current shell and just reads the file as text and then executes the commands it sees, So this file only needs to be readable. For more on that see https://unix.stackexchange.com/questions/291404/why-does-bashs-source-not-need-the-execution-bit I like this answer




          It's more of a convenience thing: Let the system run it for me directly if the the bit is set, otherwise I need to do it indirectly







          share|improve this answer















          The . command is an alias for source so the two commands are really



          ./venv/bin/activate


          and



          source venv/bin/activate


          Also note that for the system to actually process a file it needs the absolute path ie one beginning with /



          Both files names here are relative ones ie ones that can only be understood with the knowledge of the current directory which is the variable $(CWD)



          The two file names expand to $(CWD)/./venv/bin/activate and $(CWD)/venv/bin/activate . is the current directory and so both are $(CWD)/venv/bin/activate



          The difference between running a command directly or via source is that if run directly as in the first command bash creates a new sub shell and runs the command in that and the commands in the script only affect that sub shell and when the script rends that sub shell is closed and all the changes to environment are lost. source, however, runs the command in the current shell and any changes to the environment remain after the script finishes as if the commands in the script were typed into the current shell.



          The activate script (I assume is from Python virtual environment management) works by changing the $PATH so that the correct python environment is found when you use python script.py To do this you need to alter your current $PATH and so the activate script needs to be run using source.



          Also see https://askubuntu.com/questions/182012/is-there-a-difference-between-and-source-in-bash-after-all and https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it



          Not that running a command requires the command to be executable. The command to be run is always a file and that file has to be marked as executable by the system. That is the executable flag has to be set on the file permissions which you can see by ls -l venv/bin/activate



          source however is in the current shell and just reads the file as text and then executes the commands it sees, So this file only needs to be readable. For more on that see https://unix.stackexchange.com/questions/291404/why-does-bashs-source-not-need-the-execution-bit I like this answer




          It's more of a convenience thing: Let the system run it for me directly if the the bit is set, otherwise I need to do it indirectly








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 3 mins ago

























          answered 54 mins ago









          MarkMark

          19.8k115795




          19.8k115795













          • Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

            – Stephen
            39 mins ago



















          • Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

            – Stephen
            39 mins ago

















          Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

          – Stephen
          39 mins ago





          Thanks, this answers almost all my questions. But why would the "direct command" run into a permissions issue while the "source command" doesn't?

          – Stephen
          39 mins ago













          3














          From man bash:



          . filename [arguments]
          source filename [arguments]
          Read and execute commands from filename in the current shell environment and
          return the exit status of the last command executed from filename. If filename
          does not contain a slash, filenames in PATH are used to find the directory
          containing filename. The file searched for in PATH need not be executable.


          So basically source runs the code within the script/file as part of the current shell environment (which is different from executing it, which runs it in a separate shell). This is mainly used to set environment variables, aliases etc to be used in the current shell.






          share|improve this answer
























          • Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

            – Stephen
            33 mins ago
















          3














          From man bash:



          . filename [arguments]
          source filename [arguments]
          Read and execute commands from filename in the current shell environment and
          return the exit status of the last command executed from filename. If filename
          does not contain a slash, filenames in PATH are used to find the directory
          containing filename. The file searched for in PATH need not be executable.


          So basically source runs the code within the script/file as part of the current shell environment (which is different from executing it, which runs it in a separate shell). This is mainly used to set environment variables, aliases etc to be used in the current shell.






          share|improve this answer
























          • Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

            – Stephen
            33 mins ago














          3












          3








          3







          From man bash:



          . filename [arguments]
          source filename [arguments]
          Read and execute commands from filename in the current shell environment and
          return the exit status of the last command executed from filename. If filename
          does not contain a slash, filenames in PATH are used to find the directory
          containing filename. The file searched for in PATH need not be executable.


          So basically source runs the code within the script/file as part of the current shell environment (which is different from executing it, which runs it in a separate shell). This is mainly used to set environment variables, aliases etc to be used in the current shell.






          share|improve this answer













          From man bash:



          . filename [arguments]
          source filename [arguments]
          Read and execute commands from filename in the current shell environment and
          return the exit status of the last command executed from filename. If filename
          does not contain a slash, filenames in PATH are used to find the directory
          containing filename. The file searched for in PATH need not be executable.


          So basically source runs the code within the script/file as part of the current shell environment (which is different from executing it, which runs it in a separate shell). This is mainly used to set environment variables, aliases etc to be used in the current shell.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 1 hour ago









          nohillsidenohillside

          52.3k13111154




          52.3k13111154













          • Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

            – Stephen
            33 mins ago



















          • Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

            – Stephen
            33 mins ago

















          Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

          – Stephen
          33 mins ago





          Thanks, I think the last part of the bash manual entry answers the part of my question about permissions: source doesn't even require something to be executable.

          – Stephen
          33 mins ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Ask Different!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fapple.stackexchange.com%2fquestions%2f352774%2fdifference-between-two-quite-similar-terminal-commands%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Benedict Cumberbatch Contingut Inicis Debut professional Premis Filmografia bàsica Premis i...

          Monticle de plataforma Contingut Est de Nord Amèrica Interpretacions Altres cultures Vegeu...

          Escacs Janus Enllaços externs Menú de navegacióEscacs JanusJanusschachBrainKing.comChessV