sudo: source: command not found
I've been updating some of the default profile for bash, and saw from the tutorials I was following that I could reload the new profile with the new environment settings by using:
source /etc/bash.bashrc
The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo. They only became available to sudo when I closed my terminal session and rejoined.
When I try to use:
sudo source /etc/bash.bashrc
I get the error:
sudo: source: command not found
Is there a simple way to load in the new bash profile settings for sudo without having to close the terminal and restart?
--
Initially, I was using some installer scripts which referenced the variables. I found that while they could access the variables when I called the scripts directly (although, this would cause a later problem with creating directories as I needed to be root), calling the install scripts using sudo wouldn't.
I proved this by testing with these simple commands:
echo $ENV_VARIABLE
sudo echo $ENV_VARIABLE
The first would output the variable's value, but the second wouldn't output anything.
command-line bash sudo
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
add a comment |
I've been updating some of the default profile for bash, and saw from the tutorials I was following that I could reload the new profile with the new environment settings by using:
source /etc/bash.bashrc
The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo. They only became available to sudo when I closed my terminal session and rejoined.
When I try to use:
sudo source /etc/bash.bashrc
I get the error:
sudo: source: command not found
Is there a simple way to load in the new bash profile settings for sudo without having to close the terminal and restart?
--
Initially, I was using some installer scripts which referenced the variables. I found that while they could access the variables when I called the scripts directly (although, this would cause a later problem with creating directories as I needed to be root), calling the install scripts using sudo wouldn't.
I proved this by testing with these simple commands:
echo $ENV_VARIABLE
sudo echo $ENV_VARIABLE
The first would output the variable's value, but the second wouldn't output anything.
command-line bash sudo
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
How did you try to use the variables from sudo ? Please note that if you use "sudo command $variable" it will replace the variable from your shell, not from sudo's environment.
– João Pinto
Jan 10 '11 at 22:57
add a comment |
I've been updating some of the default profile for bash, and saw from the tutorials I was following that I could reload the new profile with the new environment settings by using:
source /etc/bash.bashrc
The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo. They only became available to sudo when I closed my terminal session and rejoined.
When I try to use:
sudo source /etc/bash.bashrc
I get the error:
sudo: source: command not found
Is there a simple way to load in the new bash profile settings for sudo without having to close the terminal and restart?
--
Initially, I was using some installer scripts which referenced the variables. I found that while they could access the variables when I called the scripts directly (although, this would cause a later problem with creating directories as I needed to be root), calling the install scripts using sudo wouldn't.
I proved this by testing with these simple commands:
echo $ENV_VARIABLE
sudo echo $ENV_VARIABLE
The first would output the variable's value, but the second wouldn't output anything.
command-line bash sudo
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
I've been updating some of the default profile for bash, and saw from the tutorials I was following that I could reload the new profile with the new environment settings by using:
source /etc/bash.bashrc
The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo. They only became available to sudo when I closed my terminal session and rejoined.
When I try to use:
sudo source /etc/bash.bashrc
I get the error:
sudo: source: command not found
Is there a simple way to load in the new bash profile settings for sudo without having to close the terminal and restart?
--
Initially, I was using some installer scripts which referenced the variables. I found that while they could access the variables when I called the scripts directly (although, this would cause a later problem with creating directories as I needed to be root), calling the install scripts using sudo wouldn't.
I proved this by testing with these simple commands:
echo $ENV_VARIABLE
sudo echo $ENV_VARIABLE
The first would output the variable's value, but the second wouldn't output anything.
command-line bash sudo
command-line bash sudo
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
edited Nov 18 '13 at 20:37
Braiam
52.2k20137222
52.2k20137222
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
asked Jan 10 '11 at 22:25
HorusKolHorusKol
4972829
4972829
How did you try to use the variables from sudo ? Please note that if you use "sudo command $variable" it will replace the variable from your shell, not from sudo's environment.
– João Pinto
Jan 10 '11 at 22:57
add a comment |
How did you try to use the variables from sudo ? Please note that if you use "sudo command $variable" it will replace the variable from your shell, not from sudo's environment.
– João Pinto
Jan 10 '11 at 22:57
How did you try to use the variables from sudo ? Please note that if you use "sudo command $variable" it will replace the variable from your shell, not from sudo's environment.
– João Pinto
Jan 10 '11 at 22:57
How did you try to use the variables from sudo ? Please note that if you use "sudo command $variable" it will replace the variable from your shell, not from sudo's environment.
– João Pinto
Jan 10 '11 at 22:57
add a comment |
6 Answers
6
active
oldest
votes
The problem is that source is a bash build-in command (not a program - like ls or grep). I think one approach is to login as root and then execute the source command.
sudo -s
source /etc/bash.bashrc
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
3
You're right that the problem is thatsourceis a shell builtin.sudo suis a kind of weird way to say it -- better to just saysudo -swhich is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.
– poolie
Jan 10 '11 at 22:58
1
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
The "one line" example won't work becausesustarts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.
– loevborg
Jan 11 '11 at 9:41
sudo -sis no better thansudo su. It won't have any effect either way.
– loevborg
Jan 11 '11 at 13:58
1
sudo -shas a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.
– poolie
Jan 12 '11 at 2:18
add a comment |
The problem is not that source is a shell builtin command. The fact that it is is what's actually throwing you the command not found error, but it doesn't mean it would work if it were.
The actual problem is how environment variables work. And they work like this:
every time a new process is started, if nothing happens, it inherits the environment of its parent. Due to this, using a subshell (e.g. typing bash inside a bash instance) and looking at the output of env should give similar results than its parent.
However, due to how sudo works (as stated in its manpage), sudo tries to strip the environment of the user and create a "default" environment for the supplanting user, so that the command run is run as if the user who invoked it had been the calling user (which is the expected behaviour), and thus running nautilus as sudo nautilus should open a folder at the /root folder, and not /home/yourusername.
So:
Doing something like sudo source script.sh and then sudo command, even if it worked, it wouldn't be successful at setting any variable to the later sudo command.
In order to pass environment variables, you can either tell sudo to preserve the environment (via the -E switch; and having appropriate permissions in your sudoers file) and/or setting it for the command as sudo VAR1=VALUE1 VAR2=VALUE2 command.
answered Nov 18 '13 at 19:28
ssicessice
789712
add a comment |
As Marcos says, your main problem here is that source is a shell builtin command that affects only the shell process in which it's run.
The easy solution is to just start a new shell as root, and bash will automatically read /etc/bash.bashrc when it starts. That's as simple as just saying
sudo bash
edited Apr 13 '17 at 12:23
Community♦
1
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
add a comment |
Closing and reopening the terminal should not change things. By default, sudo strips the environment. To disable that, add -E to sudo.
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
add a comment |
Using bash process substitution you can do:
source <(sudo cat /etc/bash.bashrc)
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
1
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to usesudoto access the profile. The above provides a means to import the profile whilst avoiding thesudo: source: command not foundissue mentioned.
– TomDotTom
Aug 3 '18 at 14:25
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
add a comment |
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ng
/home/user/work/bin/bettercap`
I checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
sudo -E env "PATH=$PATH" [command] [arguments]
In fact, one can make an alias out of it:
alias mysudo='sudo -E env "PATH=$PATH"'
It's also possible to name the alias itself sudo, replacing the original sudo.
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f20953%2fsudo-source-command-not-found%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
The problem is that source is a bash build-in command (not a program - like ls or grep). I think one approach is to login as root and then execute the source command.
sudo -s
source /etc/bash.bashrc
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
3
You're right that the problem is thatsourceis a shell builtin.sudo suis a kind of weird way to say it -- better to just saysudo -swhich is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.
– poolie
Jan 10 '11 at 22:58
1
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
The "one line" example won't work becausesustarts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.
– loevborg
Jan 11 '11 at 9:41
sudo -sis no better thansudo su. It won't have any effect either way.
– loevborg
Jan 11 '11 at 13:58
1
sudo -shas a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.
– poolie
Jan 12 '11 at 2:18
add a comment |
The problem is that source is a bash build-in command (not a program - like ls or grep). I think one approach is to login as root and then execute the source command.
sudo -s
source /etc/bash.bashrc
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
3
You're right that the problem is thatsourceis a shell builtin.sudo suis a kind of weird way to say it -- better to just saysudo -swhich is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.
– poolie
Jan 10 '11 at 22:58
1
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
The "one line" example won't work becausesustarts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.
– loevborg
Jan 11 '11 at 9:41
sudo -sis no better thansudo su. It won't have any effect either way.
– loevborg
Jan 11 '11 at 13:58
1
sudo -shas a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.
– poolie
Jan 12 '11 at 2:18
add a comment |
The problem is that source is a bash build-in command (not a program - like ls or grep). I think one approach is to login as root and then execute the source command.
sudo -s
source /etc/bash.bashrc
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
The problem is that source is a bash build-in command (not a program - like ls or grep). I think one approach is to login as root and then execute the source command.
sudo -s
source /etc/bash.bashrc
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
edited Jan 11 '11 at 16:37
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
answered Jan 10 '11 at 22:31
Marcos Roriz JuniorMarcos Roriz Junior
3,07432241
3,07432241
3
You're right that the problem is thatsourceis a shell builtin.sudo suis a kind of weird way to say it -- better to just saysudo -swhich is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.
– poolie
Jan 10 '11 at 22:58
1
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
The "one line" example won't work becausesustarts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.
– loevborg
Jan 11 '11 at 9:41
sudo -sis no better thansudo su. It won't have any effect either way.
– loevborg
Jan 11 '11 at 13:58
1
sudo -shas a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.
– poolie
Jan 12 '11 at 2:18
add a comment |
3
You're right that the problem is thatsourceis a shell builtin.sudo suis a kind of weird way to say it -- better to just saysudo -swhich is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.
– poolie
Jan 10 '11 at 22:58
1
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
The "one line" example won't work becausesustarts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.
– loevborg
Jan 11 '11 at 9:41
sudo -sis no better thansudo su. It won't have any effect either way.
– loevborg
Jan 11 '11 at 13:58
1
sudo -shas a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.
– poolie
Jan 12 '11 at 2:18
3
3
You're right that the problem is that
source is a shell builtin. sudo su is a kind of weird way to say it -- better to just say sudo -s which is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.– poolie
Jan 10 '11 at 22:58
You're right that the problem is that
source is a shell builtin. sudo su is a kind of weird way to say it -- better to just say sudo -s which is sudo's own way of saying "start a shell as this user." Your one-line version won't work because each of the commands in it is run by the main user's shell in a separate subprocess.– poolie
Jan 10 '11 at 22:58
1
1
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
Right. Plus BASH reads /etc/bashrc at login time. So you may as well use 'su' with -, -l, or --login switch in order to get the environment of that user: 'sudo su -' to become root or 'su - $username' to become another user.
– user8290
Jan 10 '11 at 23:21
The "one line" example won't work because
su starts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.– loevborg
Jan 11 '11 at 9:41
The "one line" example won't work because
su starts a new shell and "source" is run only after it terminates. The first example only works if the second line used inside the root shell.– loevborg
Jan 11 '11 at 9:41
sudo -s is no better than sudo su. It won't have any effect either way.– loevborg
Jan 11 '11 at 13:58
sudo -s is no better than sudo su. It won't have any effect either way.– loevborg
Jan 11 '11 at 13:58
1
1
sudo -s has a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.– poolie
Jan 12 '11 at 2:18
sudo -s has a similar effect of starting a shell, but to me it seems inelegant to stack two "become another user" commands when one would do.– poolie
Jan 12 '11 at 2:18
add a comment |
The problem is not that source is a shell builtin command. The fact that it is is what's actually throwing you the command not found error, but it doesn't mean it would work if it were.
The actual problem is how environment variables work. And they work like this:
every time a new process is started, if nothing happens, it inherits the environment of its parent. Due to this, using a subshell (e.g. typing bash inside a bash instance) and looking at the output of env should give similar results than its parent.
However, due to how sudo works (as stated in its manpage), sudo tries to strip the environment of the user and create a "default" environment for the supplanting user, so that the command run is run as if the user who invoked it had been the calling user (which is the expected behaviour), and thus running nautilus as sudo nautilus should open a folder at the /root folder, and not /home/yourusername.
So:
Doing something like sudo source script.sh and then sudo command, even if it worked, it wouldn't be successful at setting any variable to the later sudo command.
In order to pass environment variables, you can either tell sudo to preserve the environment (via the -E switch; and having appropriate permissions in your sudoers file) and/or setting it for the command as sudo VAR1=VALUE1 VAR2=VALUE2 command.
answered Nov 18 '13 at 19:28
ssicessice
789712
add a comment |
The problem is not that source is a shell builtin command. The fact that it is is what's actually throwing you the command not found error, but it doesn't mean it would work if it were.
The actual problem is how environment variables work. And they work like this:
every time a new process is started, if nothing happens, it inherits the environment of its parent. Due to this, using a subshell (e.g. typing bash inside a bash instance) and looking at the output of env should give similar results than its parent.
However, due to how sudo works (as stated in its manpage), sudo tries to strip the environment of the user and create a "default" environment for the supplanting user, so that the command run is run as if the user who invoked it had been the calling user (which is the expected behaviour), and thus running nautilus as sudo nautilus should open a folder at the /root folder, and not /home/yourusername.
So:
Doing something like sudo source script.sh and then sudo command, even if it worked, it wouldn't be successful at setting any variable to the later sudo command.
In order to pass environment variables, you can either tell sudo to preserve the environment (via the -E switch; and having appropriate permissions in your sudoers file) and/or setting it for the command as sudo VAR1=VALUE1 VAR2=VALUE2 command.
answered Nov 18 '13 at 19:28
ssicessice
789712
add a comment |
The problem is not that source is a shell builtin command. The fact that it is is what's actually throwing you the command not found error, but it doesn't mean it would work if it were.
The actual problem is how environment variables work. And they work like this:
every time a new process is started, if nothing happens, it inherits the environment of its parent. Due to this, using a subshell (e.g. typing bash inside a bash instance) and looking at the output of env should give similar results than its parent.
However, due to how sudo works (as stated in its manpage), sudo tries to strip the environment of the user and create a "default" environment for the supplanting user, so that the command run is run as if the user who invoked it had been the calling user (which is the expected behaviour), and thus running nautilus as sudo nautilus should open a folder at the /root folder, and not /home/yourusername.
So:
Doing something like sudo source script.sh and then sudo command, even if it worked, it wouldn't be successful at setting any variable to the later sudo command.
In order to pass environment variables, you can either tell sudo to preserve the environment (via the -E switch; and having appropriate permissions in your sudoers file) and/or setting it for the command as sudo VAR1=VALUE1 VAR2=VALUE2 command.
answered Nov 18 '13 at 19:28
ssicessice
789712
The problem is not that source is a shell builtin command. The fact that it is is what's actually throwing you the command not found error, but it doesn't mean it would work if it were.
The actual problem is how environment variables work. And they work like this:
every time a new process is started, if nothing happens, it inherits the environment of its parent. Due to this, using a subshell (e.g. typing bash inside a bash instance) and looking at the output of env should give similar results than its parent.
However, due to how sudo works (as stated in its manpage), sudo tries to strip the environment of the user and create a "default" environment for the supplanting user, so that the command run is run as if the user who invoked it had been the calling user (which is the expected behaviour), and thus running nautilus as sudo nautilus should open a folder at the /root folder, and not /home/yourusername.
So:
Doing something like sudo source script.sh and then sudo command, even if it worked, it wouldn't be successful at setting any variable to the later sudo command.
In order to pass environment variables, you can either tell sudo to preserve the environment (via the -E switch; and having appropriate permissions in your sudoers file) and/or setting it for the command as sudo VAR1=VALUE1 VAR2=VALUE2 command.
answered Nov 18 '13 at 19:28
ssicessice
789712
answered Nov 18 '13 at 19:28
ssicessice
789712
answered Nov 18 '13 at 19:28
ssicessice
789712
answered Nov 18 '13 at 19:28
ssicessice
789712
789712
add a comment |
add a comment |
As Marcos says, your main problem here is that source is a shell builtin command that affects only the shell process in which it's run.
The easy solution is to just start a new shell as root, and bash will automatically read /etc/bash.bashrc when it starts. That's as simple as just saying
sudo bash
edited Apr 13 '17 at 12:23
Community♦
1
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
add a comment |
As Marcos says, your main problem here is that source is a shell builtin command that affects only the shell process in which it's run.
The easy solution is to just start a new shell as root, and bash will automatically read /etc/bash.bashrc when it starts. That's as simple as just saying
sudo bash
edited Apr 13 '17 at 12:23
Community♦
1
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
add a comment |
As Marcos says, your main problem here is that source is a shell builtin command that affects only the shell process in which it's run.
The easy solution is to just start a new shell as root, and bash will automatically read /etc/bash.bashrc when it starts. That's as simple as just saying
sudo bash
edited Apr 13 '17 at 12:23
Community♦
1
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
As Marcos says, your main problem here is that source is a shell builtin command that affects only the shell process in which it's run.
The easy solution is to just start a new shell as root, and bash will automatically read /etc/bash.bashrc when it starts. That's as simple as just saying
sudo bash
edited Apr 13 '17 at 12:23
Community♦
1
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
edited Apr 13 '17 at 12:23
Community♦
1
edited Apr 13 '17 at 12:23
Community♦
1
edited Apr 13 '17 at 12:23
Community♦
1
1
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
answered Jan 10 '11 at 23:03
pooliepoolie
7,30823158
7,30823158
add a comment |
add a comment |
Closing and reopening the terminal should not change things. By default, sudo strips the environment. To disable that, add -E to sudo.
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
add a comment |
Closing and reopening the terminal should not change things. By default, sudo strips the environment. To disable that, add -E to sudo.
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
add a comment |
Closing and reopening the terminal should not change things. By default, sudo strips the environment. To disable that, add -E to sudo.
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
Closing and reopening the terminal should not change things. By default, sudo strips the environment. To disable that, add -E to sudo.
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
answered Jan 11 '11 at 2:55
psusipsusi
31.3k15090
31.3k15090
add a comment |
add a comment |
Using bash process substitution you can do:
source <(sudo cat /etc/bash.bashrc)
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
1
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to usesudoto access the profile. The above provides a means to import the profile whilst avoiding thesudo: source: command not foundissue mentioned.
– TomDotTom
Aug 3 '18 at 14:25
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
add a comment |
Using bash process substitution you can do:
source <(sudo cat /etc/bash.bashrc)
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
1
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to usesudoto access the profile. The above provides a means to import the profile whilst avoiding thesudo: source: command not foundissue mentioned.
– TomDotTom
Aug 3 '18 at 14:25
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
add a comment |
Using bash process substitution you can do:
source <(sudo cat /etc/bash.bashrc)
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
Using bash process substitution you can do:
source <(sudo cat /etc/bash.bashrc)
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
answered Jul 30 '18 at 16:32
TomDotTomTomDotTom
1192
1192
1
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to usesudoto access the profile. The above provides a means to import the profile whilst avoiding thesudo: source: command not foundissue mentioned.
– TomDotTom
Aug 3 '18 at 14:25
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
add a comment |
1
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to usesudoto access the profile. The above provides a means to import the profile whilst avoiding thesudo: source: command not foundissue mentioned.
– TomDotTom
Aug 3 '18 at 14:25
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
1
1
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
How would this help starting a root shell with the new settings, which is what OP is looking to do?
– muru
Jul 30 '18 at 17:38
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to use
sudo to access the profile. The above provides a means to import the profile whilst avoiding the sudo: source: command not found issue mentioned.– TomDotTom
Aug 3 '18 at 14:25
The OP was actually asking how to "... reload the new profile ..." from a shell which needs to use
sudo to access the profile. The above provides a means to import the profile whilst avoiding the sudo: source: command not found issue mentioned.– TomDotTom
Aug 3 '18 at 14:25
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
"The only thing is - the new environment variables were only available to my current user - and were ignored when I used sudo."
– muru
Aug 3 '18 at 14:55
add a comment |
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ng
/home/user/work/bin/bettercap`
I checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
sudo -E env "PATH=$PATH" [command] [arguments]
In fact, one can make an alias out of it:
alias mysudo='sudo -E env "PATH=$PATH"'
It's also possible to name the alias itself sudo, replacing the original sudo.
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
add a comment |
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ng
/home/user/work/bin/bettercap`
I checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
sudo -E env "PATH=$PATH" [command] [arguments]
In fact, one can make an alias out of it:
alias mysudo='sudo -E env "PATH=$PATH"'
It's also possible to name the alias itself sudo, replacing the original sudo.
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
add a comment |
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ng
/home/user/work/bin/bettercap`
I checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
sudo -E env "PATH=$PATH" [command] [arguments]
In fact, one can make an alias out of it:
alias mysudo='sudo -E env "PATH=$PATH"'
It's also possible to name the alias itself sudo, replacing the original sudo.
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ng
/home/user/work/bin/bettercap`
I checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
sudo -E env "PATH=$PATH" [command] [arguments]
In fact, one can make an alias out of it:
alias mysudo='sudo -E env "PATH=$PATH"'
It's also possible to name the alias itself sudo, replacing the original sudo.
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
edited Jan 28 at 1:03
Thomas Ward♦
44.7k23124177
44.7k23124177
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
answered Mar 8 '18 at 9:49
Anonymous PlatypusAnonymous Platypus
1,37761839
1,37761839
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f20953%2fsudo-source-command-not-found%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
How did you try to use the variables from sudo ? Please note that if you use "sudo command $variable" it will replace the variable from your shell, not from sudo's environment.
– João Pinto
Jan 10 '11 at 22:57