If the whole script is run with sudo, then all parts of the script that wouldn't have needed suddenly become dangerous.

It is not common, but could be considered best practise in some circumstances because it limits the amount of time the script and any child processes are running with extra privileges and so reduces the potential splash damage of any bugs in the unprivileged parts of the script. If your sudo is configured not to prompt for auth every time (the usual default) the user being reprompted for auth each time is not an issue¹.

I've needed to use it in some scripts for checking/managing content on FUSE mounts which are mounted without “-o allow_root”, here calling the script through sudo doesn't do the full job as root can't access the content through the fuse-based mount so we sudo again to impersonate the user owning the mount.

----

[1] if the script may be a while doing other things before the first sudo call, you might want to run “sudo -v”² early on meaning the user can give auth at the start if needed so they don't run your script, it ask for auth a minute later, and them not notice as they are looking at something else at the time.

[2] from the manpage: -v, --validate, Update the user's cached credentials, authenticating the user if necessary.

sudo isn't exclusively for root privileges. I've set up generic users with complex home/config setups where the script itself was rather simple but relied on a lot of the environment.

also, sudo can be used to explicitly whitelist certain commands, so "killall processname" can work, but "rm - rf" wont. If you run the whole script as root, everyone who can edit can introduce a footgun.

It’s not common. but employ’s the least privilege principle, so there’s that