1654: Universal Install Script
|Universal Install Script|
Title text: The failures usually don't hurt anything, and if it installs several versions, it increases the chance that one of them is right. (Note: The 'yes' command and '2>/dev/null' are recommended additions.)
Most users of computers today are used to simple, easy installation of programs. You just download a .exe or a .pkg, double click it, and do what it says. Sometimes you don't even have to install anything at all, and it runs without any installation.
However, when things are more "homebrew", for example downloading source code, things are more complicated. Under Unix-like systems, which this universal install script is designed for, you may have to work with "build environments" and "makefiles", and command line tools. To make this process simpler, there exist repositories of programs which host either packages of source code and the things needed to build it or the pre-built programs. When you download the package, it automatically does most of the work of building the code into something executable if necessary and then installing it. However, there are many such repositories, such as "pip" and "brew", among others listed in the comic. If you only know the name of a program or package, you may not know in which repository(ies) it resides.
install.sh file provided in the comic is a shell script, which attempts to fix this problem by acting as a "universal install script" that contains a lot of common install commands used in various Unix-like systems. This script in particular is interpreted by the Bourne Again Shell (Bash), which is denoted by the
#!/bin/bash in the first line. In between each of the install commands in the script is the & character, which in POSIX-compatible shells (including Bash, a popular shell scripting language) means it should continue to run the next command without waiting for the first command to finish, also known as "running in the background". This has the effect of running all the install commands simultaneously; all output and error text provided by them will be mixed together as they are all displaying on the screen around the same time.
The script accepts the name of a program or package as an argument when you run it. This value is then referenced as "$1" (argument number 1). Everywhere the script says "$1", it substitutes in the name of the package you gave it. The end result is the name being tried against a large number of software repositories and package managers, and hopefully, at least one of them will be appropriate and the program will be successfully installed. Near the end, it even tries copying the source code from an online source and then runs several commands which compile/build the program.
All in all, this script would probably work; it runs many standard popular repository programs and package managers, and runs the nearly-universal commands needed to build a program. Most of the commands would simply give an error and exit, but hopefully the correct one will proceed with the install.
One of the more subtle jokes in the comic is the inclusion of
sudo apt-get in the same script. Good unix practice dictates never logging in as root; instead you stay logged in as your normal user, and run system admin accounts via
sudo program name. This prevents accidental errors and enables logging of all sensitive commands. A side effect of this, however, is that an administrator may forget to prefix their command with
sudo, and re-running it properly the second time. This is a common joke in the Linux community, an example of which can be found at this viral tweet which shows a humorous workaround for the issue.
Since Randall's script does not use sudo for any but the
apt-get command, there are two possibilities: the script itself was run via the root user or via sudo, in which case the
sudo apt-get is not needed, or the script was run as a normal user, in this case the commands may install a local (as opposed to system-wide) version depending on local conditions. For instance npm will install a copy of the package under $HOME/.npm and pip would work as long as the user is working in a virtualenv (which is standard practice for Python developers).
curl downloads files from the network (e.g., the Internet). For example,
curl http://xkcd.com/ downloads and displays the xkcd HTML source. The pipe
| in the script attaches the output of the command before the pipe to the input of the command after the pipe, thus running whatever commands exist in the web content. Although this "curl|sh" pattern is a common practice for conveniently installing software, it is considered extremely unwise; you are running untrusted code without validation, there may be a MITM who modifies the code you receive, or the remote system could have been hijacked and the code made malicious. Most local package managers (e.g.
yum) offer digitally-signed packages that thwart this problem. You can find many examples of software providers suggesting a
curl|sh solution at curlpipesh
There appears to be a bug with the & at the end of the "git clone" line; since a git repository typically contains program source code, not executables, it may have been intended to retrieve the source code with git and then compile and install the program in the next line. In this case, the single & should be replaced with &&, an operator that will run the second command only if the first one has completed successfully. This plays into a second bug on the "configure" line, where the placement of the & means that only the "make install" command will be run asynchronously after the "configure" and "make" steps have finished in sequence (though this would likely fail due to a lack for write permissions unless it was run with sudo). To make success as likely as possible, the two lines should be like this or script should be executed twice:
git clone https://github.com/"$1"/"$1" && (cd "$1"; ./configure; make; sudo make install) &
Since all commands are running in the background, any command that requires user input will stop and wait until brought to the foreground. A common request would be for a database password, or if it is allowed to restart services for the installation. This could lead to packages being only partly installed or configured. (See more about using "yes" below.)
The title text mentions the possibility that the same program may be in multiple repositories, so in this case, the script will download and install several versions, or it may fail on a number of repositories, in which case usually nothing bad happens. Since all the commands come from different operating systems, versions, or distributions, it is not very likely that more than one will work (with the exception of pip/easy_install and the two forms of apt-get) or even exist on the same system. It mentions that adding a way of automatically saying "yes" to questions asked during the different repository-fetching programs' running, by making them read input from another program that writes a (nearly) endless stream of "y"s, could simplify things further. This would not work for any curses-based menus, or to answer any more complicated questions. Adding
2>/dev/null to a command redirects the second output stream (the "error stream") to the null device driver, which discards all writes to it, meaning errors (the package not existing) will not be sent to the screen.
- [In the panel is a shell script which, unusual for xkcd, uses only lower case. At the top the title of the program is inlaid in the frame, which has been broken here.]
- pip install "$1" &
- easy_install "$1" &
- brew install "$1" &
- npm install "$1" &
- yum install "$1" & dnf install "$1" &
- docker run "$1" &
- pkg install "$1" &
- apt-get install "$1" &
- sudo apt-get install "$1" &
- steamcmd +app_update "$1" validate &
- git clone https://github.com/"$1"/"$1" &
- cd "$1";./configure;make;make install &
- curl "$1" | bash &
- pip and easy install are package managers for Python
- brew is the successor/replacement for MacPorts and a third-party package manager for OS X
- npm is the node package manager that maintains node.js packages
- yum is the package management tool for Red Hat Enterprise Linux and some derivatives
- dnf is the package management tool for Fedora since version 22
- docker run is a Docker command that runs a given container (similar to a virtual machine)
- pkg is the package management tool on BSD systems
- apt-get is the package management tool of Debian and derivatives (e.g. Ubuntu)
- steamcmd refers to the command line version of Steam, the computer game client
- git is the revision control software used for many projects and gained a lot of traction through the GitHub platform
- configure/make/make install refers to the standard way of compiling software from source (on Linux/Unix)
- curl is a tool for loading data via http:// (i.e. from a website), this data is then pushed to the shell interpreter (in order to install)
- Note: While this is a security nightmare, some projects (like Homebrew) still use it as the preferred or only method of installation.
- a similar comic is xkcd 1987 which concerns only Python.
add a comment! ⋅ add a topic (use sparingly)! ⋅ refresh comments!