% arara: pdflatex % arara: pdflatex % arara: biber % arara: pdflatex % arara: pdflatex % arara: clean: { files: [ arara-usermanual.aux, arara-usermanual.bbl ] } % arara: clean: { files: [ arara-usermanual.bcf, arara-usermanual.cod ] } % arara: clean: { files: [ arara-usermanual.blg, arara-usermanual.lof ] } % arara: clean: { files: [ arara-usermanual.lot, arara-usermanual.out ] } % arara: clean: { files: [ arara-usermanual.toc, arara-usermanual.log ] } % arara: clean: { files: [ arara-usermanual.run.xml ] } % ------------------------------------------------- % Arara -- the cool TeX automation tool % Copyright (c) 2012, Paulo Roberto Massa Cereda % All rights reserved. % % Redistribution and use in source and binary forms, with or without % modification, are permitted provided that the following conditions % are met: % % 1. Redistributions of source code must retain the above copyright % notice, this list of conditions and the following disclaimer. % % 2. Redistributions in binary form must reproduce the above copyright % notice, this list of conditions and the following disclaimer in the % documentation and/or other materials provided with the distribution. % % 3. Neither the name of the project's author nor the names of its % contributors may be used to endorse or promote products derived from % this software without specific prior written permission. % % THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS % "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT % LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS % FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE % COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, % INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, % BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; % LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER % CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT % LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY % WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE % POSSIBILITY OF SUCH DAMAGE. % ------------------------------------------------- \documentclass[a4paper,twoside,12pt]{memoir} % packages % ------------------------------------------------- \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{arara} % ------------------------------------------------- % bibliography % ------------------------------------------------- \addbibresource{references.bib} % ------------------------------------------------- % current version % ------------------------------------------------- \newcommand{\araraversion}{3.0a} % ------------------------------------------------- % document % ------------------------------------------------- \begin{document} % title page % ------------------------------------------------- \begin{titlingpage} \begin{center} \vspace*{2em} \scalebox{1.15}{\araralogo} \vspace{2em} {\color{araracolor}\fontfamily{fco}\bfseries\Huge The cool \TeX{} automation tool} \vspace{10em} {\Huge\sffamily\bfseries User Manual} \vspace{3em} {\large \tabcolsep=1em \begin{tabular}{cc} \multicolumn{2}{c}{Paulo R.\ M.\ Cereda}\\ \multicolumn{2}{c}{\url{cereda@users.sf.net}}\\[1.5em] Marco Daniel & Brent Longborough\\ \url{marco.daniel@mada-nada.de} & \url{brent@longborough.org} \end{tabular}} \vfill {\LARGE\sffamily\bfseries Version \araraversion} \end{center} \end{titlingpage} % ------------------------------------------------- % set styles % ------------------------------------------------- \chapterstyle{madsen} \pagestyle{headings} \frontmatter \nouppercaseheads % ------------------------------------------------- % Prologue % ------------------------------------------------- \chapter*{Prologue} \label{chap:prologue} \epigraph{\emph{Moral of the story: never read the documentation, bad things happen.}}{David Carlisle} When I released the very first version of \arara on a Friday 13th, April 2012, I never thought the tool would receive so many positive comments and feedback. To be honest, since \arara was written for helping me with my own personal \LaTeX\ projects, I really doubted if the tool could be of service to anyone else. And, to my surprise, it seems \arara did good. To a lot of people around the \TeX\ world. I never intended to release the tool to the whole world, since I wasn't sure if other people could benefit from \arara's features. After all, there's already a plethora of tools available to the \TeX\ community in general, although with different approaches. The reason I decided to make \arara publicly available is quite simple: I wanted to somehow contribute to the \TeX\ community, and I wanted to give my best to make such community even more awesome. As time goes by, I'm quite satisfied with the current state of \arara~--~this is our 3rd major release. We have reached a very mature code and a great team of developers, translators and testers. Since version 1.0, the code evolved a lot -- new features, lots of bug fixes, improvements -- thanks to all the feedback I received. In my humble opinion, that's how any project should evolve: based on what our users expect and want to achieve. I'm proud to see \arara being 100\% community-driven, it's a big achievement for a project with less than one year old. First of all, I'd like to thank some friends of mine that really made \arara possible: Alan Munn, for providing great ideas and suggestions to the manual; Andrew Stacey, for heavily testing \arara, providing great user cases, and for suggesting improvements to the program; Brent Longborough, a member of the core team, for providing great suggestions and ideas to the program logic, writing rules, testing the code and also for working with the Portuguese and Turkish translations; Clemens Niederberger, for testing \arara, and also writing a great tutorial about it in his \href{http://www.mychemistry.eu/2012/06/arara-automate-latex-birds-music/}{blog on chemistry and \LaTeX}; David Carlisle, for reminding me to work on \arara, and also encouraging me to write answers about it in our \TeX\ community; Enrico Gregorio, for reviewing the original manual, testing \arara, providing great ideas and suggestions to the manual and to the program itself, and for working with the Italian translation; Francesco Endrici, for providing the very first \arara rule outside our core team; Harish Kumar, for being a heavy \arara user and integrating it with WinEdt and Inlage; \.Ilhan Polat for working with Brent in the Turkish translation; Joseph Wright, for testing it, providing contributed code for Linux and Mac installations, and also blogging about \arara in his \href{http://www.texdev.net}{personal blog}; Gonzalo Medina, for providing the Spanish translation; Mikaël Maunier, for providing the French translation; Marco Daniel, one of core team members, for heavily testing \arara, suggesting enhancements to the manual and to the program itself, providing lots of contributed rules for common tasks, and also for the German version; Patrick Gundlach, for advertising \arara in the official Twitter channel of \href{http://www.dante.de}{Dante} -- the German \TeX\ User Group; Sergey Ulyanov, for providing the Russian translation and contributed rules; Stefan Kottwitz, for encouraging me to write an article about \arara, published in the \href{http://latex-community.org/know-how/435-gnuplot-arara}{\LaTeX\ Community} forum, and also tweeting about it. Thank you very much. I'm sorry if I forgot to mention somebody, I really have so much people to thank and my memory happens to be very short. That said, I still believe that the warning featured in the first version of this manual still applies: \textsc{Hic Sunt Dracones}. Though the code really evolved from the first commit I made, \arara is far from being bug-free. And you will learn that \arara gives you enough rope. In other words, \emph{you} will be responsible for how \arara behaves and all the consequences from your actions. Sorry to sound scary, but I really needed to tell you this. After all, one of \arara's greatest features is the freedom it offers. But as you know, freedom always comes at a cost. Please, don't send us angry letters -- or e-mails, perhaps -- if something bad happen. Feedback is surely welcome for me to improve this humble tool, just write an e-mail to me or any other member of the team and we will reply as soon as possible. The source code is fully available at \url{http://github.com/cereda/arara}, feel free to contribute to the project by forking it, submitting bugs, sending pull requests or even translating it to your language. If you want to support the \LaTeX\ development by a donation, the best way to do this is donating to the \href{http://www.tug.org/}{\TeX\ Users Group}. Please also consider joining our \TeX\ community at \href{http://tex.stackexchange.com}{StackExchange}. \vspace{2em} \begin{flushright} Paulo Roberto Massa Cereda\\ \emph{on behalf of the \arara team} \end{flushright} %\vspace{8em} \vfill \begin{center} \scalebox{0.55}{\araralogo} \vspace{0.3em} {\color{araracolor}\fontfamily{fco}\bfseries\large Proudly made on Earth} \end{center} % ------------------------------------------------- \cleardoublepage % Special thanks % ------------------------------------------------- \section*{Special thanks} \begin{mdframed}[roundcorner=10pt,linecolor=araracolor,middlelinewidth=1pt] \centering {\renewcommand{\arraystretch}{1.5} \sffamily \begin{tabular}{ccc} Alan Munn & Andrew Stacey & Brent Longborough\\ Clemens Niederberger & David Carlisle & Enrico Gregorio\\ Francesco Endrici & Harish Kumar & \.Ilhan Polat\\ Joseph Wright & Gonzalo Medina & Mikaël Maunier\\ Marco Daniel & Patrick Gundlach & Sergey Ulyanov\\ Stefan Kottwitz & & \end{tabular}} \end{mdframed} \vspace{1em} \noindent\arara also makes use of some specific opensource Java projects and libraries in order to properly work. I would like to thank the following projects and their respective developers: \begin{enumerate} \item \href{http://commons.apache.org}{Apache Commons}, a project from the Apache Foundation focused on all aspects of reusable Java components. \arara uses three of the Commons libraries: \href{http://commons.apache.org/cli/}{CLI}, which provides a command line arguments parser, \href{http://commons.apache.org/collections/}{Collections}, a library which extends the Java Collections Framework, and \href{http://commons.apache.org/exec/}{Exec}, an API for dealing with external process execution and environment management in Java. \item \href{http://logback.qos.ch}{Logback}, a logging framework intended to be the successor to the popular \href{http://logging.apache.org/log4j/}{log4j} project. According to some benchmarks, it is faster and has a smaller footprint than all existing logging systems, sometimes by a wide margin. \item \href{http://code.google.com/p/snakeyaml}{SnakeYAML}, a YAML parser and emitter for the Java programming language. YAML is a data serialization format designed for human readability and interaction with scripting languages. \arara uses YAML as the rule format. \item \href{http://www.slf4j.org/}{SLF4J}, a simple facade or abstraction for various logging frameworks, allowing the end user to plug in the desired logging framework at deployment time. \item \href{http://mvel.codehaus.org}{MVEL}, a powerful expression language for Java-based applications. It provides a plethora of features and is suited for everything from the smallest property binding and extraction, to full blown scripts. \arara relies on MVEL to provide the expansion mechanism for rules. \item \href{http://maven.apache.org/}{Apache Maven}, a software project management and comprehension tool. Based on the concept of a project object model, Maven can manage a project's build, reporting and documentation from a central piece of information. \item \href{http://izpack.github.com}{IzPack}, a Java-based software installer builder that will run on any operating system coming with a Java Virtual Machine that is compliant with the Oracle JVM 1.5 or higher. \end{enumerate} A special thanks goes to my great friend \href{http://antoineneveux.fr/}{Antoine Neveux} for encouraging me to try out the \href{http://maven.apache.org}{Apache Maven} software project management. In the past, \arara was released as a NetBeans project, which is based on \href{http://ant.apache.org/}{Apache Ant}, another great tool from the Apache Foundation. Although I'm really fine with Ant, thanks to Maven, now it is way easier to build and to maintain the code. And it's always nice to learn another tool. And at last but not least, I want to thank you, dear reader and potential user, for giving \arara a try. Do not despair if you don't succeed with \arara at first; just try again. I'm sure you will find your way. This humble project is opensource and it will always be. Let the bird be your guide through the journey to the typographic land. Have a good read. % ------------------------------------------------- \cleardoublepage % Release information % ------------------------------------------------- \section*{Release information} \subsection*{Version 3.0} \begin{itemize} \item[\newfeature] Localizated messages in English, Brazilian Portuguese, German, Italian, Spanish, French, Turkish and Russian. \item[\bugfix] Improved error analysis for rules and directives. \item[\newfeature] Friendly and very detailed messages instead of generic ones. \item[\newfeature] An optional configuration file is now available in order to customize and enhance the application behaviour. \item[\bugfix] Improved rule syntax, new keys added. \item[\newfeature] Now rules are unified in a plain format. No more compiled rules. \item[\newfeature] Rules can allow an arbitrary number of commands instead of just one. \item[\newfeature] Built-in functions in the rule context to ease the writing process. \item[\bugfix] Improved expansion mechanism. \end{itemize} {\renewcommand{\arraystretch}{1.5} \begin{table}[ht] \centering \caption{Lines of code for version 3.0.} \begin{tabular}{lrrrr} \hline \textbf{Language} & \textbf{Files} & \textbf{Blank} & \textbf{Comment} & \textbf{Code}\\ \hline \hline Java & 25 & 847 & 2722 & 1659\\ XML & 2 & 12 & 0 & 181\\ \hline Sum & 27 & 859 & 2722 & 1840\\ \hline \end{tabular} \label{tab:locarara30} \end{table}} \subsection*{Version 2.0} \begin{itemize} \item[\newfeature] Added the |--timeout n| flag to allow setting a timeout for every task. If the timeout is reached before the task ends, \arara will kill it and interrupt the processing. The $n$ value is expressed in milliseconds. \item[\bugfix] Fixed the |--verbose| flag to behave as a realtime output. \item[\newfeature] There's no need of noninteractive commands anymore. \arara can now handle user input through the |--verbose| tag. If the flag is not set and the command requires user interaction, the task execution is interrupted. \item[\bugfix] Fixed the execution of some script-based system commands to ensure cross-platform compatibility. \item[\newfeature] Added the |@{SystemUtils}| orb tag to provide specific operating system checks. The orb tag maps the |SystemUtils| class from the amazing \href{http://commons.apache.org/lang/}{Apache Commons Lang} library and all of its methods and properties. \end{itemize} {\renewcommand{\arraystretch}{1.5} \begin{table}[ht] \centering \caption{Lines of code for version 2.0.} \begin{tabular}{lrrrr} \hline \textbf{Language} & \textbf{Files} & \textbf{Blank} & \textbf{Comment} & \textbf{Code}\\ \hline \hline Java & 20 & 608 & 1642 & 848\\ XML & 1 & 0 & 0 & 12\\ \hline Sum & 21 & 608 & 1642 & 860\\ \hline \end{tabular} \label{tab:locarara20} \end{table}} \subsection*{Version 1.0.1} \begin{itemize} \item[\newfeature] Added support for |.tex|, |.dtx| and |.ltx| files. When no extension is provided, \arara will automatically look for these extensions in this specific order. \item[\newfeature] Added the |--verbose| flag to allow printing the complete log in the terminal. A short |-v| tag is also available. Both |stdout| and |stderr| are printed. \item[\bugfix] Fixed exit status when an exception is thrown. Now \arara also returns a non-zero exit status when something wrong happened. Note that this behaviour happens only when \arara is processing a file. \end{itemize} {\renewcommand{\arraystretch}{1.5} \begin{table}[ht] \centering \caption{Lines of code for version 1.0.1.} \begin{tabular}{lrrrr} \hline \textbf{Language} & \textbf{Files} & \textbf{Blank} & \textbf{Comment} & \textbf{Code}\\ \hline \hline Java & 20 & 585 & 1671 & 804\\ XML & 1 & 0 & 6 & 12\\ \hline Sum & 21 & 585 & 1677 & 816\\ \hline \end{tabular} \label{tab:locarara101} \end{table}} \subsection*{Version 1.0} \begin{itemize} \item[\newfeature] First public release. \end{itemize} {\renewcommand{\arraystretch}{1.5} \begin{table}[ht] \centering \caption{Lines of code for version 1.0.} \begin{tabular}{lrrrr} \hline \textbf{Language} & \textbf{Files} & \textbf{Blank} & \textbf{Comment} & \textbf{Code}\\ \hline \hline Java & 20 & 524 & 1787 & 722\\ XML & 1 & 0 & 6 & 12\\ \hline Sum & 21 & 524 & 1793 & 734\\ \hline \end{tabular} \label{tab:locarara10} \end{table}} % ------------------------------------------------- \cleardoublepage % License % ------------------------------------------------- \section*{License} \label{sec:license} \arara is licensed under the \href{http://www.opensource.org/licenses/bsd-license.php}{New BSD License}. It's important to observe that the New BSD License has been verified as a GPL-compatible free software license by the \href{http://www.fsf.org/}{Free Software Foundation}, and has been vetted as an open source license by the \href{http://www.opensource.org/}{Open Source Initiative}. \vspace{1.5em} \ornamentline \vfill \begin{mdframed}[roundcorner=10pt,linecolor=araracolor,middlelinewidth=1pt] \noindent \begingroup \color{araracolor}\fontfamily{fco}\bfseries \arara \ -- the cool \TeX{} automation tool \endgroup \vspace{.5em} \noindent Copyright \copyright{} 2012, Paulo Roberto Massa Cereda \noindent All rights reserved. \vspace{1em} \noindent Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: \vspace{1em} \begin{itemize} \item Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. \item Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. \end{itemize} \vspace{1em} \noindent\textsc{This software is provided by the copyright holders and contributors ``as is'' and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the copyright holder or contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.} \end{mdframed} % ------------------------------------------------- \cleardoublepage \vspace*{25em} \begin{flushright} \em To my cat Fubá, who loves birds. \end{flushright} \cleardoublepage % TOC and list of codes % ------------------------------------------------- \tableofcontents* \cleardoublepage \listoffigures* \cleardoublepage \listoftables* \cleardoublepage \listofcodes* % ------------------------------------------------- \mainmatter \part{The application} \label{part:application} \chapter{Introduction} \label{chap:introduction} \epigraph{\emph{You can do such a lot with a Wompom, you can use every part of it too. For work or for pleasure, it's a triumph, it's a treasure, oh there's nothing that a Wompom cannot do.}}{Flanders \& Swann} Hello there, welcome to \arara! I'm glad you were not intimidated by the threatening message in the prologue. This chapter is actually a quick introduction to what you can expect from \arara. Don't be afraid, it will be easy to digest, I promise. \section{What is \texorpdfstring{\arara}{arara}?} \label{sec:whatisarara} Good question! \arara is a \TeX\ automation tool based on rules and directives. It is, in some aspects, similar to other well-known tools like |latexmk|~\cite{collins:2001} and |rubber|~\cite{rubber:2009}. The key difference might be the fact that \arara aims at explicit instructions in the source code in order to determine what to do instead of relying on other resources, such as log file analysis. It's a different approach for an automation tool, and we have both advantages and disadvantages of such decision. Let's talk about disadvantages first. Since we need to explicitly tell \arara what we want it to do, it might not be intuitive for casual users. Tools like |latexmk| and |rubber| rely on a analysis scheme in which the document is generated with a simple call to |latexmk mydoc.tex| or |rubber --pdf mydoc.tex|, while a similar call to |arara mydoc.tex| does absolutely nothing; it's not wrong, it's by design: \arara needs to know what you want. We do this by adding a directive in our |.tex| file, as shown in line~1 of Code~\ref{code:hellolatex}. Don't worry with the terms now, we will come back to the concepts later on in this manual, in Chapter~\ref{chap:importantconcepts}. \begin{code}[htbp] \caption{\mycmd{mydoc.tex}} \label{code:hellolatex} \begin{latex} % (*@@*)arara: pdflatex \documentclass{article} \begin{document} Hello world. \end{document} \end{latex} \end{code} When we add a directive in our source code, we are explicitly telling \arara what we want it to do, but I'm afraid that's not sufficient. So far, \arara knows \emph{what} to do, but now it needs to know \emph{how} the task should be done. Then, for every directive, we need to have an associated rule. In other words, if we want \arara to run |pdflatex| on |mydoc.tex|, we need to have a set of instructions which tells our tool how to run that specific application. Although the core team provides a lot of rules shipped with \arara out of the box, with the possibility of extending the set by adding more rules, some users might find this decision rather annoying, since other tools have most of their rules hardcoded, making the automation process even more transparent. Now, let's talk about some advantages. In my humble opinion, since \arara doesn't rely on a specific automation or compilation scheme, it becomes more extensible. The use of directives in the source code make the automation steps more fluent, which allows the specification of complex workflows very easily. Maybe \arara's verbosity on automation steps might not be suitable for small documents, but the tool really shines when you have a document which needs full control of the automation process. Another advantage that comes to my mind right now is the fact that directives and rules can be parametrized. In other words, you can create conditional branches, execution workflows based on parameters, flags, and so on, by simply providing a parameter in a directive. Besides, \arara also provides a lot of helper functions in order to enhance rules; for example, you can have a rule which executes a certain command when in Windows, and a different one when in Unix. The rules are written in a human-readable format. The reason for this decision came as an attempt to simplify the life of many casual users which are not versed into programming. Sadly, writing complex XML mappings or even deliberately injecting code into an application is not a trivial task, so we opted for an easy way of declaring the set of instructions that tells \arara how to do a task. We will discuss about the format later on, in Section~\ref{sec:rules}. Now that \arara was properly introduced, let me explain the meaning of the name. \emph{Arara} is the Brazilian name of a macaw bird (Figure~\ref{fig:arara}). Have you ever watched \emph{Rio: the movie}, produced by Blue Sky Studios? The protagonist is a blue arara. The word \emph{arara} comes from the Tupian word \emph{a'rara}, which means \emph{big bird}~\cite{tupi:2012}. \begin{figure}[htbp] \centering \includegraphics[scale=0.6]{figures/arara.png} \caption{A lovely photo of an arara.} \label{fig:arara} \end{figure} Lovely bird, isn't it? Now, you are probably wondering why I chose this name. Well, araras are colorful, noisy, naughty and very funny. Everybody loves araras. So why can't you love a tool with the very same name? And there is also another motivation of the name \emph{arara}: the chatroom residents of \href{http://chat.stackexchange.com/rooms/41}{\TeX.sx} -- including myself -- are fans of palindromes, especially palindromic numbers. As you can already tell, \emph{arara} is a palindrome. \section{How does it work?} \label{sec:howdoesitwork} Now that we know what \arara is, let's take a look on how the tool actually works. The whole idea is pretty straightforward, but some concepts might be confusing at first. Do not despair, we will come back to them later on in the manual, in Chapter~\ref{chap:importantconcepts}. First of all, we need to add at least one instruction in the source code to tell \arara what to do. This instruction is named \emph{directive} and it will be parsed during the preparation phase. By default, an \arara directive is defined in a line of its own, started with a comment, followed by the word |arara:| and the name of the task. Code~\ref{code:hellolatex} has one directive, referencing |pdflatex|. It's important to observe that |pdflatex| is not the command to be executed, but the name of the rule associated with that directive. Once \arara finds a directive, it will look for the associated \emph{rule}. In our example, it will look for a rule named |pdflatex| which will evidently run the |pdflatex| command line application. The rule is analyzed, all possible parameters are defined, the command line call is built and then it goes to a queue of commands to be executed. After extracting all directives from a source code and mapping each one of them to their respective rules, \arara then executes the queue of commands. The execution chain requires that the command $i$ was successfully executed to then proceed to the command $i+1$, and so forth. This is also by design: \arara will halt the execution if any of the commands in the queue had raised an error. If we run \arara on |mydoc.tex| -- we can also run |arara mydoc| too, we will discuss this later on -- presented in Code~\ref{code:hellolatex}, we get the output presented in Code~\ref{code:araraoutputexample}. \begin{code}[htbp] \caption{Running \arara on \mycmd{mydoc.tex}.} \label{code:araraoutputexample} \begin{bash} $ arara mydoc __ _ _ __ __ _ _ __ __ _ / _` | '__/ _` | '__/ _` | | (_| | | | (_| | | | (_| | \__,_|_| \__,_|_| \__,_| Running PDFLaTeX... SUCCESS \end{bash} \end{code} That is pretty much how \arara works: directives in the source code are mapped to rules, which are converted to commands and added to a queue. The queue is then executed and the status is reported. We will cover more details about the expansion process later on in the manual. In short, we teach \arara to do a task by providing a rule, and tell it to execute it via directives in the source code. \section{Features} \label{sec:features} To name a few features I like in \arara, I'd mention the ability to write rules in a human-readable format called YAML, which rhymes with the word \emph{camel}. YAML is actually a recursive acronym for \emph{YAML Ain't Markup Language}, and it's known as a human friendly data serialization standard for all programming languages~\cite{yaml:2001}. So far, I think this format is quite suitable to write rules, specially if you want to avoid the need of writing complicated XML mappings or even injecting code directly into the application. Another feature worth mentioning is the fact that \arara is platform independent. The application was written in Java, so \arara runs on top of a Java virtual machine, available on all the major operating systems~--~in some cases, you might need to install the proper virtual machine. We tried very hard to keep both code and libraries compatible with older virtual machines or from other vendors. Currently, \arara is known to run on Oracle's Java 5, 6 and 7, and OpenJDK 6 and 7. In Chapter~\ref{chap:buildingfromsources}, there are instructions on how to build \arara from sources. Even if you use multiple operating systems, \arara should behave the same, including the rules. There are helper functions available in order to provide support for system-specific rules based on the underlying operating system, presented in Section~\ref{sec:functions}. From version 3.0 on, \arara can now display localized messages. The default language is set to English, but the user can receive feedback from the execution process and logging in other languages as well, such as Brazilian Portuguese, German, Italian, French, Spanish, Russian and Turkish. There's also a way to redefine the default language by adding an entry in the configuration file, discussed later on in Section~\ref{sec:language}. Speaking of which, \arara has now an optional configuration file in which we can add rule paths, set the default language and define custom extensions and directive patterns, located in the user home directory. That way, we can extend \arara's behaviour to deal with other extensions, such as |.c| files, and use the tool with other formats. We will come back on this subject later on in Chapter~\ref{chap:configurationfile}. \arara is also easily integrated with other \TeX\ integrated development environment, such as \TeX works~\cite{texworks:2009}, an environment for authoring \TeX\ documents shipped with both \TeX\ Live and MiK\TeX. Chapter~\ref{chap:ideintegration} covers the integration of \arara with several environments. \section{Common uses} \label{sec:commonuses} \arara can be used in complex workflows, like theses and books. You can tell \arara to compile the document, generate indices and apply styles, remove temporary files, compile other |.tex| documents, create glossaries, call |pdfcrop|, move files, run \hologo{METAPOST} or \hologo{METAFONT}, and so forth. You can easily come up with your own rules. There's an \href{http://latex-community.org/know-how/435-gnuplot-arara}{article} available in the \LaTeX\ community which describes the integration of |gnuplot| and \arara~\cite{cereda:2012}. This article was submitted as an entry to a contest organized by Stefan Kottwitz. It might be worth a read. Let's see a few examples. Code~\ref{code:exlatexone} contains the workflow I used for another article I recently wrote. Note that the first call to |pdflatex| creates the |.aux| file, then |bibtex| will extract the cited publications. The next calls to |pdflatex| will insert and refine the references. \begin{code}[htbp] \caption{\mycmd{article.tex}} \label{code:exlatexone} \begin{latex} % (*@@*)arara: pdflatex % (*@@*)arara: bibtex % (*@@*)arara: pdflatex % (*@@*)arara: pdflatex \documentclass[journal]{IEEEtran} ... \end{latex} \end{code} Code~\ref{code:exlatextwo} contains another workflow I used for a manual. I had to use a package that required shell escape, so the calls to |pdflatex| had to enable it. Also, I had an index with a custom formatting, then |makeindex| was called with the proper style. \begin{code}[htbp] \caption{\mycmd{manual.tex}} \label{code:exlatextwo} \begin{latex} % (*@@*)arara: pdflatex: { shell: yes } % (*@@*)arara: makeindex: { style: mystyle } % (*@@*)arara: pdflatex: { shell: yes } % (*@@*)arara: pdflatex: { shell: yes } \documentclass{book} ... \end{latex} \end{code} And of course, the \arara user manual is also compiled with |arara|. You can take a look in the source code and check the header. By the way, note that I had to use a trick to avoid |arara| to read the example directives in this manual. As we will see later, \arara reads directives everywhere. Actually, I could have changed the directive pattern for |.tex| files through the configuration file, but that's another story. Other workflows can be easily created. There can be an arbitrary number of instructions for \arara to execute, so feel free to come up with your own workflow. \arara will handle it for you. My friend Joseph Wright wrote a great article about \arara in his personal blog, it's really worth a read~\cite{wright:2012}. I really hope you like my humble contribution to the \TeX\ community. Let \arara enhance your \TeX\ experience, it will help you when you'll need it the most. Enjoy the manual. \printbibliography[heading=subbibliography] \chapter{Installation} \label{chap:installation} \epigraph{\emph{Adjust \texttt{\string\hsize}: old man Fermat couldn't.}}{Enrico Gregorio} Spledid, so you decided to give \arara a try? This chapter will cover the installation procedure. We basically have two methods of installing \arara: the first one is through a cross-platform installer, which is of course the recommended method; the second one is a manual deployment, with the provided |.jar| file -- a self-contained, batteries-included executable Java archive file. If you have a recent \TeX\ Live distribution, good news: \arara is already available in your system! \section{Prerequisites} \label{sec:prerequisites} I know I've mentioned this before in Section~\ref{sec:features} and, at the risk of being repetitive, there we go again: \arara is written in Java and thus depends on a virtual machine in the underlying operating system. If you use a Mac or even a fairly recent Linux distribution, I have good news for you: it's mostly certain that you already have a Java virtual machine installed. It's very easy to check if you have a Java virtual machine installed: try running |java -version| in the terminal (bash, command prompt, you name it) and see if you get an output similar to the one provided in Code~\ref{code:javainstalled}. \begin{code}[htbp] \caption{Checking if \mycmd{java} is installed.} \label{code:javainstalled} \begin{bash} $ java -version java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.1) OpenJDK Client VM (build 20.0-b12, mixed mode) \end{bash} \end{code} If the output goes along the lines of |java: command not found|, I'm afraid you don't have a Java virtual machine installed in your operating system. Since the virtual machine is a prerequisite for \arara to run, you can install one via your favorite package manager or manually install it from the binaries available in the official \href{http://www.java.com}{Java website}. Make sure to download the correct version for your operating system. The installation procedure is very straightforward. If you get stuck, take a look on the installation instructions. It's important to mention that \arara runs also with the Java virtual machine from the OpenJDK project~\cite{openjdk:2006}, which is already available in most of the recent Linux distributions -- actually the output from Code~\ref{code:javainstalled} shows the OpenJDK version from my Fedora machine. Feel free to use the virtual machine you feel most comfortable with. Speaking of virtual machines, \arara requires at least Java 5 to run. Don't worry, it's quite easy to spot the Java version: just look at the second digit of the version string. For example, Code~\ref{code:javainstalled} outputs |1.6.0_24|, which means we have Java 6 installed. \section{Obtaining \texorpdfstring{\arara}{arara}} \label{sec:obtainingarara} Before proceeding, we need to choose the installation method. We have two options: the first option is the easiest one, which installs \arara through a cross-platform installer; the second option is a manual deployment. From version 3.0 on, \arara is also available as part of the \TeX\ Live distribution. If you have a recent \TeX\ distro, it's almost certain that you already have \arara; make sure to select it in the |tlmgr| application. If we opt for the installer, go to the \href{http://github.com/cereda/arara/downloads}{downloads} section of the project repository and download |arara-3.0-installer.jar| for all operating systems or |arara-3.0-installer.exe| for Windows. Please note that the |.exe| version is only a wrapper which will launch |arara-3.0-installer.jar| under the hood. The installer also requires Java. If we want to do things the complicated way, go to the \href{http://github.com/cereda/arara/downloads}{downloads} section of the project repository and download the |arara.jar| file, which is a self-contained, batteries-included executable Java archive file. In case you want to build \arara from source, please refer to Chapter~\ref{chap:buildingfromsources} which will cover the whole process. Thanks to Apache Maven, the build process is very easy. \section{Using the cross-platform installer} \label{sec:usingthecrossplatforminstaller} After downloading |arara-3.0-installer.jar| (or its |.exe| counterpart), it's now just a matter of running it. The installer is built with IzPack~\cite{izpack:2001}, an amazing tool for packaging applications on the Java platform. Of course the source is also available at the project repository. Personally, I suggest you to run the installer in privileged mode, but you can also run it in user mode -- just keep in mind that some features might not work, like creating symbolic links or adding the application to the system path, which inevitably requires a privileged mode. When running |arara-3.0-installer.jar| or its |.exe| wrapper on Windows by simply double-clicking it, the installer will automatically run in privileged mode. A general Unix-based installation can be triggered by the command presented in Code~\ref{code:runinstaller1}. There's also an alternative command presented in Code~\ref{code:runinstaller2}. \begin{code}[htbp] \caption{Running the installer in a Unix-based system -- method 1.} \label{code:runinstaller1} \begin{bash} $ sudo java -jar arara-3.0-installer.jar \end{bash} \end{code} \begin{code}[htbp] \caption{Running the installer in a Unix-based system -- method 2.} \label{code:runinstaller2} \begin{bash} $ su -c 'java -jar arara-3.0-installer.jar' \end{bash} \end{code} Since Windows doesn't have a similar command to |su| or |sudo|, you need to open the command prompt as administrator and then run the command presented in Code~\ref{code:runinstallerwin}. You can right-click the command prompt shortcut and select the ``Run as administrator\ldots'' option. \begin{code}[htbp] \caption{Running the installer in the Windows command prompt as administrator.} \label{code:runinstallerwin} \begin{bash} C:\> java -jar arara-3.0-installer.jar \end{bash} \end{code} The installation process will begin. Hopefully, the first screen of the installer will appear, which is the language selection (Figure~\ref{fig:instlang}). By the way, if you called the installer through the command line, please do not close the terminal! It might end the all running processes, including our installer. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-langsel.png} \caption{Language selection screen.} \label{fig:instlang} \end{figure} The installer currently supports six languages: English, German, French, Italian, Spanish, and Brazilian Portuguese. I plan to add more languages to the list in the near feature. The next screen welcomes you to the installation (Figure~\ref{fig:instwelcome}). There's the application name, the current version, the team, and the project homepage. We can proceed by clicking the \textit{Next} button. Note that you can quit the installer at any time by clicking the \textit{Quit} button -- please, don't do it; a kitten dies every time you abort the installation\footnote{Of course, this statement is just a joke. No animals were harmed, killed or severely wounded during the making of this user manual. After all, \arara is environmentally friendly.}. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-welcome.png} \caption{Welcome screen.} \label{fig:instwelcome} \end{figure} Moving on, the next screen shows the license agreement (Figure~\ref{fig:instlicense}). \arara is licensed under the \href{http://www.opensource.org/licenses/bsd-license.php}{New BSD License}~\cite{bsd:2012}. It's important to observe that the New BSD License has been verified as a GPL-compatible free software license by the Free Software Foundation~\cite{fsf:1985}, and has been vetted as an open source license by the Open Source Initiative~\cite{osi:1998}. The full license is also available in this document (page~\pageref{sec:license}). You need to accept the terms of the license agreement before proceeding. The next screen is probably the most important section of the installation: in here we will choose the packs we want to install (Figure~\ref{fig:instpacks}). All packs are described in Table~\ref{tab:packs}. Note that the grayed packs are required. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-packs.png} \caption{Packs screen.} \label{fig:instpacks} \end{figure} \begin{table}[htbp] \centering \caption{Available packs.} \label{tab:packs} \renewcommand{\arraystretch}{1.5} \footnotesize \begin{tabular}{p{0.30\textwidth}p{0.12\textwidth}p{0.4\textwidth}} \hline \textbf{Pack name} & \textbf{OS} & \textbf{Description} \\ \hline \hline Main application & All & This pack contains the core application. It also provides an |.exe| wrapper for Windows and a bash file for Unix. \\ \hline Include the \arara user manual & All & This pack installs this user manual into the |docs/| subdirectory of \arara. \\ \hline Include predefined rules & All & Of course, \arara has a set of predefined rules for you to start with. If you prefer to write your own rules from scratch, do not select this pack. \\ \hline Add a symbolic link to \arara in |/usr/local/bin| & Unix & If you ran the installer in privileged mode, a symbolic link to \arara can be created in the |/usr/local/bin| directory. There's no magic here, the installer uses the good old |ln| command. \\ \hline Add \arara to the system path & Windows & Like the Unix task, \arara can also add itself to the system path. This feature is provided by a Windows script named \href{http://legroom.net/software/modpath}{Modify Path}~\cite{modpath:2012}. \\ \hline \end{tabular} \end{table} It's very important to mention that all these modifications in the operating system -- the symbolic link creation for Unix or the addition to the path for Windows -- are safely removed when you run the \arara uninstaller. We will talk about it later, in Section~\ref{sec:uninstallingarara}. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-license.png} \caption{License agreement screen.} \label{fig:instlicense} \end{figure} In the next screen, we will select the installation path (Figure~\ref{fig:instpath}). The installer will automatically set the default installation path according to the Table~\ref{tab:paths}, but feel free to install \arara in your favorite structure -- even |/opt| or your home folder. \begin{table}[htbp] \centering \caption{Default installation paths.} \label{tab:paths} \renewcommand{\arraystretch}{1.5} \begin{tabular}{cl} \hline \textbf{OS} & \textbf{Default installation path}\\ \hline \hline Windows & |C:\Program Files\arara|\\ Unix & |/usr/local/arara|\\ \hline \end{tabular} \end{table} \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-path.png} \caption{Installation path screen.} \label{fig:instpath} \end{figure} After selecting the installation path, the installer will then confirm the creation of the target directory (Figure~\ref{fig:instnewfolder}). We simply click \textit{OK} to accept it. For convenience, the full installation path defined in the installation path screen (Figure~\ref{fig:instpath}) will be referred as |ARARA_HOME| from now on. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-pathwarning.png} \caption{Target directory confirmation.} \label{fig:instnewfolder} \end{figure} Now, just sit back and relax while \arara is being installed (Figure~\ref{fig:instprogress}). All selected packs will be installed accordingly. The post installation tasks -- like creating the symbolic link or adding \arara to the system path -- are performed here as well. If the installation has completed successfully, we will reach the final screen of the installer congratulating us for installing \arara (Figure~\ref{fig:instfinish}). \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-progress.png} \caption{Progress screen.} \label{fig:instprogress} \end{figure} \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/install-finish.png} \caption{Final screen.} \label{fig:instfinish} \end{figure} The full installation scheme is presented in Figure~\ref{fig:ararastructure}. The directory structure is presented here as a whole; keep in mind that some parts will be omitted according to your operating system and pack selection. For example, the |etc/| subdirectory will only be installed if and only if you are in Windows and the system path pack is selected. Other files are platform-specific, such as |arara.exe| for Windows and the |arara| bash file for Unix. \begin{figure}[htbp] \centering \begin{tikzpicture}[grow via three points={one child at (0.5,-0.7) and two children at (0.5,-0.7) and (0.5,-1.4)}, edge from parent path={(\tikzparentnode.south) |- (\tikzchildnode.west)}, anchor=west, font=\ttfamily] \node {ARARA\_HOME/} child { node {arara.jar}} child { node {arara.exe}} child { node {arara}} child { node {docs/} child { node {arara-usermanual.pdf}} } child [missing] {} child { node {etc/} child { node {modpath.exe}} } child [missing] {} child { node {Uninstaller/} child { node {uninstaller.jar}} } child [missing] {} child { node {rules/} child { node {biber.yaml}} child { node {\ldots}} child { node {xetex.yaml}} }; \end{tikzpicture} \caption{Installation scheme.} \label{fig:ararastructure} \end{figure} That's it, \arara is installed in your operating system. If you opted for the symbolic link creation or the path addition, \arara is already available in your terminal by simply typing |arara|. Have fun! \section{Manual installation} \label{sec:manualinstallation} Thankfully, \arara is also very easy to be manually deployed. First of all, we must create the application directory. Feel free to create this directory anywhere in your computer; it can be |C:\arara|, |/opt/arara| or another location of your choice. This procedure is similar to the installation path screen (Figure~\ref{fig:instpath}) from Section~\ref{sec:usingthecrossplatforminstaller}. Again, for convenience, the full installation path will be referred as |ARARA_HOME| from now on. Although it's not mandatory, try to avoid folders structures with spaces in the path. In any case, \arara can handle such spaces. After downloading |arara.jar| from the \href{http://github.com/cereda/arara/downloads}{downloads} section of the project repository, let's copy it to the |ARARA_HOME| directory we've created in the previous step. Since |arara.jar| is a self-contained, batteries-included executable Java archive file, \arara is already installed. In order to run \arara from a manual installation, we should open a terminal and run |java -jar $ARARA_HOME/arara.jar|, but that is far from being intuitive. To make our lives easier, we will create a shortcut for this command. If you are deploying \arara in Windows, there are two methods for creating a shortcut: the first method -- the easiest -- consists of downloading the |arara.exe| wrapper from the \href{http://github.com/cereda/arara/downloads}{downloads} section and copying it to the |ARARA_HOME| directory, in the same level of |arara.jar|. This |.exe| wrapper, provided by \href{http://launch4j.sourceforge.net}{Launch4J}~\cite{launch4j:2005}, wraps |.jar| files in Windows native executables and allows to run them like a regular Windows program. The second method for creating a shortcut in Windows is to provide a batch file which will call |java -jar $ARARA_HOME/arara.jar| for us. Create a file named |arara.bat| or |arara.cmd| inside the |ARARA_HOME| directory, in the same level of |arara.jar|, and add the content from Code~\ref{code:windows}. \begin{code}[htbp] \caption{Creating a batch file for \arara in Windows.} \label{code:windows} \begin{bash} @echo off java -jar "%~dp0\arara.jar" %* \end{bash} \end{code} After creating the batch file, add the full |ARARA_HOME| path to the system path. Unfortunately, this manual can't cover the path settings, since it's again a matter of personal taste. I'm sure you can find tutorials on how to add a directory to the system path. If you are deploying \arara in Linux or Mac, we also need to create a shortcut to |java -jar $ARARA_HOME/arara.jar|. Create a file named |arara| inside the |ARARA_HOME| directory, in the same level of |arara.jar|, and add the content from Code~\ref{code:unix}. \begin{code}[htbp] \caption{Creating a script for \arara in Linux and Mac.} \label{code:unix} \begin{bash} #!/bin/bash # Example script of arara # Installation and usage are described in the documentation SOURCE="${BASH_SOURCE[0]}" while [ -h "$SOURCE" ] ; do SOURCE="$(readlink "$SOURCE")"; done DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && cd -P "$( dirname "$SOURCE" )" && pwd )" java -jar "$DIR/arara.jar" "$@" \end{bash} \end{code} We now need to add execute permissions for our newly created script through |chmod +x arara|. The |arara| script can be invoked through path addition or symbolic link. I personally prefer to add |ARARA_HOME| to my user path, but a symbolic link creation seems way more robust -- it's what the installer does. Anyway, it's up to you to decide which method you want to use. There's no need to use both. Once we conclude the manual installation, it's time to check if \arara is working properly. Try running |arara| in the terminal and see if you get the output shown in Code~\ref{code:arararun}. \begin{code}[p] \caption{Testing if \arara is working properly.} \label{code:arararun} \begin{nolanguage} $ arara __ _ _ __ __ _ _ __ __ _ / _` | '__/ _` | '__/ _` | | (_| | | | (_| | | | (_| | \__,_|_| \__,_|_| \__,_| arara 3.0 - The cool TeX automation tool Copyright (c) 2012, Paulo Roberto Massa Cereda All rights reserved. usage: arara [file [--log] [--verbose] [--timeout N] [--language L] | --help | --version] -h,--help print the help message -L,--language set the application language -l,--log generate a log output -t,--timeout set the execution timeout (in milliseconds) -v,--verbose print the command output -V,--version print the application version \end{nolanguage} \end{code} If the terminal doesn't display the \arara logo and usage, please review the manual installation steps. Every step is important in order to make \arara available in your system. You can also try the cross-platform installer. If you still have any doubts, feel free to contact us. \section{Updating \texorpdfstring{\arara}{arara}} \label{sec:updatingarara} If there is a newer version of \arara available in the \href{http://github.com/cereda/arara/downloads}{downloads} section of the project repository, simply download the |arara.jar| file and copy it to the |ARARA_HOME| directory, replacing the current one. No further steps are needed, the newer version is deployed. Try running |arara --version| in the terminaland see if the version shown in the output is equal to the one you have downloaded. Anyway, for every version, \arara has the proper cross-platform installer available for download in the project repository. You can always uninstall the old \arara setup and install the new one. Please note that only major versions are released with the installer. If you have \arara through the \TeX\ Live distribution, the update process is straightforward: simply open a terminal and run |tlmgr update arara| in order to update the application. This is of course the preferred method. \section{Uninstalling \texorpdfstring{\arara}{arara}} \label{sec:uninstallingarara} If you want to uninstall \arara, there are two methods available. If you installed \arara through the cross-platform installer, I have good news for you: it's just a matter of running the uninstaller. Now, if \arara was deployed through the manual installation, we might have to remove some links or path additions. A general Unix-based uninstallation can be triggered by the command presented in Code~\ref{code:uninstall1}. There's also an alternative command presented in Code~\ref{code:uninstall2}. \begin{code}[htbp] \caption{Running the uninstaller in a Unix-based system -- method 1.} \label{code:uninstall1} \begin{bash} $ sudo java -jar $ARARA_HOME/Uninstaller/uninstaller.jar \end{bash} \end{code} \begin{code}[htbp] \caption{Running the uninstaller in a Unix-based system -- method 2.} \label{code:uninstall2} \begin{bash} $ su -c 'java -jar $ARARA_HOME/Uninstaller/uninstaller.jar' \end{bash} \end{code} Since Windows doesn't have a similar command to |su| or |sudo|, you need to open the command prompt as administrator and then run the command presented in Code~\ref{code:uninstallwin}. You can right-click the command prompt shortcut and select the ``Run as administrator\ldots'' option. \begin{code}[htbp] \caption{Running the uninstaller in the Windows command prompt as administrator.} \label{code:uninstallwin} \begin{bash} C:\> java -jar $ARARA_HOME/Uninstaller/uninstaller.jar \end{bash} \end{code} The uninstallation process will begin. Hopefully, the first and only creen of the uninstaller will appear (Figure~\ref{fig:uninstallone}). By the way, if you called the uninstaller through the command line, please do not close the terminal! It might end the all running processes, including our uninstaller. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/uninstall-welcome.png} \caption{The uninstaller screen.} \label{fig:uninstallone} \end{figure} There's nothing much to see in the uninstaller. We have an option to force the deletion of the |ARARA_HOME| directory, but that's all. By clicking the \textit{Uninstall} button, the uninstaller will remove the symbolic link or the path entry for \arara from the operating system, if selected during the installation. Then it will erase the |ARARA_HOME| directory (Figure~\ref{fig:uninstalltwo}). \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/installer/uninstall-finish.png} \caption{The uninstaller screen, after the execution.} \label{fig:uninstalltwo} \end{figure} Unfortunately, even if you force the deletion of the |ARARA_HOME| directory in Windows, the operating system can't remove the |Uninstaller| subdirectory because the uninstaller was being executed from there. But that's the only trace left. You can safely delete |ARARA_HOME| after running the uninstaller. If \arara was manually installed, we need to remove the symbolic link reference or the path entry, if any, then delete the |ARARA_HOME| directory. Don't leave any traces of \arara in system directories or configuration files; a broken symbolic link or a wrong path entry might cause trouble in the future. \printbibliography[heading=subbibliography] \chapter{Building from sources} \label{chap:buildingfromsources} \epigraph{\emph{Knowledge brings fear.}}{From a \emph{Futurama} episode} Although \arara already features a self-contained, batteries-included executable Java archive file, an |.exe| wrapper, and a cross-platform installer, you can easily build it from sources. The only requirements are a working Java Development Kit~\cite{oracle:2012} and the Apache Maven software project management~\cite{maven:2012}. The next sections will cover the entire process, from obtaining the sources to the build itself. Sadly, this manual doesn't cover Java and Maven deployments, so I kindly ask you to check their websites and read the available documentation. \section{Obtaining the sources} \label{sec:obtainingthesources} First of all, we need to get the source code, available in the project repository hosted on \href{https://github.com/cereda/arara}{GitHub}. We have two options on how to obtain the sources: either by clicking the \href{https://github.com/cereda/arara/archive/master.zip}{Zip} button in the project page and download a snapshot of the whole structure in an archive file, or by using |git| and clone the repository into our machine. The second option is easily done by executing the command presented in Code~\ref{code:gitobtain}, provided of course that you have |git| installed. \begin{code}[htbp] \caption{Cloning the project repository.} \label{code:gitobtain} \begin{bash} $ git clone git://github.com/cereda/arara.git \end{bash} \end{code} After cloning the project repository (Code~\ref{code:gitobtain}), a new subdirectory named |arara| is created in the current directory with the project structure -- the very same available in the project repository on GitHub. The application source code is inside |arara/arara|. Note that there are other source codes for the cross-platform installer and the |.exe| wrapper, as well as the predefined rules, each one in a subdirectory of its own. If you opted for downloading the archive file, you'll have a file named |arara-master.zip| generated automatically by GitHub. Just extract the file somewhere in your computer and you'll end up with the very same project structure as the one available in the project repository. \section{Building \texorpdfstring{\arara}{arara}} \label{sec:buildingarara} Inside the |arara/arara| directory, we have the most important file for building \arara: a file named |pom.xml|. We now just need to call the |mvn| command with the proper target and relax while Maven takes care of the building process for us. First of all, let's take a look at some targets available in our |pom.xml| file: \begin{ruleoptions} \item[compile] This target compiles the source code, generating the Java bytecode. \item[package] The |package| target is very similar to the |compile| one, but instead of only compiling the source code, it also packs the Java bytecode into an executable Java archive file without dependencies. The file will be available inside the |arara/arara/target| directory. \item[assembly:assembly] This target is almost identical to the |package| one, but it also includes all the dependencies into a final Java archive file. The file will be available inside the |arara/arara/target| directory. This is of course our preferred target, since \arara is shipped as a self-contained executable Java archive file. \item[clean] The |clean| target removes all the generated Java bytecode and deployment traces, cleaning the project structure. \end{ruleoptions} Now that we know the targets, we only need to call |mvn| with the target we want. If you want to generate the very same Java archive file we use for releases, execute the command presented in Code~\ref{code:mvnassembly}. \begin{code}[htbp] \caption{Building \arara with Maven, first attempt.} \label{code:mvnassembly} \begin{bash} $ mvn assembly:assembly \end{bash} \end{code} Actually, the command presented in Code~\ref{code:mvnassembly}, as the project structure is at the moment, will fail! Let me explain why: the application is not yet linked with the localized messages, so we need to convert our translation files into a correct format and then run the target in Maven. The error message after running |mvn assembly:assembly| presented in Code~\ref{code:errorlangnotfound} gives us a hint on what we should do. \begin{code}[htbp] \caption{The Maven error message about missing localization files.} \label{code:errorlangnotfound} \begin{bash} Failed tests: testLocalizationFile(com.github.arara.AraraTest): arara requires at least the default localization file Messages.properties located at the translations/ directory in the project repository. Rename Messages.input to Messages.properties and copy the new file to the src/ directory, under com/github/arara/localization, and build arara again. Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 [INFO] --------------------------------------------- [INFO] BUILD FAILURE [INFO] --------------------------------------------- \end{bash} \end{code} Let's go into |arara/translations| and run the commands presented in Code~\ref{code:convertinglocales}. Since we are dealing with languages that require an encoding in UTF-8 while the localization files are set in ASCII, we need to run a conversion program in order to generate valid |.properties| files. \begin{code}[htbp] \caption{Converting the localization files.} \label{code:convertinglocales} \begin{bash} $ native2ascii -encoding utf8 Messages.input ../application/src/main/resources/com/github/arara/localization/Messages.properties $ native2ascii -encoding utf8 Messages_de.input ../application/src/main/resources/com/github/arara/localization/Messages_de.properties $ native2ascii -encoding utf8 Messages_es.input ../application/src/main/resources/com/github/arara/localization/Messages_es.properties $ native2ascii -encoding utf8 Messages_fr.input ../application/src/main/resources/com/github/arara/localization/Messages_fr.properties $ native2ascii -encoding utf8 Messages_it.input ../application/src/main/resources/com/github/arara/localization/Messages_it.properties $ native2ascii -encoding utf8 Messages_pt_BR.input ../application/src/main/resources/com/github/arara/localization/Messages_pt_BR.properties $ native2ascii -encoding utf8 Messages_ru.input ../application/src/main/resources/com/github/arara/localization/Messages_ru.properties $ native2ascii -encoding utf8 Messages_tr.input ../application/src/main/resources/com/github/arara/localization/Messages_tr.properties \end{bash} \end{code} Now we can simply rerun the command presented in Code~\ref{code:mvnassembly}. Hopefully, we won't have trouble this time. Relax while Maven takes care of the building process. It might take a while, since all dependencies will be downloaded to your Maven repository. After a while, Maven will tell us that the project was built successfully! After a successful build via Maven, we can now get the generated executable Java archive file |arara-3.0-with-dependencies.jar| which is inside the |arara/arara/target| directory, rename it to |arara.jar| and use it as we have seen in the previous chapters. \section{Notes on the installer and wrapper} \label{sec:notesontheinstallerandwrapper} The project directory has additional subdirectories regarding the \arara cross-platform installer and the |.exe| wrapper. It's important to observe that only the build files are available, which means that you need to review the compilation process and make adjustments according to your directory structure. The cross-platform installer Java archive file is generated with IzPack~\cite{izpack:2001}, while the |.exe| wrapper is built with Launch4J~\cite{launch4j:2005}. Both build files are written in plain XML, so you can easily adapt them to your needs. Sadly, the main purpose of this chapter is to cover the build process of \arara itself and not its helper tools; if you want to generate your own wrapper or installer, please refer to the available documentation on how to build each file. The build process is also very straightforward. \printbibliography[heading=subbibliography] \chapter{IDE integration} \label{chap:ideintegration} \epigraph{\emph{The answer to ``can Emacs\ldots'' is always ``yes''.}}{David Carlisle} This chapter covers the integration of \arara with several integrated development environments. For obvious reasons, it's almost impossible for us to cover the full range of editors available nowadays, so we tried to focus only on a couple of them. If you use \arara with an IDE other than the ones listed here, please let us know! It would be great to include your contribution in this user manual. \section{\texorpdfstring{\TeX works}{TeXworks}} \label{sex:texworks} \arara can be easily integrated with \TeX works~\cite{texworks:2009}, an environment for authoring \TeX\ documents shipped with both \TeX\ Live and MiK\TeX. In this section, we will learn how to integrate \arara and this cross-platform \TeX\ front-end program. First of all, make sure \arara is properly installed in your operating system. Thankfully, it's very easy to add a new tool in \TeX works, just open the program and click in \textit{Edit} $\rightarrow$ \textit{Preferences\ldots} to open the preferences screen (Figure~\ref{fig:texworkspref}). \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/texworks/texworks-prefs.png} \caption{Opening the preferences screen in \TeX works.} \label{fig:texworkspref} \end{figure} The next screen is the \TeX works preferences (Figure~\ref{fig:texworksprefscreen}). There are several tabs available. Navigate to the \textit{Typesetting} tab, which contains two lists: the paths for \TeX\ and related programs, and the processing tools. In the second list -- the processing tools -- click the \textit{Plus (+)} button to add another tool. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/texworks/texworks-add.png} \caption{The \TeX works preferences screen.} \label{fig:texworksprefscreen} \end{figure} We are now in the new tool screen (Figure~\ref{fig:texworksarara}). \TeX works provides an very straightforward interface for adding new tools; we just need to provide the tool name, the executable path, and the parameters. Table~\ref{tab:texworksarara} helps us on what to type in each field. When done, just click \textit{OK} and our new tool will be available. \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/texworks/texworks-arara.png} \caption{The new tool screen.} \label{fig:texworksarara} \end{figure} {\renewcommand{\arraystretch}{1.5} \begin{table}[htbp] \centering \footnotesize \begin{tabular}{p{0.15\textwidth}p{0.25\textwidth}p{0.50\textwidth}} \hline \textbf{Field name} & \textbf{Value} & \textbf{Description} \\ \hline \hline Name & |arara| & The tool name. You can actually type whatever name your heart desires. This value will be displayed in the compilation profile. \\ \hline Program & |$ARARA_HOME/arara| & The full executable path. Just browse the filesystem and select the correct \arara path. Observe that symbolic links are resolved to their full targets. For Windows, select the |.exe| wrapper; for Unix, select the bash script. \\ \hline Arguments & {\renewcommand{\arraystretch}{1} \begin{tabular}[t]{l} |$fullname|\\ |--verbose|\\ |--log| \end{tabular}} & The tool arguments. Note that you need to type one argument at a time, by clicking the \textit{Plus (+)} button. The first argument is a \TeX works variable which will expand to the current filename. The second and third arguments are \arara flags, discussed later, in Chapter~\ref{chap:runningarara}. \\ \hline \end{tabular} \caption{Configuring \arara in \TeX works.} \label{tab:texworksarara} \end{table}} We are now back to the preferences screen (Figure~\ref{fig:texworksprefscreen}). Hopefully, \arara is in the list of processing tools. Just click \textit{OK} to confirm the new addition. Congratulations, now \arara is available as a compilation profile in \TeX works (Figure~\ref{fig:texworksprofile}). \begin{figure}[htbp] \centering \includegraphics[scale=0.5]{figures/texworks/texworks-profile.png} \caption{Using \arara in the \TeX works compilation profile.} \label{fig:texworksprofile} \end{figure} And we are done, \arara is now integrated with \TeX works! Just make sure to select the correct profile when running the compilation process. \section{WinEdt} \label{sec:winedt} The following procedure is kindly provided by Harish Kumar. It's very easy to integrate \arara with WinEdt, let's take a look at the steps. \subsection{Getting images for icons and toolbar} WinEdt uses $16 \times 16$ |.png| images for menu items, the toolbar and the tree control. They are available in \texttt{\%B\textbackslash Bitmaps\textbackslash Images}\footnote{\texttt{\%B} maps to \texttt{C:\textbackslash Program Files\textbackslash WinEdt Team\textbackslash WinEdt 7} for default installation.} folder and they are automatically loaded on startup or later through the \textit{Options Interface} (or |ReloadImages| macro function). Restricted users can place additional images in their \texttt{\%b\textbackslash Bitmaps\textbackslash Images}\footnote{\texttt{\%b} maps to \texttt{C:\textbackslash Users\textbackslash \textbackslash AppData\textbackslash Roaming\textbackslash WinEdt Team\textbackslash WinEdt 7} for default installation} folder. At the moment all images have a $16\times16$ dimension and use 32-bit transparent |.png| format. The images for the \arara toolbar can be downloaded from the \href{http://github.com/cereda/arara/downloads}{downloads area} of the project repository. It would suffice to have a $16 \times 16$ |.png| image for WinEdt v7 while for WinEdt v6, one has to use $16 \times 16$ |.bmp| image. The downloaded images must be copied to \texttt{\%B\textbackslash Bitmaps\textbackslash Images} or \texttt{\%b\textbackslash Bitmaps\textbackslash Images} (depending upon the admin privileges). Once copied, WinEdt has to be restarted to load the images. Now the images should be available for use. \subsection{Adding a menu entry} The following steps describe how to add a menu entry for \arara in WinEdt v6 and v7. \begin{enumerate} \item Go to \textit{Options $\rightarrow$ Options Interface}. A side window will appear on the left side as shown in Figure~\ref{fig:optionsinterface}. \item From the \textit{Menus and Toolbar} drop down list, select \textit{Main Menu} and double click to open the file |Main Menu.ini|. \item In the |Main Menu.ini| file, type the code presented in Code~\ref{code:mainmenuwinedt} somewhere in the file. \item Save the file. Now the current script has to be loaded by clicking the \textit{Load current script} button, which is the first button in the tool bar in \textit{Options Interface} window shown in Figure~\ref{fig:optionsinterface}. \item Now in the WinEdt \textit{\TeX} menu, a submenu called \textit{Arara} should be visible and functional (Figure~\ref{fig:winedtmenu}). \item From the \textit{Menus and Toolbar} drop down list, select \textit{Toolbar} and double click to open the file |Toolbar.ini|. \item In the |Toolbar.ini| file, type the following line, somewhere in the file: |BUTTON="arara"|. \item Save the file |Toolbar.ini|. Now the current script has to be loaded by clicking the \textit{Load current script} button, which is the first button in the tool bar in \textit{Options Interface} window (Figure~\ref{fig:optionsinterface}). \item Now a button for \arara should be visible as shown in Figure~\ref{fig:wineditararabutton}. \end{enumerate} \begin{figure}[htbp] \centering \includegraphics[width=.4\textwidth]{figures/winedt/winedt-optionsinterface.png} \caption{The \textit{Options Interface} window in WinEdt.} \label{fig:optionsinterface} \end{figure} \begin{code}[htbp] \caption{Adding an entry to \arara in \mycmd{Main Menu.ini}.} \label{code:mainmenuwinedt} \begin{lstlisting}[basicstyle=\footnotesize\ttfamily, columns=flexible, showspaces=false, breaklines=true] ITEM="Arara" CAPTION="Arara" IMAGE="arara16" SAVE_INPUT=1 MACRO=:RunConsole('arara "\%F"','\%P','arara...'); REQ_FILTER=:"\%!M=TeX"|"\%!M=TeX:STY"|"\%!M=TeX:AUX" \end{lstlisting} \end{code} \begin{figure}[htbp] \centering \includegraphics[width=.7\textwidth]{figures/winedt/winedt-menu.png} \caption{The WinEdt \textit{\TeX} menu.} \label{fig:winedtmenu} \end{figure} \begin{figure}[htbp] \centering \includegraphics[width=.5\textwidth]{figures/winedt/winedt-ararabutton.png} \caption{The \arara button in WinEdt.} \label{fig:wineditararabutton} \end{figure} And we are done! \arara is successfully integrated in WinEdt. Now you can add directives to your files and click the buttons to trigger the execution. \section{Inlage} \label{sec:inlage} The following procedure is kindly provided by Harish Kumar. It's very easy to integrate \arara with Inlage, let's take a look at the steps. \subsection{Inlage v4} The following steps describe how to add a menu entry for \arara in Inlage v4. It's an easy procedure. \begin{enumerate} \item Go to \textit{Build $\rightarrow$ User Commands}. A window named \textit{Edit Commands} will appear as shown in Figure~\ref{fig:inlageeditcommands}. \item Now press the \textit{Plus (+)} button to get the \textit{Add Command} window as shown in Figure~\ref{fig:inlageaddcommand}. \item Under the \textit{Name} textfield, type |arara| and under the \textit{Command Line} textarea, type |arara \%f|. Now the new configuration should be saved using the \textit{Save} button. Now an entry for \arara should be visible as seen in Figure~\ref{fig:inlagelistarara}. \item These settings must be then updated using the \textit{Update} button in the \textit{Edit Commands} window shown in Figure~\ref{fig:inlageeditcommands}. \item Now a menu entry for \arara should be visible in \textit{Build $\rightarrow$ Execute $\rightarrow$ arara}. \end{enumerate} \begin{figure}[htbp] \centering \includegraphics[width=.4\textwidth]{figures/inlage/inlage-editcommands.png} \caption{The \textit{Edit Commands} window in Inlage.} \label{fig:inlageeditcommands} \end{figure} \begin{figure}[htbp] \centering \includegraphics[width=.5\textwidth]{figures/inlage/inlage-addcommand.png} \caption{The \textit{Add Command} window in Inlage.} \label{fig:inlageaddcommand} \end{figure} \begin{figure}[htbp] \centering \includegraphics[width=.4\textwidth]{figures/inlage/inlage-listarara.png} \caption{\arara added to the \textit{Edit Commands} window in Inlage.} \label{fig:inlagelistarara} \end{figure} That's it, \arara is now successfully integrated in Inlage v4. Have fun! \subsection{Inlage v5} The following steps describe how to add a menu entry for \arara in Inlage v5. It's an easy procedure. \begin{enumerate} \item Go to \textit{Build $\rightarrow$ Compiler Options\ldots}. A \textit{Settings} window will appear as shown in Figure~\ref{fig:inlagesettings}. \item Under \textit{Profiles}, create a new profile clicking the \textit{New} button. A new window will open; now let's type the name for the new profile as |arara|, as shown in Figure~\ref{fig:inlagenewprofile}. Now press \textit{Okay}. \item Under \textit{Compiler Order}, press \textit{Add Compiler}, as shown in Figure~\ref{fig:inlageaddcompiler}. \item Under \textit{Binaries}, change the following: \begin{enumerate} \item In \textit{Implementation}, choose \textit{Custom}. \item In \textit{Binary Name}, choose the executable for \arara using the \textit{Browse} button. \item In \textit{Parameters}, you can choose the parameters, such as |--verbose|. \item In \textit{Target File}, choose \textit{Active File/Masterfile}. \end{enumerate} \item Save these settings. After the previous steps, you should get a menu for \arara in Inlage v5 as seen in Figure~\ref{fig:inlageararamenu}. \end{enumerate} \begin{figure}[htbp] \centering \includegraphics[width=.7\textwidth]{figures/inlage/inlage-settings.png} \caption{The \textit{Settings} window in Inlage.} \label{fig:inlagesettings} \end{figure} \begin{figure}[htbp] \centering \includegraphics[width=.7\textwidth]{figures/inlage/inlage-newprofile.png} \caption{Adding a new profile in Inlage.} \label{fig:inlagenewprofile} \end{figure} \begin{figure}[htbp] \centering \includegraphics[width=.7\textwidth]{figures/inlage/inlage-addcompiler.png} \caption{Adding a compiler in Inlage.} \label{fig:inlageaddcompiler} \end{figure} \begin{figure}[htbp] \centering \includegraphics[width=.7\textwidth]{figures/inlage/inlage-araramenu.png} \caption{\arara added to the menu in Inlage.} \label{fig:inlageararamenu} \end{figure} That's it, \arara is successfully integrated with Inlage v5. Have fun! \section{\texorpdfstring{\TeX Shop}{TeXShop}} \label{sec:texshop} Integrating \arara with \TeX shop is probably one of the easiest procedures. Simply open your terminal, go to |~/Library/TeXShop/Engines| and create a file named |arara.engine| with the content presented in Code~\ref{code:texshopcode}. Now, we need to add execute permissions to our newly created file. A simple |chmod +x arara.engine| will do the trick. Now, open \TeX shop and you will see \arara available for use in the list of engines (Figure~\ref{fig:texshop}). \begin{figure}[htbp] \centering \includegraphics[width=.8\textwidth]{figures/texshop/texshop-arara.png} \caption{\arara available in \TeX shop.} \label{fig:texshop} \end{figure} No more steps are needed, \arara is successfully deployed in \TeX shop. If you want to remove \arara from \TeX shop, just remove |arara.engine| from the |Engines| directory. \begin{code}[htbp] \caption{\mycmd{arara.engine}} \label{code:texshopcode} \begin{bash} #!/bin/bash export PATH=/usr/texbin:/usr/local/bin:${PATH} arara "$1" \end{bash} \end{code} \section{\texorpdfstring{\TeX nic Center}{TeXnic Center}} \label{sec:texniccenter} \TeX nic Center has also an easy integration with \arara. The first step is to go to \textit{Build $\rightarrow$ Define Output Profiles\ldots}. The \textit{Profiles} window should open, as shown in Figure~\ref{fig:txnprofiles}. \begin{figure}[htbp] \centering \includegraphics[width=.8\textwidth]{figures/texniccenter/texniccenter-profiles.png} \caption{The \textit{Profiles} window in \TeX nic Center.} \label{fig:txnprofiles} \end{figure} Let's now create a new profile! Click the \textit{Add} button. A window will pop up and ask for the new profile name (Figure~\ref{fig:txnnewprofile}). Type |arara| as the profile name and click \textit{OK}. \begin{figure}[htbp] \centering \includegraphics[width=.7\textwidth]{figures/texniccenter/texniccenter-newprofile.png} \caption{Creating a new profile in \TeX nic Center.} \label{fig:txnnewprofile} \end{figure} The last step is the easiest one. With the |arara| profile selected, check the box which says \textit{Run (La)\TeX in this profile}, then enter the full path to |arara| in the textbox named \textit{Path to the (La)\TeX compiler} and write |--log --verbose "%wm"| in the texbox named \textit{Command line arguments to pass to the compiler}; click \textit{OK}, as shown in Figure~\ref{fig:txnsettings}. \begin{figure}[htbp] \centering \includegraphics[width=.8\textwidth]{figures/texniccenter/texniccenter-config.png} \caption{Configuring \arara in \TeX nic Center.} \label{fig:txnsettings} \end{figure} That's it, now \arara is integrated with \TeX nic Center! Just make sure to select |arara| in the dropdown list of available profiles. \printbibliography[heading=subbibliography] \chapter{Important concepts} \label{chap:importantconcepts} \epigraph{\emph{Beware of bugs in the above code; I have only proved it correct, not tried it.}}{Donald Knuth} Time for our first contact with \arara! It's important to understand a few concepts in which \arara relies before we proceed to the usage itself. Do not worry, these concepts are easy to follow, yet they are vital to the comprehension of the application and the logic behind it. \section{Rules} \label{sec:rules} Do you remember |mydoc.tex| from Code~\ref{code:hellolatex} in page~\pageref{code:hellolatex}? When we tried to mimic |rubber| and run |arara mydoc|, nothing happened. We should tell \arara how it should handle this execution. Let's start with the rules. A \emph{rule} is a formal description of how \arara should handle a certain task. For example, if we want to use |pdflatex| with \arara, we should have a rule for that. Once a rule is defined, \arara automatically provides an access layer to that rule through directives, a concept to be introduced in Section~\ref{sec:directives}. A rule is a plain text file written in the YAML format~\cite{yaml:2001}. I opted for this format because it's cleaner and more intuitive to use than other markup languages, besides of course being a data serialization standard for all programming languages. As a bonus, the acronym \emph{YAML} rhymes with the word \emph{camel}, so \arara is heavily environmentally friendly\footnote{Perl, I'm looking at you.}. The default rules, that is, the rules shipped with \arara, are placed inside a special subdirectory named |rules/| inside |ARARA_HOME|. We will learn in Section~\ref{sec:searchpaths} that we can add an arbitrary number of paths for storing our own rules, in order of priority, so don't worry with the location of the default rules, although it's important to understand and acknowledge their existance. The basic structure of an \arara rule is presented in Code~\ref{code:yamlrule}. \begin{code}[htbp] \caption{\mycmd{makefoo.yaml}, a basic structure of an \arara rule.} \label{code:yamlrule} \begin{yaml} !config # I am a comment identifier: makefoo name: MakeFoo command: makefoo @{file} arguments: [] \end{yaml} \end{code} The |!config| keyword (line 1) is mandatory and it must be the first line of any \arara rule. Note that the format also accepts comments (line 2) by simply starting a line with the |#| symbol. The following keys are defined: \begin{ruleoptions} \item[identifier] This key (line 3) acts as a unique identifier for the rule. It's highly recommended to use lowercase letters without spaces, accents or punctuation symbols. As a convention, if you have an identifier named |makefoo|, the rule filename must be |makefoo.yaml|. \item[name] The |name| key (line 4) holds the name of the task. When running \arara, this value will be displayed in the output. In our example, \arara will display |Running MakeFoo| in the output when dealing with this task. \item[command] This key (line 5) contains the system command to be executed. You can use virtually any type of command, interactive or noninteractive. But beware: if \arara is running in silent mode, which is the default behaviour, an interactive command wich might require the user input will be halted and the execution will fail. Don't despair, you can use a special |--verbose| flag with \arara in order to interact with such commands -- we will talk about flags in Chapter~\ref{chap:runningarara}. There are cases in which you might want to have a list of commands instead of a single one; \arara has support for multiple commands inside one rule, we just need to replace |command| by |commands| and provide a list of commands to be executed, as seen in Code~\ref{code:excommands}. You probably noticed a strange element |@{file}| in the |command| line: this element is called \emph{orb tag}. For now, just admit these elements exist. We will come back to them later on, in Section~\ref{sec:orbtags}, I promise. \item[arguments] The |arguments| key (line 6) denotes a list of arguments for the rule command. In our example, we have an empty list, denoted as |[]|. You can define as many arguments as your command requires. Please check Code~\ref{code:makebar} for an example of a list of arguments. \end{ruleoptions} There are cases in which we need to run more than just one command for a certain rule. Take, for example, the |frontespizio| rule released with \arara: when using the |frontespizio| package\footnote{\url{http://ctan.org/pkg/frontespizio}, written by Enrico Gregorio.}, the document has to processed by the choosen engine, say |pdflatex|, no less than three times; if |latex| is used, there's an additional run of |dvips|. In that case, the logic is enclosed inside the rule, so there's no need to write every compilation step as required by the package as directives in the source code; a simple call to |frontespizio| is enough to generate the proper results. If you need to run more than one command inside a rule, replace the |command| identifier by |commands| and add one command per line, preceeded by |-| to indicate an item in the list. Code~\ref{code:excommands} presents a sample |makefoobar| rule which runs the |makefoo| program two times, followed by one run of the |makebar| program. \begin{code}[htbp] \caption{\mycmd{makefoobar.yaml}, an \arara rule with multiple commands.} \label{code:excommands} \begin{yaml} !config identifier: makefoobar name: MakeFooBar commands: - makefoo @{file} - makefoo @{file} - makebar @{file} arguments: [] \end{yaml} \end{code} For more complex rules, we might want to use arguments. Code~\ref{code:makebar} presents a new rule which makes use of them instead of an empty list as we saw in Code~\ref{code:yamlrule}. \begin{code}[htbp] \caption{\mycmd{makebar.yaml}, a rule with arguments.} \label{code:makebar} \begin{yaml} !config identifier: makebar name: MakeBar command: makebar @{one} @{two} @{file} arguments: - identifier: one flag: -i @{parameters.one} - identifier: two flag: -j @{parameters.two} \end{yaml} \end{code} For every argument in the |arguments| list, we have a |-| mark and the proper indentation. The required keys for an argument are: \begin{ruleoptions} \item[identifier] This key (lines 6 and 8) acts as a unique identifier for the argument. It's highly recommended to use lowercase letters without spaces, accents or punctuation symbols. \item[flag] The |flag| key (lines 7 and 9) represents the argument value. Note that we have other orb tags in the arguments definitions, |@{parameters.one}| and |@{parameters.two}|; we will discuss them later on, in Section~\ref{sec:orbtags}. Just to give some context, |parameters| is a special keyword which maps the elements available in the directives. For example, if we have |one: 1| in a directive, |parameters.one| will resolve to |1|. The argument |flag| value is only triggered, that is, resolved, if and only if there's an explicit directive argument. Say, if |one| is not defined as a directive argument, the |flag| value of the argument |one| will be resolved to an empty string. There's a way of overriding the default empty string value when a directive argument is not specified, which is done by using the |default| key. By the way, the |flag| key is not really mandatory, but for most of the rules, you'll need it. At least one of the |flag| and |default| keys is mandatory. \end{ruleoptions} If we need to set a default value other than an empty string to a rule argument, we can use the |default| key. When a rule argument just needs a default value, you can safely ignore the |flag| key and rely on the |default| key. If you need to map a directive argument into a rule argument without falling back to a default value different than an empty string, just use the |flag| key. Now, if you need mapping and fallback, stick with both keys. For now, we need to keep in mind that \arara uses rules to tell it how to do a certain task. In the next sections, when more concepts are presented, we will come back to this subject. Just a taste of things to come, as we mentioned before already: directives are mapped to rules through orb tags. Don't worry, I'll explain how things work. \section{Directives} \label{sec:directives} A \emph{directive} is a special comment inserted in the |.tex| file in which you indicate how \arara should behave. You can insert as many directives as you want, and in any position of the |.tex| file. \arara will read the whole file and extract the directives. A directive should be placed in a line of its own, in the form |% arara: | -- actually, we will see in Section~\ref{sec:filepatterns} that the prefix search can be altered. There are two types of directives: \begin{description} \item[empty directive] An empty directive, as the name indicates, has only the rule identifier, as we seen in Section~\ref{sec:rules}. Lines 1 and 3 of Code~\ref{code:directiveslatex} show an example of empty directives. Note that you can suppress arguments (line 3 in contrast to line 2), but we will see that \arara assumes that you know exactly what you are doing. The syntax for an empty directive is |% arara: makefoo|. \item[parametrized directive] A parametrized directive has the rule identifier followed by its arguments. Line 2 of Code~\ref{code:directiveslatex} shows an example of a parametrized directive. It's very important to mention that the arguments are mapped by their identifiers and not by their positions. The syntax for a parametrized directive is |% arara: makefoo: { arglist }|. The argument is in the form |arg: value|; a list of arguments and their respective values is separated by comma. \end{description} \begin{code}[htbp] \caption{Example of directives in a .tex file.} \label{code:directiveslatex} \begin{latex} %% (*@@*)arara: makefoo %% (*@@*)arara: makebar: { one: hello, two: bye } %% (*@@*)arara: makebar \documentclass{article} ... \end{latex} \end{code} The arguments are defined according to the rule mapped by the directive. For example, the rule |makebar| (Code~\ref{code:makebar}) has a list of two arguments, |one| and |two|. So you can safely write |makebar: { one: hello }|, but trying to map a nonexisting argument with |makebar: { three: hi }| will raise an error. If you want to disable an \arara directive, there's no need of removing it from the |.tex| file. Simply replace |% arara:| by |% !arara:| and this directive will be ignored. \arara always look for a line that, after removing the leading and trailing spaces, starts with a comment |%| and has the keyword |arara:| in it. In Section~\ref{sec:filepatterns}, we will learn how to override this search pattern, but the |arara:| keyword is always immutable. Directives are mapped to rules. In Section~\ref{sec:orbtags} we will learn about orb tags and then revisit rules and directives. I hope the concepts will be clearer since we will understand what an orb tag is and how it works. How about a nice cup of coffee? \section{Orb tags} \label{sec:orbtags} When I was planning the mapping scheme, I opted for a templating mechanism. I was looking for flexibility, and the powerful \href{http://mvel.codehaus.org}{MVEL} expression language~\cite{mvel:2012} was perfect for the job. I could extend my mapping plans by using orb tags. An \emph{orb tag} consists of a |@| character followed by braces |{...}| which contain regular MVEL expressions. In particular, \arara uses the |@{}| expression orb, which contains a value expression which will be evaluated to a string, and appended to the output template. For example, the following template |Hello, my name is @{name}| with the |name| variable resolving to |Paulo| will be expanded to the string |Hello, my name is Paulo|. Cool, isn't it? Code~\ref{code:exorbtags} presents a few examples on how orb tags are expanded. \begin{code}[htbp] \caption{A few examples on how orb tags are expanded.} \label{code:exorbtags} \begin{bash} # always consider: name = Paulo In[1]: Hello, my name is @{name}. Out[1]: Hello, my name is Paulo. In[2]: @{name == "Paulo"} Out[2]: true In[3]: @{name.toUpperCase()} Out[3]: PAULO In[4]: Hello, I am @{name == "Paulo" ? "John" : "Mary"}. Out[4]: Hello, I am John. \end{bash} \end{code} In the first example of Code~\ref{code:exorbtags}, |@{name}| simply indicates the expansion of the variable into its value, so the output is a concatenation of the text with the variable value. The second example is a conditional test, that is, whether the |name| variable has its value equals to |Paulo|; the result of this evaluation is then expanded, which is |true|. The third example presents a more complex construction: since |name| holds a string, MVEL resolves this variable to a |String| object and automatically all methods from the |String| class in Java are available to the variable, so the method |toUpperCase()| is called in order to make all characters in the string to be capitalized, and the output is presented. The fourth and last example presents a ternary operation, which starts with a conditional to be evaluated; if this test evaluates to true, the first string is printed, with the second string being printed in case the test is false. When mapping rules, every command argument will be mapped to the form |@{identifier}| with value equals to the content of the |flag| key. The |@{identifier}| orb tag might hold the value of the |default| key instead, if the key is defined and there were no directive parameters referring to |identifier|. There are three reserved orb tags, |@{file}|, |@{item}| and |@{parameters}| -- actually, that's not true, there's a fourth reserved orb tag which plays a very special role in \arara \ -- |@{SystemUtils}| -- but we will talk about it later on. The |@{file}| orb tag refers to the filename argument passed to \arara. The |@{file}| value can be overriden, but we will discuss it later. The second reserved orb tag |@{item}| refers to a list of items, in case the rule might use some sort of list iteration, discussed later on. The third reserved orb tag |@{parameters}| is a map which can expand to the argument value passed in the directive. If you have |makebar: { one: hello }|, the |flag| key of argument |one| will be expanded from the original definition |-i @{parameters.one}| to |-i hello|. Now |@{one}| contains the expanded |flag| value, which is |-i hello|. All arguments tags are expanded in the rule command. If one of them is not defined in the directive, \arara will admit an empty value, so the |command| flag will be expanded to |makebar -i hello mydoc|, unless of course the current argument doesn't have a |default| elements in its definition. The whole procedure is summarized as follows: \begin{enumerate} \item \arara processes a file named |mydoc.tex|. \item A directive |makebar: { one: hello }| is found, so \arara will look up the rule |makebar.yaml| (Code~\ref{code:makebar}) inside the default rules directory. \item The argument |one| is defined and has value |hello|, so the corresponding |flag| key will have the orb tag |@{parameters.one}| expanded to |hello|. The new value is now added to the template referenced by the |command| key and then |@{one}| is expanded to |-i hello|. \item The argument |two| is not defined, so the template referenced by the |command| key has |@{two}| expanded to an empty string, since there's no |default| key in the argument definition. \item There are no more arguments, so the template referenced by the |command| key now expands |@{file}| to |mydoc|. \item The final command is now |makebar -i hello mydoc|. \end{enumerate} There's a reserved directive key named |files|, which is in fact a list. In case you want to override the default value of the |@{file}| orb tag, use the |files| key, like |makebar: { files: [ thedoc.tex ] }|. This will result in |makebar thedoc.tex| instead of |makebar mydoc.tex|. The very same concept applies to the other reserved directive key named |items|, which is also a list, and the expansion happens in the |@{item}| orb tag. If you provide more than one element in the list, \arara will replicate the directive for every file found, so |makebar: { files: [ a, b, c ] }| will result in three commands: |makebar a|, |makebar b| and |makebar c|. If you happen to have a rule which makes use of both |files| and |items| in the directive, you'll end up with a cartesian product of those two lists. \printbibliography[heading=subbibliography] \chapter{Configuration file} \label{chap:configurationfile} \epigraph{\emph{An algorithm must be seen to be believed.}}{Donald Knuth} \arara has support for an optional configuration file in order to enhance and override some settings of the application without the need of delving into the source code. The optional configuration file has to reside inside the user home directory, which is usually |C:\Users\Username| for Windows Vista and superior, or |~/username| for the Unix world, under the name |araraconfig.yaml|. \arara always looks for a configuration file during every execution. In fact, |araraconfig.yaml| is just a plain text file written in the YAML format, starting with the |!config| line and at with least one of the three settings presented in the following sections. The order doesn't matter, as long as they are consistent. \section{Search paths} \label{sec:searchpaths} When looking for rules, \arara always searches the default rule path located at |ARARA_HOME/rules|; if no rule is found, the execution halts with an error. It's not wise to mess with the default rule path, so we use the configuration file to add search paths, that is, a list of directories in which \arara should look for rules. An example of a new search path is presented in Code~\ref{code:searchone}. \begin{code}[htbp] \caption{An example of a new search path for the configuration file.} \label{code:searchone} \begin{yaml} !config paths: - /home/paulo/rules \end{yaml} \end{code} According to Code~\ref{code:searchone}, from now on, \arara will look for rules first in the |/home/paulo/rules|; if the rule is not found, then the search falls back to the default search path located at |ARARA_HOME/rules|. We can even add an arbitrary number of paths, as seen in Code~\ref{code:searchtwo}. \begin{code}[htbp] \caption{An arbitrary number of paths added in the configuration file.} \label{code:searchtwo} \begin{yaml} !config paths: - /home/paulo/rules - /opt/arara/rules - /home/paulo/myrules \end{yaml} \end{code} The items order defines the search priority. \arara also features a special orb tag for search paths named |@{userhome}| which maps the variable to the user home directory, for example, |/home/paulo|, according to your operating system. But before we proceed, a word on the YAML format. Sadly, we can't start values with |@| because this symbol is reserved for future use in the YAML format. For example, |foo: @bar| is an invalid YAML format, so the correct usage is to enclose it in quotes: |foo: '@bar'| or |foo: "@bar"|. We also need to enclose our strings with quotes in \arara, but now we can save them by simply adding the || prefix to the value. In other words, |foo: @bar| is correctly parsed; when that keyword in that specific position is found, \arara removes it. That means that the orb tag presented in Code~\ref{code:searchthree} will be correctly parsed. \begin{code}[htbp] \caption{Using the special orb tag for mapping the home directory in the configuration file.} \label{code:searchthree} \begin{yaml} !config - '@{userhome}/rules' - /opt/arara/rules - @{userhome}/myrules \end{yaml} \end{code} It's important to observe that the || prefix is also valid in the rules context, presented in Section~\ref{sec:rules}. The idea of using this prefix is to actually ease the writing of rules that involve quoting without the need of escaping all internal quotes or even alternating between single and double quotes. It's also a way of writing cleaner rules. \section{Language} \label{sec:language} \arara currently features localized messages in English, French, Italian, German, Spanish, Brazilian Portuguese, Russian and Turkish. The default language fallback is English, but we can easily change the language by adding |language: | to the configuration file, as seen in Code~\ref{code:conflang}. The list of languages and codes is presented in Table~\ref{tab:langcodeconf}. \begin{code}[htbp] \caption{Changing the language in the configuration file.} \label{code:conflang} \begin{yaml} !config language: en \end{yaml} \end{code} \begin{table}[htbp] \centering \caption{Languages and codes.} \label{tab:langcodeconf} \renewcommand{\arraystretch}{1.5} \begin{tabular}{lr} \hline \textbf{Language} & \textbf{Code} \\ \hline \hline English & |en| \\ Brazilian Portuguese & |ptbr| \\ Italian & |it| \\ Spanish & |es| \\ German & |de| \\ French & |fr| \\ Russian & |ru| \\ Turkish & |tr| \end{tabular} \end{table} There's also a |--language| command line flag which has a higher priority, so it overrides the configuration file setting, if any. Beware of the terminal you use; the Windows command prompt has serious troubles in understanding UTF-8. You probably won't run into problems with the applications shipped in Mac or Linux. \section{File patterns} \label{sec:filepatterns} \arara accepts the following filetypes: |tex|, |dtx| and |ltx|. If no file extension is provided in the command line, for example, calling |arara mydoc| instead of |arara mydoc.tex|, the application will automatically look for files that match the filetypes in that specific order, that is, |mydoc.tex|, |mydoc.dtx| and |mydoc.ltx|. Let's say we want to change the order by promoting |dtx| to the first match; we can easily achieve that by rearranging the items of the list of filetypes in the configuration file according to Code~\ref{code:itemsconf}. \begin{code}[htbp] \caption{Rearranging the list of filetypes in the configuration file.} \label{code:itemsconf} \begin{yaml} !config filetypes: - extension: dtx - extension: tex - extension: ltx \end{yaml} \end{code} The |filetypes| key in the configuration file is actually way more powerful than the example shown in Code~\ref{code:itemsconf}. Before we continue, let's start with some basics. Consider the three directives presented in Code~\ref{code:confdirectives}. \begin{code}[htbp] \caption{Three directives with different formatting patterns.} \label{code:confdirectives} \begin{latex} % (*@@*)arara: foo % (*@@*)arara: foo % (*@@*) arara: foo \documentclass{book} ... \end{latex} \end{code} The default setting for \arara is to recognize the three directives shown in Code~\ref{code:confdirectives}. In other words, the search pattern for all the three extensions is |^(\\s)*%\\s+| plus |arara:\\s| which is immutable, of course. Let’s say that, for the |dtx| format, you want \arara to look for directives that have no spaces in the beginning of the line, that is, the line must start with only one percentage sign followed by at least one space and the default prefix. We can easily achieve such requirement by adding a |pattern| element to our list, as presented in Code~\ref{code:confdirectivessearch}. \begin{code}[htbp] \caption{Changing the search pattern for \mycmd{.dtx} files.} \label{code:confdirectivessearch} \begin{yaml} !config !config filetypes: - extension: dtx pattern: ^%\\s+ - extension: tex - extension: ltx \end{yaml} \end{code} Now, only the first directive of Code~\ref{code:confdirectives} is recognized, if the analyzed file has the |.dtx| extension. All other extensions -- |.tex| and |.ltx| -- will follow the default search pattern. We can also extend \arara to analyze files with arbitrary extensions. As an example, let's suppose we have a sample |hello.c| file, presented in Code~\ref{code:helloc}. Note that the code was omitted for obvious reasons, since we are interested in the header. \begin{code}[htbp] \caption{A sample \mycmd{hello.c} code.} \label{code:helloc} \begin{clang} // arara: gcc #include ... \end{clang} \end{code} We can add the |.c| extension to be recognized by \arara by simply adding the extension and search pattern entries in the configuration file, as presented in Code~\ref{code:confc}. \begin{code}[htbp] \caption{Adding support for \mycmd{.c} files in the configuration file.} \label{code:confc} \begin{yaml} !config filetypes: - extension: c pattern: ^\\s*//\\s* \end{yaml} \end{code} Done, now \arara can support |.c| files! We can run |arara hello.c| and have our code compiled, provided we have a |gcc| rule, of course. The extensions list will be |.tex|, |.dtx|, |.ltx| and |.c|. If you want to change the order, it’s a matter of rearranging the items, as shown in Code~\ref{code:confctwo}. \begin{code}[htbp] \caption{Rearranging items of arbitrary extensions in the configuration file.} \label{code:confctwo} \begin{yaml} !config filetypes: - extension: c pattern: ^\\s*//\\s* - extension: tex - extension: dtx - extension: ltx \end{yaml} \end{code} From now on, the |.c| has priority over all other extensions. It's very important to note that for customized extensions, the |pattern| key is mandatory. For default extensions, use the |pattern| key if and only if you want to override the search pattern. \arara comes with a rule for Sketch~\cite{sketch:2013}, written by Sergey Ulyanov. We can easily add |% arara: sketch: { files: [ drawing.sk ] }| and Sketch will be properly called. Let's say we want to make \arara recognize Sketch files; it's just a matter of adding the extension and the search pattern in our configuration file, as presented in Code~\ref{code:sketchconfig}. \begin{code}[htbp] \caption{Adding support for Sketch files in the configuration file.} \label{code:sketchconfig} \begin{yaml} !config filetypes: - extension: sk pattern: ^(\\s)*[%#]\\s+ \end{yaml} \end{code} Now \arara supports |.sk| files! We can write a sample Sketch file (borrowed from the documentation) presented in Code~\ref{code:sketchsample} and add a |sketch| directive. The comments in the Sketch language allow both |%| and |#| symbols at the beginning of the line. \begin{code}[htbp] \caption{\mycmd{drawing.sk}, a sample Sketch file.} \label{code:sketchsample} \begin{latex} % arara: sketch polygon(0,0,1)(1,0,0)(0,1,0) line(-1,-1,-1)(2,2,2) \end{latex} \end{code} With the new settings presented in Code~\ref{code:sketchconfig}, we can run |arara drawing| or |arara drawing.sk| (Code~\ref{code:sketchsample}) and Sketch will be properly executed through \arara with no problems. \printbibliography[heading=subbibliography] \chapter{Running \texorpdfstring{\arara}{arara}} \label{chap:runningarara} \epigraph{\emph{Never trust a computer you can't throw out a window.}}{Steve Wozniak} Now that we have learned some basics, it's time to run \arara! Thankfully, the application is very user-friendly; if something goes wrong, we can easily find out what happened through messages and the log file. \section{Command line} \label{sec:commandline} \arara has a very simple command line interface. A simple |arara mydoc| does the trick -- provided that |mydoc| has the proper directives. The default behaviour is to run in silent mode, that is, only the name and the execution status of the current task are displayed. The idea of the silent mode is to provide a concise output. Sadly, in some cases, we want to follow the compilation workflow and even interact with a command which requires user input. If you have an interactive command, \arara won't even bother about it: the execution will halt and the command will fail. Well, that's the silent mode. Thankfully, \arara has a set of flags that can change the default behaviour or even enhance the compilation workflow. Table~\ref{tab:araraflags} shows the list of available \arara flags, with both short and long options. {\renewcommand{\arraystretch}{1.5} \begin{table}[htbp] \centering \footnotesize \begin{tabular}{p{0.1\textwidth}p{0.2\textwidth}p{0.55\textwidth}} \hline \textbf{Flag} & & \textbf{Behaviour}\\ \hline \hline |-h| & |--help| & This flag prints the help message, as seen in Code~\ref{code:arararun}, and exits the application. If you run |arara| without any flags or a file to process, this is the default behaviour. \\ \hline |-L c| & |--language c| & The |--language| flag sets the language of the current execution of \arara, where |c| is the language code presented in Table~\ref{tab:langcodeconf}, on page~\pageref{tab:langcodeconf}. Note that this flag has higher priority than the language set in the configuration file. \\ \hline |-l| & |--log| & The |--log| flag enables the logging feature of \arara. All streams from all commands will be logged and, at the end of the execution, an |arara.log| file will be generated. The logging feature is discussed in Section~\ref{sec:logging}. \\ \hline |-t n| & |--timeout n| & This flag sets an execution timeout for every task. If the timeout is reached before the task ends, \arara will kill it and interrupt the processing. The $n$ value is expressed in milliseconds. \\ \hline |-v| & |--verbose| & The |--verbose| flag enables all streams to be flushed to the terminal -- exactly the opposite of the silent mode. This flag also allows user input if the current command requires so. The user input interaction is possible thanks to the amazing Apache Commons Exec library~\cite{exec:2010}. \\ \hline |-V| & |--version| & This flag, as the name indicates, prints the current \arara version and exits the application. \\ \hline \end{tabular} \caption{The list of available \arara flags.} \label{tab:araraflags} \end{table}} \arara can recognize three types of files based on their extension, in this order: |.tex|, |.dtx| and |.ltx|. Other extensions are not recognized, unless of course you provide the correct mapping for them in the configuration file, as discussed in Section~\ref{sec:filepatterns}. The combination of flags is very useful to enhance the \TeX\ experience. They can provide nice features for integrating \arara with \TeX\ IDEs, as seen in Chapter~\ref{chap:ideintegration}. Note that both |--log| and |--verbose| flags are the most common combo to use in an IDE, so we can have both terminal and file output at the same time without any cost. \section{Messages} \label{sec:messages} Messages are the first type of feedback provided by \arara. They are basically related to rules, directives and configuration settings. Bad syntax, nonexisting rules, malformed directives, wrong expansion, \arara tries to tell you what went wrong. Those messages are usually associated with errors. We tried to include useful messages, like telling in which directive and line an error ocurred, or that a certain rule does not exist or has an incorrect format. \arara also checks if a command is valid. For example, if you try to call a rule that executes a nonexisting |makefoo| command, \arara will complain about it. These messages usually cover the events that can happen during the preprocessing phase. Don't panic, \arara will tell you what happened. Of course, an error halts the execution, so we need to fix the reported issue before proceeding. Note that \arara can also complain about nonexisting commands -- in this case, the error will be raised in runtime, since it's an underlying operating system dependency. If you use the |--language| flag or set up the |language| key in the configuration file, \arara will be able to display localized messages according to the provided language code. In other words, users will be able to read messages from the application in languages other English. Currently, \arara is able to display messages in English, Brazilian Portuguese, Spanish, German, Italian, French, Russian and Turkish. Have fun! \section{Logging} \label{sec:logging} Another way of looking for an abnormal behaviour is to read the proper |.log| file. Unfortunately, not every command emits a report of its execution and, even if the command generates a |.log| file, multiple runs would overwrite the previous reports and we would have only the last call. \arara provides a more consistent way of monitoring commands and their own behaviour through a global |.log| file that holds every single bit of information. You can enable the logging feature by adding either the |--log| or |-l| flags to the |arara| application. Before we continue, I need to explain about standard streams, since they constitute an important part of the generated |.log| file by \arara. Wikipedia~\cite{streams:2012} has a nice definition of them: \begin{quotation} \noindent ``In computer programming, standard streams are preconnected input and output channels between a computer program and its environment (typically a text terminal) when it begins execution. The three \textsc{i/o} connections are called standard input (|stdin|), standard output (|stdout|) and standard error (|stderr|).'' \end{quotation} Basically, the operating system provides two streams directed to display data: |stdout| and |stderr|. Usually, the first stream is used by a program to write its output data, while the second one is typically used to output error messages or diagnostics. Of course, the decision of what output stream to use is up to the program author. When \arara traces a command execution, it logs both |stdout| and |stderr|. The log entry for both |stdout| and |stderr| is referred as \emph{Output logging}. Again, an output to |stderr| does not necessarily mean that an error was found in the code, while an output to |stdout| does not necessarily mean that everything ran flawlessly. It's just a naming convention, as the program author decides how to handle the messages flow. That's why \arara logs them both in the same output stream. Read the log entries carefully. A excerpt of the resulting |arara.log| from |arara helloindex --log| is shown in Code~\ref{code:araralog} -- several lines were removed in order to leave only the more important parts. \begin{code}[htbp] \caption{\mycmd{arara.log} from \mycmd{arara helloindex {-}{-}log}.} \label{code:araralog} \begin{lstlisting}[basicstyle=\footnotesize\ttfamily, columns=flexible, showspaces=false, breaklines=true] 09 Abr 2012 11:27:58.400 INFO Arara - Welcome to Arara! 09 Abr 2012 11:27:58.406 INFO Arara - Processing file helloindex.tex, please wait. 09 Abr 2012 11:27:58.413 INFO DirectiveExtractor - Reading directives from helloindex.tex. 09 Abr 2012 11:27:58.413 TRACE DirectiveExtractor - Directive found in line 1 with pdflatex. ... 09 Abr 2012 11:27:58.509 INFO DirectiveParser - Parsing directives. 09 Abr 2012 11:27:58.536 INFO TaskDeployer - Deploying tasks into commands. 09 Abr 2012 11:27:58.703 INFO CommandTrigger - Ready to run commands. 09 Abr 2012 11:27:58.704 INFO CommandTrigger - Running PDFLaTeX. 09 Abr 2012 11:27:58.704 TRACE CommandTrigger - Command: pdflatex helloindex.tex 09 Abr 2012 11:27:59.435 TRACE CommandTrigger - Output logging: This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011) ... Output written on helloindex.pdf (1 page, 12587 bytes). Transcript written on helloindex.log. 09 Abr 2012 11:27:59.435 INFO CommandTrigger - PDFLaTeX was successfully executed. 09 Abr 2012 11:27:59.655 INFO CommandTrigger - Running MakeIndex. 09 Abr 2012 11:27:59.655 TRACE CommandTrigger - Command: makeindex helloindex.idx 09 Abr 2012 11:27:59.807 TRACE CommandTrigger - Output logging: This is makeindex, version 2.15 [TeX Live 2011] (kpathsea + Thai support). ... Generating output file helloindex.ind..done (9 lines written, 0 warnings). Output written in helloindex.ind. Transcript written in helloindex.ilg. 09 Abr 2012 11:27:59.807 INFO CommandTrigger - MakeIndex was successfully executed. ... 09 Abr 2012 11:28:00.132 INFO CommandTrigger - All commands were successfully executed. 09 Abr 2012 11:28:00.132 INFO Arara - Done. \end{lstlisting} \end{code} The \arara log is useful for keeping track of the execution flow as well as providing feedback on how both rules and directives are being expanded. The log file contains information about the directive extraction and parsing, rules checking and expansion, deployment of tasks and execution of commands. The \arara messages are also logged. If by any chance your code is not working, try to run |arara| with the logging feature enabled. It might take a while for you to digest the log entries, but I'm sure you will be able to track every single step of the execution and fix the offending line in your code. \section{Command output} \label{sec:commandoutput} Even when the |--log| flag is enabled, \arara still runs in silent mode. There's a drawback of this mode: if there's an interactive command wich requires the user input, \arara will simply halt the task and the execution will fail. We need to make |stdin| -- the standard input stream -- available for us. Thanks to the amazing Apache Commons Exec library~\cite{exec:2010}, \arara can also provide an access layer to the standard input stream in order to interact with commands, when needed. We just need to use a special |--verbose| flag. It's important to note that both |--log| and |--verbose| flags can be used together; \arara will log everything, including the input stream. I usually recommend those two flags when integrating \arara with \TeX\ IDEs, like we did in Chapter~\ref{chap:ideintegration}. \printbibliography[heading=subbibliography] \part{For authors} \label{part:forauthors} \chapter{Quick start} \label{sec:quickstarta} \epigraph{\emph{Snakes! Why did it have to be snakes?}}{Indiana Jones, \emph{Raiders of the Lost Ark} (1981)} This chapter covers a quick start of \arara, including an overview of the predefined rules and some notes on how to properly organize directives in the source code. \section{Predefined rules} \label{sec:predefinedrules} Let's take a look on the predefined rules and a brief description of their parameters. Note that these rules are constantly updated; the most recent versions are available in the project repository. For convenience, we will use |yes| and |no| for representing boolean values. Note that you can also use other pairs: |on| and |off|, and |true| and |false|. These values are also case insensitive, so entries like |True| or |NO| are valid. Note that the |latex|, |pdflatex|, |xelatex| and |lualatex| rules have a |shell| parameter resolving to |--shell-escape|. This flag is also available in MiK\TeX, but as an alias to the special |--enable-write18| flag. If you want to use \arara with an outdated MiK\TeX\ distribution which doesn't support the |--shell-escape| alias, make sure to edit the predefined rules accordingly -- these rules are located inside |$ARARA_HOME/rules| -- and replace all occurrences of |--shell-escape| by |--enable-write18|. Another option is to add another search path in the configuration file with modified rules, since custom search paths have higher priority than the default rules directory. If you use \TeX~Live or a recent Mik\TeX\ installation, there's no need to edit the rules, since the |--shell-escape| flag is already available. \subsection*{\texorpdfstring{\hologo{biber}}{biber}} \begin{description} \item[Description] This rule maps \hologo{biber}, calling the |biber| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: biber| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{BibTeX}}{BibTeX}} \begin{description} \item[Description] This rule maps \hologo{BibTeX}, calling the |bibtex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: bibtex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Clean} \begin{description} \item[Description] This rule maps the removal command from the underlying operating system. There are no parameters for this rule, except the the reserved directive key |files| which \textit{must} be used. If |files| is not used in the directive, \arara will simply ignore this rule. \item[Syntax] |% arara: clean| \end{description} \subsection*{dvips} \begin{description} \item[Description] This rule maps dvips, calling the |dvips| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: dvips| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[output] This parameter is used to set the output PostScript filename. If not provided, the default output name is set to |@{getBasename(file)}.ps|. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{frontespizio} \begin{description} \item[Description] This rule maps a compilation chain defined in |frontespizio|, a package written by Enrico Gregorio; it calls a defined \TeX\ engine three times with the proper parameters, when available. All parameters are optional. If no engine is provided, |pdflatex| is used as default. When |latex| is the chosen engine, there's an additional call to dvips. \item[Syntax] |% arara: frontespizio| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[engine] This parameter is used to set the \TeX\ engine. If not provided, |pdflatex| is used as a default value. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{LaTeX}}{LaTeX}} \begin{description} \item[Description] This rule maps \hologo{LaTeX}, calling the |latex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: latex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[draft] This is a boolean parameter which sets the draft mode, that is, no PDF output is generated. When value set to true, the draft mode is enabled, while false disables it. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Latexmk cleanup} \begin{description} \item[Description] This rule calls the cleanup option of Latexmk, according to the provided parameters. All parameters are optional. \item[Syntax] |% arara: lmkclean| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[include] This parameter, if equals to |all|, will remove all generated files, leaving only the source code intact; otherwise only the auxiliary files will be removed. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{LuaLaTeX}}{LuaLaTeX}} \begin{description} \item[Description] This rule maps \hologo{LuaLaTeX}, calling the |lualatex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: lualatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[draft] This is a boolean parameter which sets the draft mode, that is, no PDF output is generated. When value set to true, the draft mode is enabled, while false disables it. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Latexmk with \texorpdfstring{\hologo{LuaLaTeX}}{LuaLaTeX}} \begin{description} \item[Description] This rule calls Latexmk with \hologo{LuaLaTeX} as engine. All parameters are optional. \item[Syntax] |% arara: lualatexmk| \end{description} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \item[style] This parameter is used in case you want to provide a style for |makeindex|, if different than the default style. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{LuaTeX}}{LuaTeX}} \begin{description} \item[Description] This rule maps \hologo{LuaTeX}, calling the |luatex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: luatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[draft] This is a boolean parameter which sets the draft mode, that is, no PDF output is generated. When value set to true, the draft mode is enabled, while false disables it. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Make} \begin{description} \item[Description] This rule maps Make, calling the |make| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: make| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[task] This parameter is used to set the task name for |make| to execute. \end{ruleoptions} \subsection*{MakeGlossaries} \begin{description} \item[Description] This rule maps MakeGlossaries, calling the |makeglossaries| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: makeglossaries| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{MakeIndex} \begin{description} \item[Description] This rule maps MakeIndex, calling the |makeindex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: makeindex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[style] This parameter sets the index style. If not defined, |makeindex| relies on the default index style. \item[german] This is a boolean parameter which sets the German word ordering in the index. If true, the German word ordering will be employed; if the value is set to false, |makeindex| will rely on the default behaviour. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Nomencl} \begin{description} \item[Description] This rule maps Nomencl, which is in fact a call to the |makeindex| command with the the nomenclature feature. All parameters are optional. \item[Syntax] |% arara: nomencl| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[style] This parameter sets the nomenclature style. If not defined, |makeindex| relies on the default nomenclature style. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{pdfLaTeX}}{PDFLaTeX}} \begin{description} \item[Description] This rule maps \hologo{pdfLaTeX}, calling the |pdflatex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: pdflatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[draft] This is a boolean parameter which sets the draft mode, that is, no PDF output is generated. When value set to true, the draft mode is enabled, while false disables it. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Latexmk with \texorpdfstring{\hologo{pdfLaTeX}}{pdfLaTeX}} \begin{description} \item[Description] This rule calls Latexmk with \hologo{pdfLaTeX} as engine. All parameters are optional. \item[Syntax] |% arara: pdflatexmk| \end{description} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \item[style] This parameter is used in case you want to provide a style for |makeindex|, if different than the default style. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{pdfTeX}}{PDFTeX}} \begin{description} \item[Description] This rule maps \hologo{pdfTeX}, calling the |pdftex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: pdflatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[draft] This is a boolean parameter which sets the draft mode, that is, no PDF output is generated. When value set to true, the draft mode is enabled, while false disables it. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{ps2pdf} \begin{description} \item[Description] This rule maps pdf2pdf, calling the |ps2pdf| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: ps2pdf| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[output] This parameter is used to set the output PDF filename. If not provided, the default output name is set to |@{getBasename(file)}.pdf|. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Sketch} \begin{description} \item[Description] This rule maps Sketch, a small, simple system for producing line drawings of two or three-dimensional objects and scenes. All parameters are optional. \item[Syntax] |% arara: sketch| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[input] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{songidx} \begin{description} \item[Description] This rule maps |songidx|, a command line tool used to extract songs metadata from an file generated by the |songs| package\footnote{\url{http://songs.sourceforge.net}, written by Kevin Hamlen.} The parameter is mandatory. \item[Syntax] |% arara: songidx| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[input] This parameter sets the name of the file generated by |songs| in which |songidx| will extract the songs metadata. \end{ruleoptions} \subsection*{\texorpdfstring{\TeX}{TeX}} \begin{description} \item[Description] This rule maps \TeX, calling the |tex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: pdflatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{XeLaTeX}}{XeLaTeX}} \begin{description} \item[Description] This rule maps \hologo{XeLaTeX}, calling the |xelatex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: xelatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \subsection*{Latexmk with \texorpdfstring{\hologo{XeLaTeX}}{XeLaTeX}} \begin{description} \item[Description] This rule calls Latexmk with \hologo{XeLaTeX} as engine. All parameters are optional. \item[Syntax] |% arara: xelatexmk| \end{description} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \item[style] This parameter is used in case you want to provide a style for |makeindex|, if different than the default style. \end{ruleoptions} \subsection*{\texorpdfstring{\hologo{XeTeX}}{XeTeX}} \begin{description} \item[Description] This rule maps \hologo{XeTeX}, calling the |xetex| command with the proper parameters, when available. All parameters are optional. \item[Syntax] |% arara: xelatex| \end{description} \subsubsection*{Parameters} \begin{ruleoptions} \item[action] This parameter sets the interaction mode flag. Possible options are |batchmode|, |nonstopmode|, |scrollmode|, and |errorstopmode|. If not defined, no flag will be set. \item[shell] This is a boolean parameter which sets the shell escape mode. If true, shell escape will be enabled; if the value is set to false, the feature will be completely disabled. If not defined, the default behaviour is rely on restricted mode. \item[synctex] This parameter is defined as boolean and sets the generation of Sync\TeX\ data for previewers. If true, data will be generated; false will disable this feature. If not defined, no flag will be set. \item[options] This parameter is used to provide flags which were not mapped. It is recommended to enclose the value with single or double quotes. \end{ruleoptions} \section{Organizing directives} \label{sec:organizingdirectives} Actually, there's nothing much to say about directives, they are really easy to use. The important part when dealing with directives is to make sure we will only use the right amount of them. Remember, for each directive, there will be call to the command line tool, and this might take some time. Since a directive can have as many parameters as its corresponding rule has, we need to take care. If an argument value has spaces, enclose it with quotes. Again, try to avoid at all costs values with spaces, but if you really need them, enclose the value with single quotes. If you want to make sure that both rules and directives are being mapped and expanded correctly, enable the logging option with the |--log| flag and verify the output. All expansions are logged. Although \arara reads the whole file looking for directives, it's a good idea to organize them at the top of the file. It will surely make your life easier, as you can quickly spot the compilation chain to be applied to the current document. If there's something wrong with a directive, don't worry, \arara will be able to track the inconsistency down and warn us about it. \chapter{Reference for rule library} \label{chap:referenceforrulelibraryone} \epigraph{\emph{Your brain may give birth to any technology, but other brains will decide whether the technology thrives. The number of possible technologies is infinite, and only a few pass this test of affinity with human nature.}}{Robert Wright} This chapter aims at discussing the reserved keywords of \arara for directive arguments and special orb tags, their purpose and how to correctly use them in the context of a document. \section{Directive arguments} \label{sec:directivearguments} As seen in the previous chapters, \arara has two reserved keywords for directive arguments which cannot be defined as arguments of a rule: |files| and |items|. Those variables do not hold a single value as the usual directive argument does, but they actually refer to a list of values instead. in the YAML format, a list is defined as a sequence of elements separated by a comma and enclosed with |[]|. For example, |items: [ a, b, c ]| is a list and refers to the elements |a|, |b| and |c|. Let's see in more details about each directive argument. \begin{ruleoptions} \item[files] When not defined with a proper value in the directive definition, |files| contains only one value: the current file reference. When we explicitly add this argument to a directive, the value is overriden, and \arara considers one iteration per element. In order words, if we have |foo: { files: [ a, b, c ] }|, \arara will perform the execution of the task |foo| three times, one for each value of |files|. Each value of |files| is expanded to the |@{file}| orb tag in the rule context. \item[items] The |items| directive argument, although it has the exact behaviour of |files| in the processing phase, happens to have a different semantics. Think of a rule that needs to process a list of elements, say, a list of extensions, files to copy, and so forth; for every value defined in |items|, \arara will perform the execution the current task. It's important to note that |items| has an empty list by default. Each value of |items| is expanded to the |@{item}| orb tag in the rule context. \end{ruleoptions} Both |files| and |items| can be used in any directive, if the rule of course makes use of their corresponding |@{file| and |@{item}| orb tags. Please note that, if those two lists are defined in the directive, \arara will resolve the variables as the cartesian product of the lists. \section{Special orb tags} \label{sec:specialorbtags} In the rule context, \arara has four reserved keywords which cannot be assigned as arguments identifiers; each one of them has its own purpose and semantics, besides of course mapping different values. These orb tags are |@{file}|, |@{item}|, |@{parameters}| and |@{SystemUtils}|. \begin{ruleoptions} \item[file] This orb tags always resolve to the filename processed by \arara. If the |files| directive argument is used in the directive definition, |@{file}| will resolve, in each iteration, to the current value of that list. The variable always hold an string value and it's never empty. \item[item] The |@{item}| orb tag resolves to each element of the list of items defined through the |items| directive argument. In each iteration of the |items| list, |@{item}| will resolve to the current value of that list. The variable always hold an string value and it is empty by default. \item[parameters] This orb tag is actually a map, that is, a collection of variables. The |@{parameters}| orb tag is set with all the directive arguments and their corresponding values. The access to a variable is done through |parameters.|, so if we want to access the |foo| directive argument value, we simply write |@{parameters.foo}|. \item[SystemUtils] This orb tag maps the |SystemUtils| class from the Apache Commons Lang library~\cite{lang:2001} and provides a lot of methods and properties in order to write cross-platform rules. Table~\ref{tab:properties} on page~\pageref{tab:properties} presents the list of properties available in the |@{SystemUtils}| orb tag. \end{ruleoptions} Since these are reserved keywords used for special orb tags, \arara will raise an error if there's an attempt of assigning one of them as rule argument identifier. \printbibliography[heading=subbibliography] \part{For rulemakers} \label{part:forrulemakers} \chapter{Quick start} \label{chap:quickstartrm} \epigraph{\emph{Cause and effect act in webs, not chains.}}{Steve Grand} Now that we know about rules, directives and orb tags, it's time to come up with some examples. I know it might not be trivial to understand how \arara works in a glance, but I'm sure the examples will help with the concepts. Please note that there might have platform-specific rules, so double-check the commands before running them -- actually, don't worry, \arara has a card up its sleeve. \section{Writing rules} \label{sec:writingrules} Before we proceed, I think it's important to mention this note again: we can't start values with |@| because this symbol is reserved for future use in the YAML format. For example, |foo: @bar| is an invalid YAML format, so the correct usage is to enclose it in quotes: |foo: '@bar'| or |foo: "@bar"|. We also need to enclose our strings with quotes in \arara, but we can save them by simply adding the || prefix to the value. In other words, |foo: @bar| is correctly parsed; when that keyword in that specific position is found, \arara removes it. Our first example is to add support to \hologo{pdfLaTeX} instead of using the default rule. Our first attempt to write this rule is presented in Code~\ref{code:pdflatexone}. Make sure to create a directory to store your own rules and don't forget to add this directory to the search path in the configuration file (Chapter~\ref{chap:configurationfile}). \begin{code}[htbp] \caption{\mycmd{pdflatex.yaml}, first attempt.} \label{code:pdflatexone} \begin{yaml} !config identifier: pdflatex name: PDFLaTeX command: pdflatex "@{file}" arguments: [] \end{yaml} \end{code} So far, so good. The |command| flag has the |pdflatex| program and the |@{file}| orb tag. Now we can add the |pdflatex| directive to our |.tex| file, as we can see in Code~\ref{code:helloexampleone}. \begin{code}[htbp] \caption{\mycmd{helloworld.tex}} \label{code:helloexampleone} \begin{latex} % (*@@*)arara: pdflatex \documentclass{article} \begin{document} Hello world. \end{document} \end{latex} \end{code} It's just a matter of calling |arara helloworld| -- you can also provide the |.tex| extension by calling |arara helloworld.tex|, after all the extension will be removed anyway -- and \arara will process our file, according to the Code~\ref{code:araraoutputone}. \begin{code}[htbp] \caption{\arara output for the \mycmd{pdflatex} task.} \label{code:araraoutputone} \begin{bash} $ arara helloworld __ _ _ __ __ _ _ __ __ _ / _` | '__/ _` | '__/ _` | | (_| | | | (_| | | | (_| | \__,_|_| \__,_|_| \__,_| Running PDFLaTeX... SUCCESS \end{bash} \end{code} Great, our first rule works like a charm. Once we define a rule, the directive is automatically available for us to call it as many times as we want. What if we make this rule better? Consider the following situation: \begin{quotation} \noindent Sometimes, we need to use |\write18| to call a package that makes use of it (for example, |minted|). It's very dangerous to enable shell escape globally, but changing the |pdflatex| call every time we need it sounds boring. \end{quotation} \arara has a special treatment for cases like this. We will rewrite our |pdflatex| rule to include a flag for shell escape. Another cool feature will be presented now, as we can see in the new rule shown in Code~\ref{code:pdflatextwo}. \begin{code}[htbp] \caption{\mycmd{pdflatex.yaml}, second attempt.} \label{code:pdflatextwo} \begin{yaml} !config identifier: pdflatex name: PDFLaTeX command: pdflatex @{shell} "@{file}" arguments: - identifier: shell flag: @{parameters.shell == "yes" ? "--shell-escape" : "--no-shell-escape" } \end{yaml} \end{code} Line 7 from Code~\ref{code:pdflatextwo} makes use of the ternary operator |?:| which defines a conditional expression. In the first part of the evaluation, we check if |parameters.shell| is equal to the string |"yes"|. If so, |"--shell-escape"| is defined as the result of the operation. If the conditional expression is false, |"--no-shell-escape"| is set instead. What if you want to allow |true| and |on| as valid options as well? We can easily rewrite our orb tag to check for additional values, but \arara has a clever way of doing that: a function to look for boolean values! In this case, we will use a function named |isTrue()|, available in the rule context. Please refer to Section~\ref{sec:functions} for a list of the available functions and their meanings. The new attempt is presented in Code~\ref{code:pdflatexthree} \begin{code}[htbp] \caption{\mycmd{pdflatex.yaml}, third attempt.} \label{code:pdflatexthree} \begin{yaml} !config identifier: pdflatex name: PDFLaTeX command: pdflatex @{shell} "@{file}" arguments: - identifier: shell flag: @{ isTrue( parameters.shell, "--shell-escape" , "--no-shell-escape" ) } \end{yaml} \end{code} With this new rule, it's now easy to enable the shell escape option in |pdflatex|. Simply go with the directive |pdflatex: { shell: yes }|. You can also use |true| or |on| instead of |yes|. Any other value for |shell| will disable the shell escape option. It's important to observe that \arara directives have no mandatory arguments. If you want to add a dangerous option like |--shell-escape|, consider calling it as an argument with a proper check and rely on a safe state for the argument fallback. For the next example, we will create a rule for MakeIndex. To be honest, although |makeindex| has a lot of possible arguments, I only use the |-s| flag once in a while. Code~\ref{code:makeindexone} shows our first attempt of writing this rule. Note that we are making use of another built-in function of \arara named |getBasename()|; this function returns the name of the file without the extension. \begin{code}[htbp] \caption{\mycmd{makeindex.yaml}, first attempt.} \label{code:makeindexone} \begin{yaml} !config identifier: makeindex name: MakeIndex command: makeindex @{style} "@{ getBasename(file) }.idx" arguments: - identifier: style flag: -s @{parameters.style} \end{yaml} \end{code} As a follow-up to our first attempt, we will now add support for the |-g| flag that employs German word ordering in the index. Since this flag is basically a switch, we can borrow the same tactic used for enabling shell escape in the |pdflatex| rule from Code~\ref{code:pdflatexthree}. The new rule is presented in Code~\ref{code:makeindextwo}. \begin{code}[htbp] \caption{\mycmd{makeindex.yaml}, second attempt.} \label{code:makeindextwo} \begin{yaml} !config identifier: makeindex name: MakeIndex command: makeindex @{style} "@{ getBasename(file) }.idx" arguments: - identifier: style flag: -s @{parameters.style} - identifier: german flag: @{ isTrue( parameters.german, "-g" ) } \end{yaml} \end{code} The new |makeindex| rule presented in Code~\ref{code:makeindextwo} looks good. We can now test the compilation workflow with an example. Consider a file named |helloindex.tex| which has a few index entries for testing purposes, presented in Code~\ref{code:examplemakeindex}. As usual, I'll present my normal workflow, that involves calling |pdflatex| two times to get references right, one call to |makeindex| and finally, a last call to |pdflatex|. Though there's no need of calling |pdflatex| two times in the beginning, I'll keep that as a good practice from my side. \begin{code}[htbp] \caption{\mycmd{helloindex.tex}} \label{code:examplemakeindex} \begin{latex} % (*@@*)arara: pdflatex % (*@@*)arara: pdflatex % (*@@*)arara: makeindex % (*@@*)arara: pdflatex \documentclass{article} \usepackage{makeidx} \makeindex \begin{document} Hello world\index{Hello world}. Goodbye world\index{Goodbye world}. \printindex \end{document} \end{latex} \end{code} By running |arara helloindex| or |arara helloindex.tex| in the terminal, we will obtain the same output from Code~\ref{code:araramakeexample}. The execution order is defined by the order of directives in the |.tex| file. If any command fails, \arara halts at that position and nothing else is executed. You might ask how \arara knows if the command was successfully executed. The idea is quite simple: good programs like |pdflatex| make use of a concept known as exit status. In short, when a program had a normal execution, the exit status is zero. Other values are returned when an abnormal execution happened. When |pdflatex| successfully compiles a |.tex| file, it returns zero, so \arara intercepts this number. Again, it's a good practice to make command line applications return a proper exit status according to the execution flow, but beware: you might find applications or shell commands that don't feature this control (in the worst case, the returned value is always zero). \arara relies on the \href{http://commons.apache.org/exec/}{Apache Commons Exec} library to provide the system calls. \begin{code}[!htbp] \caption{Running \mycmd{helloindex.tex}.} \label{code:araramakeexample} \begin{bash} $ arara helloindex __ _ _ __ __ _ _ __ __ _ / _` | '__/ _` | '__/ _` | | (_| | | | (_| | | | (_| | \__,_|_| \__,_|_| \__,_| Running PDFLaTeX... SUCCESS Running PDFLaTeX... SUCCESS Running MakeIndex... SUCCESS Running PDFLaTeX... SUCCESS \end{bash} \end{code} According to the terminal output shown in Code~\ref{code:araramakeexample}, \arara executed all the commands successfully. In Section~\ref{sec:logging} we discuss how \arara works with commands and how to get their streams for a more detailed analysis. For the next example, we will write a rule for both \hologo{BibTeX} and \hologo{biber}. Instead of writing two rules -- one for each command -- I'll show how we can use conditional expressions and run different commands in a single rule. The common scenario is to have each tool mapped to its own rule, but as we can see, rules are very flexible. Let's see how \arara handles this unusual |bibliography| rule presented in Code~\ref{code:bibone}. \begin{code}[htbp] \caption{\mycmd{bibliography.yaml}} \label{code:bibone} \begin{yaml} !config identifier: bibliography name: Bibliography command: @{engine} @{args} @{ getBasename(file) } arguments: - identifier: engine flag: @{ isTrue( parameters.engine == "biber", "biber", "bibtex" ) } default: bibtex - identifier: args flag: @{parameters.args} \end{yaml} \end{code} The |bibliography| rule is quite simple, actually. If no |engine| is provided in the |bibliography| directive, the |default| element of the |engine| argument will be set to |bibtex|. Otherwise, if the |engine| parameter is set to |biber| -- and only this value -- the |engine| orb tag will expand the result to |biber|. Code~\ref{code:examplebib} presents only the header of our |biblio.tex| file using the new |bibliography| directive. Other options are shown in Table~\ref{tab:biblio}. \begin{code}[htbp] \caption{\mycmd{biblio.tex}} \label{code:examplebib} \begin{latex} % (*@@*)arara: pdflatex % (*@@*)arara: bibliography % (*@@*)arara: pdflatex \documentclass{article} ... \end{latex} \end{code} {\renewcommand{\arraystretch}{1.5} \begin{table}[ht] \centering \footnotesize \begin{tabular}{p{0.3\textwidth}p{0.55\textwidth}} \hline \textbf{Directive} & \textbf{Behaviour}\\ \hline \hline \mycmd{bibliography: \{ engine: bibtex \}} & This directive sets the |engine| parameter to |bibtex|, which will expand the command to |bibtex| in the rule. Note that any value other than |biber| will expand the command to |bibtex|. \\ \hline \mycmd{bibliography: \{ engine: biber \}} & This directive sets the |engine| parameter to |biber|, which will expand the command to |biber| in the rule. This is the only possible value that will set |biber| as the rule command. \\ \hline \mycmd{bibliography: \{ engine: bibtex, args: '-min-crossrefs=2' \}} & This directive sets the |engine| parameter to |bibtex| and also provides an argument to the command. Note that the |args| value is specific to |bibtex| -- using this argument value with |biber| will surely raise an error. \\ \hline \mycmd{bibliography: \{ engine: biber, args: '{-}{-}sortcase=true' \}} & This directive sets the |engine| parameter to |biber| and also provides an argument to the command. Note that the |args| value is specific to |biber| -- using this argument value with |bibtex| will surely raise an error. \\ \hline \end{tabular} \caption{Other directive options for \mycmd{bibliography}.} \label{tab:biblio} \end{table}} It's important to note that |bibtex| and |biber| differ in their flags, so I used a global |args| parameter. It is recommended to enclose the |args| value with single or double quotes. Use this parameter with great care, since the values differ from tool to tool. The output is presented in Code~\ref{code:ararabib}. \begin{code}[!htbp] \caption{Running \mycmd{biblio.tex}.} \label{code:ararabib} \begin{bash} $ arara biblio __ _ _ __ __ _ _ __ __ _ / _` | '__/ _` | '__/ _` | | (_| | | | (_| | | | (_| | \__,_|_| \__,_|_| \__,_| Running PDFLaTeX... SUCCESS Running Bibliography... SUCCESS Running PDFLaTeX... SUCCESS \end{bash} \end{code} According to the terminal output shown in Code~\ref{code:ararabib}, \arara executed all the commands successfully. A friendly warning: this rule is very powerful because of its flexibility, but the syntax -- specially the conditional expression and the expansion tricks -- might mislead the user. My advice is to exhaustively test the rules before deploying them into production. After all, better be safe than sorry. Note that \arara already includes both |bibtex| and |biber| rules. We believe this is the best approach to deal with such tools instead of a generic |bibliography| rule. Take a look on the existing rules, they might help the learning process. \section{Cross-platform rules} \label{sec:crossplatformrules} One of the goals when writing \arara was to provide a cross-platform tool which behaves exactly the same on every single operating system. Similarly, the rules also follow the same idea, but sadly that's not always possible. After all, at some point, commands are bounded to the underlying operating system. A rule that call |pdflatex|, for example, is easy to maintain; you just need to ensure there's an actual |pdflatex| command available in the operating system -- in the worst case, \arara warns about a nonexisting command. But there are cases in which you need to call system-specific commands. You could write two or three rules for the same task, say |makefoowin|, |makefoolinux|, and |makefoomac|, but this approach is not intuitive. Besides, if you share documents between operating systems, you'd have to also change the respective directive in your |.tex| file in order to reflect which operating system you are on. Thankfully, there's a better solution for writing cross-platform rules which require system-specific commands. In Section~\ref{sec:specialorbtags}, we mentioned about a special orb tag called |@{SystemUtils}| -- it's now time to unveil its power. This orb tag is available for all rules and maps the |SystemUtils| class from the Apache Commons Lang library~\cite{lang:2001}. In other words, we have access to all methods and properties from that class. Even though we have access to all public methods of the |SystemUtils| class, I believe we won't need to use them -- the available properties are far more useful for us. Table~\ref{tab:properties} shows the most relevant properties for our context. The \href{http://commons.apache.org/lang/api/org/apache/commons/lang3/SystemUtils.html}% {Apache Commons Lang documentation} contains the full class description. {\renewcommand{\arraystretch}{1.5} \begin{table}[htpb] \centering \footnotesize \begin{tabular}{lp{0.6\textwidth}} \hline \textbf{Property} & \textbf{Description}\\ \hline \hline |IS_OS_AIX| & True if this is AIX.\\ |IS_OS_FREE_BSD| & True if this is FreeBSD.\\ |IS_OS_HP_UX| & True if this is HP-UX.\\ |IS_OS_IRIX| & True if this is Irix.\\ |IS_OS_LINUX| & True if this is Linux.\\ |IS_OS_MAC| & True if this is Mac.\\ |IS_OS_MAC_OSX| & True if this is Mac.\\ |IS_OS_NET_BSD| & True if this is NetBSD.\\ |IS_OS_OPEN_BSD| & True if this is OpenBSD.\\ |IS_OS_OS2| & True if this is OS/2.\\ |IS_OS_SOLARIS| & True if this is Solaris.\\ |IS_OS_SUN_OS| & True if this is Sun OS.\\ |IS_OS_UNIX| & True if this is a Unix-like system, as in any of AIX, HP-UX, Irix, Linux, Mac~OS~X, Solaris or Sun OS.\\ |IS_OS_WINDOWS| & True if this is Windows.\\ |IS_OS_WINDOWS_2000| & True if this is Windows 2000.\\ |IS_OS_WINDOWS_2003| & True if this is Windows 2003.\\ |IS_OS_WINDOWS_2008| & True if this is Windows 2008.\\ |IS_OS_WINDOWS_7| & True if this is Windows 7.\\ |IS_OS_WINDOWS_95| & True if this is Windows 95.\\ |IS_OS_WINDOWS_98| & True if this is Windows 98.\\ |IS_OS_WINDOWS_ME| & True if this is Windows ME.\\ |IS_OS_WINDOWS_NT| & True if this is Windows NT.\\ |IS_OS_WINDOWS_VISTA| & True if this is Windows Vista.\\ |IS_OS_WINDOWS_XP| & True if this is Windows XP.\\ \hline \end{tabular} \caption{Most relevant properties of \mycmd{SystemUtils}.} \label{tab:properties} \end{table}} Every time we want to call any of the available properties presented in Table~\ref{tab:properties}, we just need to use the |SystemUtils.PROPERTY| syntax, check the corresponding value through conditional expressions and define commands or arguments according to the underlying operating system. Let's go back to our examples and add a new plain rule featuring the new |@{SystemUtils}| orb tag. Right after running |arara helloindex| successfully (Code~\ref{code:araramakeexample}), we now have as a result a new |helloindex.pdf| file, but also a lot of auxiliary files, as we can see in Code~\ref{code:lsone}. \begin{code}[htbp] \caption{List of all files after running \mycmd{arara helloindex}.} \label{code:lsone} \begin{bash} $ ls helloindex.aux helloindex.ilg helloindex.log helloindex.tex helloindex.idx helloindex.ind helloindex.pdf \end{bash} \end{code} What if we write a new |clean| rule to remove all the auxiliary files? The idea is to use |rm| to remove each one of them. For now, let's stick with a system-specific rule -- don't worry, we will improve this rule later on. Since we want our rule to be generic enough, it's now a good opportunity to introduce the use of the reserved directive key |files|. This special key is a list that overrides the default |@{file}| value and replicates the directive for every element in the list. I'm sure this will be the easiest rule we've written so far. The |clean| rule is presented in Code~\ref{code:cleanone}. \begin{code}[htbp] \caption{\mycmd{clean.yaml}, first attempt.} \label{code:cleanone} \begin{yaml} !config identifier: clean name: CleaningTool command: rm -f "@{file}" arguments: [] \end{yaml} \end{code} Note that the command |rm| has a |-f| flag. As mentioned before, commands return an exit status after their calls. If we try to remove a nonexisting file, |rm| will complain and return a value different than zero. This will make \arara halt and print a big ``failure'' on screen, since a non-zero exit status is considered an abnormal execution. If we provide the |-f| flag, |rm| will not complain of a nonexisting file, so we won't be bothered for this trivial task. Now we need to add the new |clean| directive to our |helloindex.tex| file (Code~\ref{code:examplemakeindex}). Of course, |clean| will be the last directive, since it will only be reachable if everything executed before was returned withno errors. The new header of |helloindex.tex| is presented in Code~\ref{code:examplemakeindextwo}. \begin{code}[htbp] \caption{\mycmd{helloindex.tex} with the new \mycmd{clean} directive.} \label{code:examplemakeindextwo} \begin{latex} % (*@@*)arara: pdflatex % (*@@*)arara: pdflatex % (*@@*)arara: makeindex % (*@@*)arara: pdflatex % (*@@*)arara: clean: { files: [ helloindex.aux, helloindex.idx, helloindex.ilg, helloindex.ind, helloindex.log ] } \documentclass{article} ... \end{latex} \end{code} The reserved directive key |files| has five elements, so the |clean| rule will be replicated five times with the orb tag |@{file}| being expanded to each element. Time to run |arara helloindex| again and see if our new |clean| rule works! Code~\ref{code:araramakeexampletwo} shows both \arara execution and directory listing. We expect to find only our source |helloindex.tex| and the resulting |helloindex.pdf| file. \begin{code}[htbp] \caption{Running \mycmd{helloindex.tex} with the new \mycmd{clean} rule.} \label{code:araramakeexampletwo} \begin{bash} $ arara helloindex __ _ _ __ __ _ _ __ __ _ / _` | '__/ _` | '__/ _` | | (_| | | | (_| | | | (_| | \__,_|_| \__,_|_| \__,_| Running PDFLaTeX... SUCCESS Running PDFLaTeX... SUCCESS Running MakeIndex... SUCCESS Running PDFLaTeX... SUCCESS Running CleaningTool... SUCCESS Running CleaningTool... SUCCESS Running CleaningTool... SUCCESS Running CleaningTool... SUCCESS Running CleaningTool... SUCCESS $ ls helloindex.pdf helloindex.tex \end{bash} \end{code} Great, the |clean| rule works like a charm! But we have a big issue: if we try to use this rule in Windows, it doesn't work -- after all, |rm| is not a proper Windows command. Worse, replacing |rm| by the equivalent |del| won't probably work. Commands like |del| must be called in the form |cmd /c del|. Should we write another system-specific rule, say, |cleanwin|? Of course not, there's a very elegant way to solve this issue: the |@{SystemUtils}| orb tag. The idea is very simple: we check if \arara is running in a Windows operating system; if true, we set the command to |cmd /c del|, or |rm -f| otherwise. The new version of our |clean| rule is presented in Code~\ref{code:cleantwo}. \begin{code}[htbp] \caption{\mycmd{clean.yaml}, second attempt.} \label{code:cleantwo} \begin{yaml} !config identifier: clean name: CleaningTool command: @{ SystemUtils.IS_OS_WINDOWS ? "cmd /c del" : "rm -f" } "@{file}" arguments: [] \end{yaml} \end{code} There we go, our first cross-platform rule! There's no need of writing a bunch of system-specific rules; only one cross-platform rule is enough. We know that the |clean| rule will work as expected in every operating system, even if the task to be performed relies on system-specific commands. With cross-platform rules, we are able to write cleaner and more concise code. There's another way of writing the |clean| rule, now with a built-in function instead of the |@{SystemUtils}| orb tag: we can use a function named |isWindows()| to check if \arara is running in a Windows operating System. The third attempt of our |clean| rule is presented in Code~\ref{code:cleanthree}. \begin{code}[htbp] \caption{\mycmd{clean.yaml}, third attempt.} \label{code:cleanthree} \begin{yaml} !config identifier: clean name: CleaningTool command: @{ isWindows( "cmd /c del" , "rm -f" ) } "@{file}" arguments: [] \end{yaml} \end{code} Note that the |clean| rule is expecting |@{file}| to be overriden, since we rely on the reserved directive key |files|. If by any chance this rule is called without the |files| directive key, that is, an empty directive |% arara: clean|, I have very bad news to you: the rule will be expanded to |rm -f mydoc.tex| and your |.tex| file will be gone! Is there any way to avoid this behaviour? Yes, there is. For our fourth attempt of rewritting the |clean| rule, we will make use of two new built-in functions. The first one is named |isFalse()|, which only expands the value if the conditional expression resolves to false; the second one is named |getOriginalFile()|, which holds the original reference to the file processed by \arara. The idea here is very simple: if the current |@{file}| is different than the original file, run the task; otherwise, the whole command is expanded to an empty string -- empty commands are discarded by \arara. We will use a rule argument to hold the whole command, but note that the |flag| element is not important here, since we won't use this argument in the directive; only |default| matters in this context. The new |clean| rule is presented in Code~\ref{code:cleanfour}. \begin{code}[htbp] \caption{\mycmd{clean.yaml}, fourth attempt.} \label{code:cleanfour} \begin{yaml} !config identifier: clean name: CleaningTool command: @{remove} arguments: - identifier: remove default: @{ isFalse( file == getOriginalFile(), isWindows( "cmd /c del", "rm -f" ).concat(' "').concat(file).concat('"')) } \end{yaml} \end{code} Now we have a safe version of the |clean| rule. If we try to run \arara on our document with |% arara: clean|, nothing will happen and our original file won't be removed. That means that |clean| will only take action when we have an explicit list of files to be removed, and even if the element in the |files| list is different than the original file. Take a look in all the default rules available in the \href{http://github.com/cereda/arara}{project directory} on GitHub. They are very easy to understand. If you get stuck in any part, a good advice is to enable the logging feature through the |--log| flag, since \arara logs every expansion and command. \printbibliography[heading=subbibliography] \chapter{Reference for rule library} \label{chap:referenceforrulelibrarytwo} \epigraph{\emph{I first saw the \TeX book lying beside a brand new Macintosh Plus back in 1985 and was instantly amazed by both.}}{Enrico Gregorio} This chapter presents a list of built-in functions of \arara available in the rule context, as well as some notes on expansion. These functions have to be used always inside an orb tag, that is, |@{ }|, in order to properly work, since they are written for the MVEL expression language. \section{Functions} \label{sec:functions} \arara features some functions in order to ease trivial tasks during the writing process of a rule. In this section, we will present a list of these functions, including their parameters and return value. \subsection*{getOriginalFile} \begin{description} \item[Syntax] |string getOriginalFile()| \item[Description] Returns the original file reference processed by \arara as |string|. \end{description} \subsection*{isEmpty} \begin{description} \item[Syntax] |boolean isEmpty(string s)| \item[Description] Checks if |s| is empty and returns a |boolean| value: |true| if |s| is empty, |false| otherwise. \end{description} \begin{description} \item[Syntax] |string isEmpty(string s1, string s2)| \item[Description] Checks if |s1| is empty and returns a |string| value: |s2| if |s1| is empty, or an empty |string| otherwise. \end{description} \begin{description} \item[Syntax] |string isEmpty(string s1, string s2, string s3)| \item[Description] Checks if |s1| is empty and returns a |string| value: |s2| if |s1| is empty, or |s3| otherwise. \end{description} \subsection*{isNotEmpty} \begin{description} \item[Syntax] |boolean isNotEmpty(string s)| \item[Description] Checks if |s| is not empty and returns a |boolean| value: |true| if |s| is not empty, |false| otherwise. \end{description} \begin{description} \item[Syntax] |string isNotEmpty(string s1, string s2)| \item[Description] Checks if |s1| is not empty and returns a |string| value: |s2| if |s1| is not empty, or an empty |string| otherwise. \end{description} \begin{description} \item[Syntax] |string isNotEmpty(string s1, string s2, string s3)| \item[Description] Checks if |s1| is not empty and returns a |string| value: |s2| if |s1| is not empty, or |s3| otherwise. \end{description} \subsection*{isTrue} \begin{description} \item[Syntax] |boolean isTrue(string s)| \item[Description] Checks if |s| has any of the values in the \arara context that are considered |true| -- |true|, |yes|, |y| and |1| -- and returns a |boolean| value: |true| if |s| has a valid |true| value, or |false| otherwise. \end{description} \begin{description} \item[Syntax] |string isTrue(string s1, string s2)| \item[Description] Checks if |s1| has any of the values in the \arara context that are considered |true| -- |true|, |yes|, |y| and |1| -- and returns a |string| value: |s2| if |s1| has a valid |true| value, or an empty |string| otherwise. \end{description} \begin{description} \item[Syntax] |string isTrue(string s1, string s2, string s3)| \item[Description] Checks if |s1| has any of the values in the \arara context that are considered |true| -- |true|, |yes|, |y| and |1| -- and returns a |string| value: |s2| if |s1| has a valid |true| value, or |s3| otherwise. \end{description} \begin{description} \item[Syntax] |string isTrue(string s1, string s2, string s3, string s4)| \item[Description] Checks if |s1| has any of the values in the \arara context that are considered |true| -- |true|, |yes|, |y| and |1| -- and returns a |string| value: |s2| if |s1| has a valid |true| value, |s3| if |s1| has any of the values in the \arara context that are considered |false| -- |false|, |no|, |n| and |0| -- or |s4| otherwise as a default fallback. \end{description} \begin{description} \item[Syntax] |string isTrue(boolean b, string s)| \item[Description] Returns |s| if |b| is |true|, or an empty |string| otherwise. \end{description} \begin{description} \item[Syntax] |string isTrue(boolean b, string s1, string s2)| \item[Description] Returns |s1| if |b| is |true|, or |s2| otherwise. \end{description} \subsection*{isFalse} \begin{description} \item[Syntax] |boolean isFalse(string s)| \item[Description] Checks if |s| has any of the values in the \arara context that are considered |false| -- |false|, |no|, |n| and |0| -- and returns a |boolean| value: |true| if |s| has a valid |false| value, or |false| otherwise. \end{description} \begin{description} \item[Syntax] |string isFalse(string s1, string s2)| \item[Description] Checks if |s1| has any of the values in the \arara context that are considered |false| -- |false|, |no|, |n| and |0| -- and returns a |string| value: |s2| if |s1| has a valid |false| value, or an empty |string| otherwise. \end{description} \begin{description} \item[Syntax] |string isFalse(string s1, string s2, string s3)| \item[Description] Checks if |s1| has any of the values in the \arara context that are considered |false| -- |false|, |no|, |n| and |0| -- and returns a |string| value: |s2| if |s1| has a valid |false| value, or |s3| otherwise. \end{description} \begin{description} \item[Syntax] |string isFalse(string s1, string s2, string s3, string s4)| \item[Description] Checks if |s1| has any of the values in the \arara context that are considered |false| -- |false|, |no|, |n| and |0| -- and returns a |string| value: |s2| if |s1| has a valid |false| value, |s3| if |s1| has any of the values in the \arara context that are considered |true| -- |true|, |yes|, |y| and |1| -- or |s4| otherwise as a default fallback. \end{description} \begin{description} \item[Syntax] |string isFalse(boolean b, string s)| \item[Description] Returns |s| if |b| is |false|, or an empty |string| otherwise. \end{description} \begin{description} \item[Syntax] |string isFalse(boolean b, string s1, string s2)| \item[Description] Returns |s1| if |b| is |false|, or |s2| otherwise. \end{description} \subsection*{trimSpaces} \begin{description} \item[Syntax] |string trimSpaces(string s)| \item[Description] Returns |s| with the trailing and leading spaces trimmed. \end{description} \subsection*{getFilename} \begin{description} \item[Syntax] |string getFilename(string s)| \item[Description] This function takes a file path in the form of a |string| and returns a |string| containing only the file name, or an empty |string| in case of error. \end{description} \subsection*{getBasename} \begin{description} \item[Syntax] |string getBasename(string s)| \item[Description] Returns the base name of |s| as a |string|, that is, the file name without the extension, or an empty |string| in case of error. \end{description} \subsection*{getFiletype} \begin{description} \item[Syntax] |string getFiletype(string s)| \item[Description] Returns the file type of |s| as a |string|, that is, the extension of the file name, or an empty |string| in case of error. \end{description} \subsection*{getDirname} \begin{description} \item[Syntax] |string getDirname(string s)| \item[Description] This function takes a file path in the form of a |string| and returns a |string| containing only the directory structure without the file name, or an empty |string| in case of error. \end{description} \subsection*{isFile} \begin{description} \item[Syntax] |boolean isFile(string s)| \item[Description] Returns |true| if |s| is a valid reference to a file, or |false| otherwise. \end{description} \subsection*{isDir} \begin{description} \item[Syntax] |boolean isDir(string s)| \item[Description] Returns |true| if |s| is a valid reference to a directory, or |false| otherwise. \end{description} \subsection*{isWindows} \begin{description} \item[Syntax] |string isWindows(string s1, string s2)| \item[Description] Returns |s1| if \arara is running in a Windows operating system, or |s2| otherwise. \end{description} \subsection*{isLinux} \begin{description} \item[Syntax] |string isLinux(string s1, string s2)| \item[Description] Returns |s1| if \arara is running in a Linux operating system, or |s2| otherwise. \end{description} \subsection*{isUnix} \begin{description} \item[Syntax] |string isUnix(string s1, string s2)| \item[Description] Returns |s1| if \arara is running in a Unix operating system, or |s2| otherwise. \end{description} \subsection*{isMac} \begin{description} \item[Syntax] |string isMac(string s1, string s2)| \item[Description] Returns |s1| if \arara is running in a Mac operating system, or |s2| otherwise. \end{description} All the functions described are available in the rule context and can be concatenated in order to create more complex checkings. \section{Notes on expansion} \label{sec:notesonexpansion} It's important to observe that \arara always try to rely on a smooth fallback to empty strings in case of function errors or unused arguments. This approach allows the application to not halt in case of a recoverable situation. If, for example, \arara finds an empty command to execute -- like in the |clean| rule presented in Code~\ref{code:cleanfour} when |files| isn't used -- the task is simply ignored. That way, we can make more robust rules without worrying too much with expansion. Remember that \arara basically deals with string values, and some times, with boolean operations. We decided to stick with those two types because of simplicity. Taking care of string comparisons, using the built-in functions and limiting the scope of the command is sufficient to write good rules. \end{document}