Shell – Should I be using ‘sudo’ in scripts that I write

scriptingshellsudoUbuntu

I'm setting up a new machine (well actually, an Ubuntu VM) and am trying to write a script to setup a few common things that I use when doing this (Git, curl, vim + janus).

So my script looks a bit like this:

#setup
#!/bin/sh
sudo apt-get install git
sudo apt-get install curl
...

It doesn't seem great to have 'sudo' mixed in with my command — that is just my security-spidey-sense tingling. It seems like something like the following might also work:

sudo setup

Is there a better way to do this? What are your rules of thumb when you write scripts and need elevated permissions?

Best Answer

There is no problem using multiple 'sudo' calls in scripts.

I find it better than running the whole scripts as root as the risks are limited by restricting the privilege elevation to the commands that really need them.

Related Solutions

Make ls distinguish scripts from binaries in output

You need to look at the contents of a file to distinguish between binaries and scripts. ls won't do this, it only looks at file names and metadata (type, permission, etc.).

Here's a crude parser for file that colors scripts and binaries differently. It acts like ls -d; adding metadata would require a patch-up job that calls for a more direct approach (e.g. in Perl or Python); use lsx somedir/* to list the contents of a directory. File names are assumed not to contain newlines nor colons (you can change the : separator for some other string with the -F option to file).

lsx () {
  file -iN -- "$@" |
  while IFS= read -r line; do
    name=${line%%: *}; type=${line#*: }
    color=0
    case $type in
      application/x-executable*) color='32';;
      text/x-shellscript*) color='01;32';;
      application/*zip*) color='31';;
    esac
    printf '\033[%sm%s\033[0m\n' "$color" "$name"
  done
}

Bash – When is it important to write portable scripts

As a member of this community I do not often see people disregarding bashisms for things that target bash. When talking about portability, GNUisms are much worse than bashisms. As long as you use bash for your shebang, you can expect the script to be executed using bash. However, you can't guarantee the version unless you explicitly check. Bash version 4 brought some useful features such as associative arrays, but Bash v3 is still widely used on OS X and RHEL 5.

what types of scripts should be as portable as possible?

This is more about your needs and what you choose to support as the developer. If you are writing an install script for an application that supports all types of *NIX, then portability will be very important.

how common are systems that do not have Bash installed?

FreeBSD and Solaris 10 are examples of systems that do not come with bash installed by default. Most Linux systems will have it, with the exception of embedded systems.

if the system has Bash installed, will it also have the GNU version of find and other utilities?

No, and this is the real issue with portability. If portability is important, you should only use shell command features that are defined by the POSIX standard. GNU utilities can be installed on non-GNU systems such as FreeBSD, but they are unlikely to be first in PATH, and you can not rely on those tools to be installed.

Best Answer

Related Solutions

Make ls distinguish scripts from binaries in output

Bash – When is it important to write portable scripts

Related Question