summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/support/arara/chapters/introduction.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/doc/support/arara/chapters/introduction.tex')
-rw-r--r--Master/texmf-dist/doc/support/arara/chapters/introduction.tex4
1 files changed, 2 insertions, 2 deletions
diff --git a/Master/texmf-dist/doc/support/arara/chapters/introduction.tex b/Master/texmf-dist/doc/support/arara/chapters/introduction.tex
index 10f7af82084..f064774c9ae 100644
--- a/Master/texmf-dist/doc/support/arara/chapters/introduction.tex
+++ b/Master/texmf-dist/doc/support/arara/chapters/introduction.tex
@@ -48,7 +48,7 @@ Quite surprising. However, this behaviour is not wrong at all, it is completely
That is the major difference of \arara\ when compared to other tools: \emph{it is not an automatic process and the tool does not employ any guesswork on its own}. You are in control of your documents; \arara\ will not do anything unless you \emph{teach it how to do a task and explicitly tell it to execute the task}.
\end{messagebox}
-Now, how does one tell \arara\ to do a task? That is the actually the easy part, provided that you have everything up and running. We accomplish the task by adding a special comment line, hereafter known as \emph{directive}, somewhere in our \rbox{hello.tex} file (preferably in the first lines):
+Now, how does one tell \arara\ to do a task? That is actually the easy part, provided that you have everything up and running. We accomplish the task by adding a special comment line, hereafter known as \emph{directive}, somewhere in our \rbox{hello.tex} file (preferably in the first lines):
\begin{ncodebox}{Source file}{teal}{\icnote}{white}{hello.tex}
% arara: pdflatex
@@ -127,7 +127,7 @@ Our example has one directive, referencing \rbox{pdflatex}. It is important to o
Once \arara\ finds a directive, it will look for the associated \emph{rule}. In our example, it will look for a rule named \rbox{pdflatex} which will evidently run the \rbox{pdflatex} command line application. Rules are \gls{YAML} files named according to their identifiers followed by the \rbox{yaml} extension and follow a strict structure. This concept is covered in Section~\ref{sec:rule}, on page~\pageref{sec:rule}.
\begin{messagebox}{New feature in version 4.0}{araracolour}{\icattention}{white}
-\textbf{\gls{REPL} workflow} -- \arara\ now employs a \gls{REPL} workflow for rules and directives. In previous versions, directives were extracted, their corresponding rules were analized, commands were built and added to a queue before any proper execution or evaluation. I decided to change this workflow, so now \arara\ evaluates each rule on demand, i.e, there is no \emph{a priori} checking. A rule will \emph{always} reflect the current state, including potential side effects from previous executed rules.
+\textbf{\gls{REPL} workflow} -- \arara\ now employs a \gls{REPL} workflow for rules and directives. In previous versions, directives were extracted, their corresponding rules were analyzed, commands were built and added to a queue before any proper execution or evaluation. I decided to change this workflow, so now \arara\ evaluates each rule on demand, i.e, there is no \emph{a priori} checking. A rule will \emph{always} reflect the current state, including potential side effects from previous executed rules.
\end{messagebox}
Now, we have a queue of pairs $(\textit{directive}, \textit{rule})$ to process. For each pair, \arara\ will map the directive to its corresponding rule, evaluate it and run the proper command. The execution chain requires that command $i$ was successfully executed to then proceed to 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. How does one know if a command was successfully executed? \arara\ checks the corresponding \emph{exit status} available after a command execution. In general, a successful execution yields 0 as its exit status.