simplifiying the runscript section

Author: GodloveD

02-building/README.md

@@ -197,7 +197,7 @@ OSVersion: stable
 MirrorURL: http://ftp.us.debian.org/debian/
 
 %runscript
-    fortune | cowsay | lolcat
+    echo "This is what happens when you run the container..."
 
 %post
     apt-get update

05-runscript/README.md

@@ -1,26 +1,25 @@
-# The Runscript: Making containerized apps behave more like normal apps
+# The Runscript: Making containerized apps behave like normal apps
 
-We are now going to consider an extended example describing a containerized application that takes a file as input, analyzes the data in the file, and produces another file as output.
-This is obviously a very common situation.
+Consider an application that takes one file as input, analyzes the data in the file, and produces another file as output. This is obviously a very common situation.
 
-Let's imagine that we want to use the cowsay program in our `lolcow.simg` to "analyze data".  We should give our container an input file, it should reformat it (in the form of a cow speaking), and it should dump the output into another file.  
+Let's imagine that we want to use the cowsay program in our `lolcow.sif` to "analyze data".  We should give our container an input file, it should reformat the text (in the form of a cow speaking), and it should dump the output into another file.  
 
 Here's an example.  First I'll make some "data"
 
 ```
-$ echo "The grass is always greener over the septic tank" > input
+$ echo "The grass is always greener over the septic tank" > /data/input
 ```
 
 Now I'll "analyze" the "data"
 
 ```
-$ cat input | singularity exec lolcow.simg cowsay > output
+$ cat /data/input | singularity exec lolcow.sif cowsay >/data/output
 ```
 
-The "analyzed data" is saved in a file called `output`. 
+The "analyzed data" is saved in a file called `/data/output`. 
 
 ```
-$ cat output
+$ cat /data/output
  ______________________________________
 / The grass is always greener over the \
 \ septic tank                          /
@@ -41,77 +40,55 @@ $ ./lolcow.simg
 This is what happens when you run the container...
 ```
 
-Let's rewrite this runscript in the definition file and rebuild our container
-so that it does something more useful.  
+Let's rewrite this runscript in the definition file and rebuild our container so that it does something more useful. And while we're at it, we'll change the bootstrap method to `library`  
 
 ```
-BootStrap: debootstrap
-OSVersion: stable
-MirrorURL: http://ftp.us.debian.org/debian/
+BootStrap: library
+From: debian:9
 
 %runscript
-    infile=
-    outfile=
-
-    usage() {
-        >&2 echo "Usage:"
-        >&2 echo "$SINGULARITY_NAME -i <infile> -o <outfile> [ -- <cowsay options> ]"
+    if [ $# -ne 2 ]; then
+        echo "Please provide an input and an output file."
         exit 1
-    }
-
-    while getopts i:o: argument
-    do
-        case $argument in
-        i)
-            infile="$OPTARG"
-            ;;
-        o)
-            outfile="$OPTARG"
-            ;;
-        ?)
-            usage
-            ;;
-        esac
-    done
-
-    shift "$((OPTIND - 1))"
-
-    if [ -z "$infile" ] || [ -z "$outfile" ]
-    then
-        usage
     fi
-
-    cat "$infile" | cowsay "$@" > "$outfile"
+    cat $1 | cowsay > $2
 
 %post
-    echo "Hello from inside the container"
     apt-get update
     apt-get -y install fortune cowsay lolcat
-    apt-get clean
 
 %environment
     export PATH=$PATH:/usr/games
-    export LC_ALL=C
 ```
 
 Now we must rebuild out container to install the new runscript.  
 
 ```
-$ sudo singularity build --force lolcow.simg Singularity
+$ sudo singularity build --force lolcow.sif lolcow.def
 ```
 
 Note the `--force` option which ensures our previous container is completely overwritten.
 
-After rebuilding our container, we can call the lolcow.simg as though it were an executable, give it input and output file names, and optionally give additional arguments to go directly to the `cowsay` program.  
+After rebuilding our container, we can call the `lolcow.sif` as though it were an executable, give it input and output file names.  
 
 ```
-$ ./lolcow.simg
-Usage:
-lolcow.simg -i <infile> -o <outfile> [ -- <cowsay options> ]
+$ ./lolcow.sif /data/input /data/output2
+/.singularity.d/runscript: 7: /.singularity.d/runscript: cannot create /data/output2: Directory nonexistent
+cat: /data/input: No such file or directory
+```
+
+Whoops!  
 
-$ ./lolcow.simg -i input -o output2
+We are no longer piping redirecting standard output into and out of the container, so we need to bind mount the `/data` directory into the container.  It will be convenient to simply set the bind path as an environment variable.  
 
-$ cat output2
+```
+$ export SINGULARITY_BINDPATH=/data
+
+$ ./lolcow.sif /data/input /data/output2
+
+$ ./lolcow.sif /data/vader.txt /data/output3
+
+$ cat /data/output2 /data/output3
  ______________________________________
 / The grass is always greener over the \
 \ septic tank                          /
@@ -121,4 +98,27 @@ $ cat output2
             (__)\       )\/\
                 ||----w |
                 ||     ||
+ __________________
+< I am your father >
+ ------------------
+        \   ^__^
+         \  (oo)\_______
+            (__)\       )\/\
+                ||----w |
+                ||     ||
 ```
+
+To summarize, we have written a runscript for our container that will do some very basic error checking and expects the location of an input file and an output file allowing it to analyze the data. This is obviously a trivial example, but the sky is the limit. If you can code it, you can make your container do it!  
+
+---
+**BONUS**
+
+You will often see this or something similar as a containers runscript.
+
+```
+%runscript
+    python "$@"
+```
+What does this do?
+
+---