I have a script which contains

while true
  sudo mycmd
  sleep 10000
  [ ... ] ; break

when I run the script in bash, I will have to provide my password once in 10000 seconds after finishing running the previous instance of sudo mycmd.

I remeber yes | somecommand can repeatedly provide yes as stdin input to somecommand, as answers to repeated questions of "Yes or No". I wonder how I can provide my password repeatedly to the script?


  • 4
    Why not just run the script with sudo to start? Alternatively, set up sudo so it can run mycmd with no password.
    – ivanivan
    Oct 31, 2018 at 3:40

2 Answers 2


The password can be piped into the sudo command but this is not secure in any way at all and should be avoided if possible.

echo 'hunter2' | sudo -S mycmd

A better method would be to just run the entire script with sudo and only require the password once.

The sudo password can also be avoided entirely but is also not recommended for security reason. This can be done by updating the /etc/sudoers file with the visudo command and including a line such as this for all users in the wheel group.


To disable it only for a single user switch %wheel with the users username.

  • 1
    you may replace last ALL by /absolute/path/to/mycmd
    – Archemar
    Oct 31, 2018 at 6:08

You asked:

how I can provide my password repeatedly to the script?

and ewatt's answer shows a direct way of doing that.

Using the "NOPASSWD" flag for the "sudo mycmd" rule would avoid asking for your password at all, as ewatt mentioned.

Alternatively, if you don't want to hard-code your password in a script, tell sudo that it's OK to cache the password for this particular command until the next reboot by setting the timestamp_timout to a negative value. Here, I've defined an alias for the command (arbitrarily replaced as /tmp/mycmd.sh) and used that in the Defaults definition.

Cmnd_Alias MYCMD = /tmp/mycmd.sh
Defaults!MYCMD timestamp_timeout=-1

Alternatively, you could set a user-level timeout default:

Defaults:tim timestamp_timeout=-1

... which would mean that your timestamp for any sudo command would be cached until the next reboot.

Or, alternatively still, timeouts for any command and any user, but on a particular host:

Defaults@thishost timestamp_timeout=-1

Setting the timestamp_timeout this way allows sudo to cache your password after the first time you enter it.

If you implement one of the Defaults options in order to avoid entering your password during each loop of the script, but prefer the safety net of entering your password for separate activities, then run sudo -k to tell sudo to "kill" (or reset) your timestamp, so that you'll be prompted for it next time. Note that you'll restart this "cached" ... "reset" process each time you authenticate to sudo.

If "until the next reboot" is too long for you, then set it to a value that's larger "enough" than 10000 seconds -- in minutes, so more than 166! -- to allow you to notice and enter the password for each loop.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.