Useful Unix Terminal Commands for TeX, LaTeX, and XeLaTeX for document design and generation

bash-latex.sh

## IF YOU ARE USING OS X, WE RECOMMEND USING MacTeX (BE AWARE: 2GB DOWNLOAD, REQUIRES SYSTEM RESTART AFTER INSTALLATION):
## https://tug.org/mactex/
## 
## IF YOU ARE USING WINDOWS, WE RECOMMEND USING MikTeX (DOWNLOADED APP WILL CONNECT ONLINE TO DOWNLOAD PACKAGES):
## http://miktex.org/
##
## ON WINDOWS (WHILE NOT NECESSARY) YOU MAY ALSO WANT TO BE USING A TERMINAL/SHELL EMULATING SYSTEM LIKE mingw OR cygwin,
## NOT ONLY FOR LaTeX, BUT FOR GENERAL PROGRAMMING AND SCRIPTING PURPOSES AS WELL.
##
## THE FOLLOWING COMMANDS ARE ONLY TESTED AND CONFIRMED FOR UNIX (bash):


# CHECK IF YOU HAVE pdflatex ON YOUR SYSTEM (PATH WILL BE PRINTED BELOW)
which pdflatex;


# CHECK IF YOU HAVE biber ON YOUR SYSTEM (PATH WILL BE PRINTED BELOW)
which biber;


# CHECK IF YOU HAVE xelatex ON YOUR SYSTEM (PATH WILL BE PRINTED BELOW)
which xelatex;


# UPDATE YOUR (La)TeX REPOSITORY MANAGER (RUN THIS BEFORE UPDATING REPOSITORIES)
sudo -E tlmgr update --self;


# UPDATE YOUR (La)TeX REPOSITORY PACKAGES (!! THIS CAN TAKE AN HOUR OR MORE !!)
sudo -E tlmgr update --all;



## WHY MULTIPLE BUILDS?
# When new to latex, it may seem strange that you need multiple calls to the same executable.
# What is happening, though, is that these executables work like state-machine calls. The first
# time, they are building the necessary logs and relationships found in your files. The next
# call(s) are then taking those existing log and relationship files and coordinating them to
# render the counted and connected elements of the final document. How would the system know
# how many pages there are until it renders all the pages? Good question, right? That is why
# these systems run multiple times, because you need to pre-render, compute, and re-render to
# get all of the expected information. In WYSIWYG document editors, like Microsoft Word, these
# computations are ongoing and hidden in the background of the application. When documents get
# sufficiently large, you can feel the sluggishness of the rendering in a visual editor, because
# those computations are constantly running and re-running. With LaTeX you are always only
# writing code, in the programming (typesetting) language, and only when you are ready do you
# call for the rendering commands to run. They can take seconds or minutes, depending on your
# system and the size/complexity of your documents, but it is a directly called operation, not
# an ongoing one. The only way the document knows to say "Page 10 of 100", is if it already
# pre-rendered all sections, figures, labels, listings, equations, and margins and knows that
# there are 100 pages and this is the 10th one. Instead of running and checking and computing
# constantly, as visual editor does, the LaTeX approach runs only when called, thus you need
# to re-run it subsequent times to pre-compute and then render the relevant information and
# alignment geometry.


# BUILD PDF FROM *.tex FILE
pdflatex MyLaTeXReport.tex;
pdflatex MyLaTeXReport.tex;


# BUILD PDF FROM *.tex FILE WITH BIBLIOGRAPHY
pdflatex MyLaTeXReport.tex;
biber MyReportReferences.bib;
pdflatex MyLaTeXReport.tex;
pdflatex MyLaTeXReport.tex;


# BUILD PDF WITH CUSTOMIZED FONTS FROM *.tex FILE WITH BIBLIOGRAPHY
xelatex MyLaTeXReport.tex;
biber MyReportReferences.bib;
xelatex MyLaTeXReport.tex;
xelatex MyLaTeXReport.tex;




# FIX THE TERRIBLE AND WEIRD ERROR WITH biber WHEN TRYING TO REBUILD A DOCUMENT
# REFERENCE: http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file
# SUMMARY: Essentially the biber cache gets filled with garbage and you need to wipe it, otherwise
#          it attempts to reuse its own cache, but can't. This is what the error is (very confusingly)
#          trying to tell you. Because of all the styles and rules that biber follows, it relies on
#          its cache to simplify subsequent calls. When you run it too often, it's easy to fill the
#          cache, though, and subsequent calls will not be able to write new data or read any of the
#          existing data, and essentially your build system is stuck until you clear the cache.
rm -rf `biber --cache`;