-
-
Save cowboy/3118588 to your computer and use it in GitHub Desktop.
#!/bin/bash | |
# Might as well ask for password up-front, right? | |
sudo -v | |
# Keep-alive: update existing sudo time stamp if set, otherwise do nothing. | |
while true; do sudo -n true; sleep 60; kill -0 "$$" || exit; done 2>/dev/null & | |
# Example: do stuff over the next 30+ mins that requires sudo here or there. | |
function wait() { | |
echo -n "["; for i in {1..60}; do sleep $1; echo -n =; done; echo "]" | |
} | |
wait 0 # show reference bar | |
echo "$(sudo whoami) | $(date)" | |
wait 1 | |
echo "$(sudo whoami) | $(date)" | |
wait 2 | |
echo "$(sudo whoami) | $(date)" | |
wait 5 | |
echo "$(sudo whoami) | $(date)" | |
wait 10 | |
echo "$(sudo whoami) | $(date)" | |
wait 15 | |
echo "$(sudo whoami) | $(date)" | |
wait 1 | |
sudo -K | |
echo "$(whoami) | $(date)" | |
wait 2 | |
echo "$(whoami) | $(date)" | |
wait 5 | |
echo "done." |
I was thinking about something like this but it doesn't handle the case where sudo
expires immediately
@spudowiar, I recently changed my dotfiles to use the sledge-hammer approach to sudo
ing by adding myself to /etc/sudoers
for the duration of the script, because anything else just wouldn't work reliably.
Maybe that will work for your case.
Awesome... That's exactly what I'm looking for. Unfortunately it does not work with a long running task like a massive brew install. After that, the sudo session is expired and you have to re-enter a password for the next sudo command. @cowboy Do you have any hints/experiences on that?!
I think the following statement:
while true; do sudo -n true; sleep 60; kill -0 "$$" || exit; done 2>/dev/null &
Should be changed to:
while true; do sleep 60; sudo -n true; kill -0 "$$" || exit; done 2>/dev/null &
Because an immediate call to sudo
right after the first one is not only redundant, but would also cause sudo to ask password again for the second real sudo call (at lease in my testing case).
Awesome... That's exactly what I'm looking for. Unfortunately it does not work with a long running task like a massive brew install. After that, the sudo session is expired and you have to re-enter a password for the next sudo command. @cowboy Do you have any hints/experiences on that?!
Homebrew explicitly invalidates the sudo timestamp, so AFAIK there's no way for this to work with brew.
@cowboy are you saying that this attempt at a solution didn't work? https://gist.github.com/cowboy/6733297
Has anyone tried this solution with the following sequence of commands:
sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get -y autoremove
local packages=(tree curl unzip htop gconf-service gconf-service-backend gconf2
gconf2-common libappindicator1 libgconf-2-4 libindicator7
libpython2-stdlib python python2.7 python2.7-minimal libatomic1
gimp vlc)
sudo apt-get -y install ${packages[@]}
sudo apt-get -y update
# At this point it asks me again the password
sudo apt-get -y install gufw
For me it didn't work.
Does sudo count the times is called along with the timeout? Because I see I'm using a few redundant apt-get update
.
FYI: I'm running ubuntu 20.04
Hi thanks for this gist!
I do have a problem actually, which is really strange! I have an updateall script that takes care of my osx, npm, brew and pip updates and package upgrades.
the following asks for sudo password again right after
echo "Next up: Npm"
, while ...the following script doesn't (note only changed the position of npm before brew)
I am using stuff from both @cowboy and @mathiasbynens in my dotfiles, maybe you guys know whats up..