To do a patch manually I must type this command

sudo ./playback_delete_data_patch.sh 09_delete_old_data_p.sql  

There is a space just before the 09:

sudo ./playback_delete_data_patch.sh [space] 09_delete_old_data_p.sql

How can I run this inside a script?

There are also several other commands but this one is giving trouble.

  • 3
    Just put it in the script, what's the problem?
    – Lie Ryan
    Feb 24, 2014 at 22:31
  • 9
    @LieRyan - the sudo password - the script won't be able to run fully if someone is not there to enter it.
    – Wilf
    Feb 24, 2014 at 23:04
  • My system just runs them fine without prompting. Ubuntu 16.04 in October 2017. You have messed up your sudoers setup . No big deal. It just needs fixed.
    – SDsolar
    Oct 11, 2017 at 22:02
  • 6
    @SDsolar Your system is the one that's messed up; it's a minor security vulnerability to not prompt for the password (makes users more vulnerable to some types of social engineering attacks).
    – wizzwizz4
    Feb 24, 2018 at 13:32
  • How you run the script (with regard to sudo) does affect the environment (i.e. available variables), though. This is important in some cases, for example with gsettings.
    – caw
    Jun 15, 2021 at 4:41

7 Answers 7


It is rarely a good idea to have sudo inside scripts. Instead, remove the sudo from the script and run the script itself with sudo:

sudo myscript.sh

That way, all commands within the script will be run with root privileges and you only need to give the password once when launching the script. If you need a particular command within the script to be run without sudo privileges, you can run it as a regular user with (thanks Lie Ryan):

sudo -u username command 

The space is irrelevant, it should not affect anything, there is always a space between a command and its arguments.

  • 48
    there may be commands in the script that don't need the root privilege, you can drop the root privilege temporarily for those commands by using sudo -u username
    – Lie Ryan
    Feb 25, 2014 at 22:01
  • 82
    A lot of scripts I write do a whole bunch of user interaction and/or error checking. Then one command at the end - something like rsync - needs to be run as root. Why would I want to make the whole thing run elevated and leave myself open to many lines of code that could contain serious errors or vulnerabilities with root access - especially while debugging - when only one or a few commands require that access?
    – Joe
    Sep 26, 2015 at 4:28
  • 17
    @Joe has a really good point here. Also when one says don't do that, it would be nice to know exactly why is that, or at least, in which context shouldn't I do that, and why
    – arainone
    Sep 24, 2016 at 10:50
  • 6
    When sudo is run on a script it sets the $SUDO_USER environmental variable to the user who called the script. Useful in conjunction with sudo -u
    – Zell Faze
    Jan 2, 2017 at 17:30
  • 17
    @terdon You aren't listening. I know that if you run the script as root it will never prompt you for sudo. I'm comparing that with not running the script as root and instead putting explicit sudo calls in the script, because elevating the entire script to root may be a terrible idea if there are only a handful of narrow actions that need root. In that context I was responding specifically to your comment: "Largely because this means you can't run the script automatically since you will need to enter the password each time you are asked."
    – BeeOnRope
    Aug 10, 2017 at 16:31

You could possibly modify the sudoers file.

Run sudo visudo.

Add an entry for your username and the script that you would like to run without being asked for a password.

username ALL=(ALL) NOPASSWD: /path/to/script
  • 3
    Didn't work for me, but thanks, good to know this exists. Perhaps I got the syntax wrong.
    – Krista K
    Jul 30, 2015 at 23:02
  • 14
    Not sure anyone mentioned it, but you must terminate all login sessions of that user after you have edited the sudoers file.
    – escape-llc
    Nov 12, 2015 at 17:54
  • 2
    Just to clarify here it is not the script that contains the "sudo ./playback_delete_data_patch.sh 09_delete_old_data_p.sql" line that should be specified in the sudoers file but the playback_delete_data_patch.sh script or whatever other command you want that user and/or their scripts to be able to run through sudo without specifying a password.
    – MttJocy
    Jul 8, 2016 at 19:42
  • I'm trying to use this for a grub reboot to windows script. Code is: sudo grub-reboot "$(grep -i 'windows' /boot/grub/grub.cfg|cut -d"'" -f2)" && sudo reboot This works in a terminal but not in a shell script prepended with #!/bin/sh & set to executable. Any thoughts why this would be? Mousepad colouring suggests the && sudo reboot is being treated as if in quotes? I tried removing the sudos from that line and it didn't change anything. Thanks!
    – dez93_2000
    Apr 22, 2020 at 20:24
  • Turns out I needed to also add /usr/sbin/grub-reboot to /etc/sudoers and remove 'sudo' from before reboot
    – dez93_2000
    Apr 22, 2020 at 20:40

You could try something like:

echo "PASSWORD" | sudo -S ./playback_delete_data_patch.sh 09_delete_old_data_p.sql

This is not the most secure thing to do since you are writing a sudoer password in plain text. To make it a little more secure you can create a variable and read the sudo password into the variable and then you could execute the command as:

echo $PASSWORD | sudo -S ./playback_delete_data_patch.sh 09_delete_old_data_p.sql

Also, if you do not mind all your commands being executed as root you can simple execute your script using sudo, as previously suggested.

sudo ./myscript
  • 4
    Reading password into variable securely: read -s PASSWORD Apr 30, 2019 at 12:27

This answer is similar to terdon's answer. I would also suggest running the main script with sudo so the script can run without having to ask for the user's password during its execution.

However, in case you want to drop root privileges to some of the commands and run them as the actual user who invoked the command with sudo, you can check for the $SUDO_USER variable to figure out the original user.

This is an example script of how you could achieve that:


# ref: https://askubuntu.com/a/30157/8698
if ! [ $(id -u) = 0 ]; then
   echo "The script need to be run as root." >&2
   exit 1

if [ $SUDO_USER ]; then

# Commands that you don't want running as root would be invoked
# with: sudo -u $real_user
# So they will be run as the user who invoked the sudo command
# Keep in mind if the user is using a root shell (they're logged in as root),
# then $real_user is actually root
# sudo -u $real_user non-root-command

# Commands that need to be ran with root would be invoked without sudo
# root-command

There is actually a much simpler way to do this. For portability, this is my implementation but feel free to manipulate it to suit your need.

Enter your sudo password as a parameter when starting the script, capture it, and echo it with each command which will prompt for the sudo password.


echo $PW | ./playback_delete_data_patch.sh 09_delete_old_data_p.sql  
./command_wo_sudo.sh <param>
echo $PW | ./other_command_requires_sudo.sh <param>

You can add a prompt and capture after the script is kicked off like so:

echo "enter the sudo password, please"
read PW

But if someone else monitors what's run on the node; has access to logs created by it; or is just looking over your should randomly when you run a test, that could compromise security.

This also works with running commands/scripts that require a yes to continue:

echo $PW | yes | ./install.sh

The echo is in response to a prompt, so you can use anything you need to, there, if you're running other scripts that have prompts for progress, in sequential order. Make sure you know that order, though, or bad things can happen.

  • That's so much more elegant and simple, I'm glad I scrolled all the way down! EDIT: wait, this will add the password to my terminal history
    – Job
    Aug 2, 2018 at 9:10
  • 5
    How to ask for username/password with read: ryanstutorials.net/bash-scripting-tutorial/bash-input.php That should avoid this issue
    – Job
    Aug 2, 2018 at 9:13
  • 3
    Add a space before the command to avoid it appearing in the history. Oct 16, 2020 at 18:14
# this declares that current user is a sudoer
sudo tee /etc/sudoers.d/$USER <<END

# write the content of your script here
sudo npm install hexo-cli -g
mkdir Untitled
sudo apt-get install python

# then to remove the sudo access from the current user
sudo /bin/rm /etc/sudoers.d/$USER
sudo -k
  • 12
    This script has a very dangerous bug. For the duration of the time the script is running, the current user has elevated privileges. Furthermore, if the script crashes, these privileges are not revoked.
    – dotancohen
    Sep 15, 2020 at 0:57

You could try to add the user who runs the script to the sudoers file:

#give permissions to the file
sudo chmod 700 /etc/sudoers.d/useradm

sudo visudo /etc/sudoers.d/useradm

#add the following text, changing "user" but your desired user

#return the right permissions to the file
sudo chmod 440 /etc/sudoers.d/useradm
  • 4
    Generally this is a poor method. If you're going to add NOPASSWD sudo rules, especially for accounts that run automation, you should at minimum be restricting them to the exact command that is run (and not ALL) Nov 29, 2018 at 1:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .