Editing 1654: Universal Install Script

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 14: Line 14:
 
The <code>install.sh</code> file provided in the comic is a {{w|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 {{w|Bourne Again Shell}} (Bash), which is denoted by the <code>#!/bin/bash</code> in the first line. In between each of the install commands in the script is the & character, which in {{w|POSIX}}-compatible {{w|Unix shell|shells}} (including {{w|Bash (Unix shell)|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 <code>install.sh</code> file provided in the comic is a {{w|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 {{w|Bourne Again Shell}} (Bash), which is denoted by the <code>#!/bin/bash</code> in the first line. In between each of the install commands in the script is the & character, which in {{w|POSIX}}-compatible {{w|Unix shell|shells}} (including {{w|Bash (Unix shell)|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.
+
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.
 
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 <code>apt-get</code> and <code>sudo apt-get</code> 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 <code>sudo program name</code>. 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 <code>sudo</code>, 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 [https://web.archive.org/web/20220304210306/https://twitter.com/liamosaur/status/506975850596536320 viral tweet] which shows a humorous workaround for the issue.
+
One of the more subtle jokes in the comic is the inclusion of <code>apt-get</code> and <code>sudo apt-get</code> 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 <code>sudo program name</code>. 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 <code>sudo</code>, 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 [https://twitter.com/liamosaur/status/506975850596536320 viral tweet] which shows a humorous workaround for the issue.
  
 
Since Randall's script does not use sudo for any but the <code>apt-get</code> command, there are two possibilities: the script itself was run via the root user or via sudo, in which case the <code>sudo apt-get</code> 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 [https://iamzed.com/2009/05/07/a-primer-on-virtualenv/ virtualenv] (which is standard practice for Python developers).
 
Since Randall's script does not use sudo for any but the <code>apt-get</code> command, there are two possibilities: the script itself was run via the root user or via sudo, in which case the <code>sudo apt-get</code> 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 [https://iamzed.com/2009/05/07/a-primer-on-virtualenv/ virtualenv] (which is standard practice for Python developers).
Line 32: Line 32:
 
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.)
 
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.)
  
===Title text===
+
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 <code>2>/dev/null</code> 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.
The title text mentions the possibility that the same program may be in multiple repositories. In this case, the script may download and install several different versions of the same software. This would likely only create a confusing install-base, as an operating system would tend to prefer to use one version over another regardless of which one functions. It is unlikely that different repositories include the same software, with the exception of pip/easy_install and the two forms of apt-get, which would each likely see the software is already installed and abort. A way to fix this would be to use if statements. An example of this is [https://github.com/TheOddCell/Universal-Install-Script/blob/main/install.sh here].
 
 
 
The title text also 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 {{w|curses (programming library)|curses}}-based menus, or to answer any more complicated questions. Adding <code>2>/dev/null</code> 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.
 
  
 
==Transcript==
 
==Transcript==
Line 71: Line 68:
 
*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)
 
*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.
 
**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 [[1987]] which concerns only Python.
+
* a similar comic is {{xkcd|1987}} which concerns only Python.
  
 
{{comic discussion}}
 
{{comic discussion}}
Line 77: Line 74:
 
[[Category:Programming]]
 
[[Category:Programming]]
 
[[Category:Version Control]]
 
[[Category:Version Control]]
[[Category:Comics with lowercase text]]
 

Please note that all contributions to explain xkcd may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see explain xkcd:Copyrights for details). Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel | Editing help (opens in new window)