Home/ Questions/Q 9714
Next
In Process

askthedev.com Latest Questions

Asked: 2024-09-26T00:44:11+05:30 In:

How can I resolve the issue of getting a ‘command not found’ error when trying to use the source command with sudo in Ubuntu?

I’ve been wrestling with this frustrating issue in Ubuntu, and I’m hoping someone here can help me out. So, I’m trying to use the `source` command with `sudo`, but I keep getting this annoying ‘command not found’ error. It’s driving me a bit crazy!

Here’s the situation: I’ve got a script that sets up some environment variables and other config settings, and I want to run it with elevated privileges. I naturally thought using `sudo` was the way to go, but anytime I try something like `sudo source myscript.sh`, I get that dreaded error. I did some digging and found out that `source` is actually a shell built-in command, and `sudo` doesn’t exactly play nice with it.

I’ve read a bunch of forums and articles, and some folks are saying that instead of `source`, I should use the `.` (dot) command, like this: `sudo . myscript.sh`. But honestly, that just feels a bit weird to me. Is that even the right way to go?

I also thought about running the script without `sudo`, but then the environment variables won’t be applied with the right permissions. I get that I can modify the script itself to include `sudo` for specific commands inside it, but that seems a bit cumbersome. And honestly, I feel like there’s got to be a cleaner way to do this!

Has anyone else run into this issue? How did you get around it? What’s the best practice here? Would love to hear any tips or tricks you guys might have! I really don’t want to keep getting stuck every time I try to run this script with `sudo`. Thanks a ton for any help you can provide!

Share

    Leave an answer

    You must login to add an answer.

    Need An Account,

    2 Answers



    1. Ubuntu Sudo Source Command Issue

      Frustrations with `sudo source` Command

      Totally get your pain! So, here’s the deal with `source` and `sudo`:

      When you run something like sudo source myscript.sh, you’ll hit that “command not found” wall because `source` is built into the shell. It’s not a standalone program that `sudo` can run. That’s why it’s being all grumpy about it!

      Now, using just the dot command (like sudo . myscript.sh) isn’t quite right. The dot command loads the script in the current shell, but it doesn’t work with `sudo` because you need `sudo` to elevate permissions for the command itself, not just for sourcing your script.

      If you want to run your script and set those environment variables, usually, the best way is to modify the script a bit. You should put sudo in front of the individual commands in your script that need elevated privileges. I know it feels a bit clunky, but it’s generally how it goes.

      Alternatively, you could try running your script as normal and then using sudo for specific commands within it. But if you really need the whole script to run with those elevated permissions, another way is to run a shell with sudo and then run the script:

      sudo bash myscript.sh

      This way, the whole script runs with elevated permissions, and you’ll get all the environment variables set without the weirdness of `source`.

      Hope that helps clear things up a bit! It took me a while to wrap my head around this too, so you’re not alone!




    2. Ubuntu Sourcing Script with Sudo Issue

      You’re correct that the issue arises because `source` is a shell built-in and not a standalone executable, which is why `sudo` can’t find it. You can solve this by executing a new shell that runs the script in a context where environment variables are correctly set. Instead of using `sudo source myscript.sh`, try `sudo bash -c ‘source myscript.sh’`. This invokes a new bash shell with elevated privileges, allowing it to source the script correctly. This way, you don’t have to modify your script or rearrange your commands significantly.

      Alternatively, if your script doesn’t require elevated privileges for all operations, consider modifying it to use `sudo` where needed, instead of trying to run the entire script with elevated privileges. For instance, if the script has specific commands that need sudo, you can prefix those commands with `sudo` instead of running the whole script with it. This keeps your script more secure and flexible. If there are many environment variables to be set that absolutely require elevated access, creating a wrapper script that handles necessary elevation might be a beneficial approach. This way, you retain control and avoid potential permission issues while keeping your environment consistent.


    Related Questions