Difference between two quite-similar Terminal commands












5















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 normally have 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$


What is the command that works (. venv/bin/activate) actually doing? I've never seen syntax like that before.










share|improve this question

























  • Note to editors. The author is dealing with a script that is used in python development. But the question and definitely the answers are not python specific

    – Mark
    6 hours ago
















5















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 normally have 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$


What is the command that works (. venv/bin/activate) actually doing? I've never seen syntax like that before.










share|improve this question

























  • Note to editors. The author is dealing with a script that is used in python development. But the question and definitely the answers are not python specific

    – Mark
    6 hours ago














5












5








5








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 normally have 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$


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 normally have 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$


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








edited 5 hours ago







Stephen

















asked 9 hours ago









StephenStephen

297316




297316













  • Note to editors. The author is dealing with a script that is used in python development. But the question and definitely the answers are not python specific

    – Mark
    6 hours ago



















  • Note to editors. The author is dealing with a script that is used in python development. But the question and definitely the answers are not python specific

    – Mark
    6 hours ago

















Note to editors. The author is dealing with a script that is used in python development. But the question and definitely the answers are not python specific

– Mark
6 hours ago





Note to editors. The author is dealing with a script that is used in python development. But the question and definitely the answers are not python specific

– Mark
6 hours ago










2 Answers
2






active

oldest

votes


















5














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





















  • 1





    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
    8 hours ago











  • @Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

    – bmike
    7 hours ago













  • Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

    – Stephen
    7 hours ago











  • Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

    – Kevin Johnson
    1 hour ago



















5














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
    8 hours 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









5














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





















  • 1





    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
    8 hours ago











  • @Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

    – bmike
    7 hours ago













  • Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

    – Stephen
    7 hours ago











  • Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

    – Kevin Johnson
    1 hour ago
















5














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





















  • 1





    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
    8 hours ago











  • @Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

    – bmike
    7 hours ago













  • Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

    – Stephen
    7 hours ago











  • Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

    – Kevin Johnson
    1 hour ago














5












5








5







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 8 hours ago

























answered 9 hours ago









MarkMark

19.9k115795




19.9k115795








  • 1





    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
    8 hours ago











  • @Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

    – bmike
    7 hours ago













  • Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

    – Stephen
    7 hours ago











  • Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

    – Kevin Johnson
    1 hour ago














  • 1





    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
    8 hours ago











  • @Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

    – bmike
    7 hours ago













  • Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

    – Stephen
    7 hours ago











  • Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

    – Kevin Johnson
    1 hour ago








1




1





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
8 hours 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
8 hours ago













@Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

– bmike
7 hours ago







@Stephen When you do a long listing, does the file lack the execute permission? ls -l venv/bin/activate portion of the answer? That would explain the permission error when you try to execute the file directly as opposed to letting the shell read the file for contents. Unix permissions come from a model established quite a while back, so they sometimes are confusing why you could read a file as opposed to execute it as a "binary" or "app" +1 to the asker and answerer here - great question that lets Mark explain why it happens as well as what to do.

– bmike
7 hours ago















Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

– Stephen
7 hours ago





Thanks all, I think the edit to the answer answers my remaining question (the execute bit was indeed turned off, but I don't need to change that since I can just source it).

– Stephen
7 hours ago













Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

– Kevin Johnson
1 hour ago





Important to note that running an executable and source-ing it are more different than that. Running the executable calls the system's exec function, whereas calling source on a file will read the file and run the lines of the file similar to if they were directly typed into the terminal. This is why you can run a binary program, but you can't source it. (eg. source /bin/ls vs /bin/ls)

– Kevin Johnson
1 hour ago













5














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
    8 hours ago
















5














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
    8 hours ago














5












5








5







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 9 hours 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
    8 hours 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
    8 hours 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
8 hours 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
8 hours 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

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]