Persönlich finde ich es einfach eine Sache der Gewöhnung, dass in Ordnern von LaTeX-Projekten scheinbares Chaos herrscht. Ich erstelle mir üblicherweise einen Ordner pro Projekt, in dem dann eben alle Dateien, die während der verschiedenen Kompiliervorgänge so entstehen, liegen. Die Hilfsdateien fallen ja grob gesagt in zwei Kategorien:
1. Dateien, die Daten enthalten, die für den nächsten Kompiliervorgang wichtig sind, z.B. die `aux`-Datei für Querverweise, die `toc`-Datei für das Inhaltsverzeichnis usw.
2. Dateien, die Nachrichten und Details zum Kompiliervorgang enthalten, wie die `log`-Datei oder die `blg`-Datei, die von `biber` erzeugt wird.
Dateien aus der Kategorie eins würde ich in der Regel nicht löschen, solange das Dokument nicht fertig ist, da sie zur Fertigstellung benötigt werden.
## Löschen mit `arara` ##
Allerdings kann es manchmal doch praktisch sein, wenn man nach erfolgreicher Dokumenterstellung die Hilfsdateien wieder löschen kann. (Ich hatte mal ein Projekt aus ca. 50 recht ähnlichen Dokumenten, die alle zweimal kompiliert werden mussten, danach konnten die Hilfsdateien entfernt werden. Sie mussten auch alle im gleichen Ordner bleiben. Es hätte viele Aufräummöglichkeiten gegeben, doch mir gefiel der Ansatz mit `arara` auch am besten.)
Daher ist hier jetzt die deutsche Version meiner Antwort auf TeX.sx zu »[Deleting external/auxiliary files][1]«:
Es gibt Paulo Ceredas tolles [`arara`][2] (_The cool TeX automation tool_), ohne das ich mir nicht mehr vorstellen kann zu arbeiten. Es hat eine vordefinierte `clean`-Regel, die es ermöglicht anzugeben, welche Dateien nach der Kompilierung gelöscht werden sollen. Die folgende Datei namens `test.tex` würde zweimal kompiliert werden und dann würden die `aux`- und die `toc`-Datei gelöscht:
% arara: pdflatex
% arara: pdflatex
% arara: clean: { files: [ test.aux , test.toc ] }
\documentclass{article}
\begin{document}
\tableofcontents
\section{Test}
foo
\end{document}
Da ich es mühsam fand, immer den kompletten Dateinamen der Dateien anzugeben, die gelöscht werden sollen, [habe ich Paulo gefragt][3], ob es ein `arara`-Äquivalent für `\jobname` gebe,
% arara: clean: { files: [ \jobname.aux, \jobname.log ] }
das es ermöglichen würde, die `arara`-Anweisungen von einer Datei zur nächsten zu kopieren. [Er schrieb mir][4] die folgende nette Regel (Danke nochmal, Paulo):
<!-- language: yaml -->
!config
identifier: remove
name: Remove
command: <arara> @{remove}
arguments:
- identifier: remove
default: <arara> @{isNotEmpty(item, isWindows("cmd /c del", "rm -f").concat(' "').concat(getBasename(file))concat('.').concat(item).concat('"'))}
Korrekt installiert wird damit aus obigem Beispiel:
% arara: pdflatex
% arara: pdflatex
% arara: remove: { items: [ aux , toc ] }
\documentclass{article}
\begin{document}
\tableofcontents
\section{Test}
foo
\end{document}
## Mit `arara` in Ordner kopieren ##
Es folgt der Versuch einer `arara`-Regel, mit der man ausgewählte Dateien in einen anderen Ordner kopieren kann:
!config
# Backup rule for arara
# author: Clemens Niederberger
# version: 0.1 2014/05/21
# requires arara 3.0+
identifier: backup
name: Backup
command: <arara> @{backup}@{folder}
arguments:
- identifier: backup
default: <arara> @{isWindows("cmd /c copy", "cp -f").concat(' "')
.concat(getBasename(file)).concat('.')
.concat(isNotEmpty(item,item,"pdf"))
.concat('" ')}
- identifier: folder
flag: <arara> @{parameters.folder}
Diese Regel kann man nun folgendermaßen einsetzen,
% arara: backup: { folder: myfolder }
um die PDF-Datei in den Unterordner `myfolder` zu kopieren. Der Aufruf
% arara: backup: { folder: myfolder , items: [ tex , pdf ] }
würde entsprechend die `tex`- und die `pdf`-Datei kopieren. **Achtung: der Ordner, in den die Dateien kopiert werden soll, sollen, _muss_ angegeben werden. Außerdem muss der Ordner existieren.**
*Ich habe kein Windows und konnte daher nicht testen, ob die Regel unter Windows funktioniert. Feedback von Testern wäre daher willkommen.*
[1]: http://tex.stackexchange.com/q/24785/5049
[2]: http://cereda.github.io/arara/
[3]: http://chat.stackexchange.com/transcript/41?m=12167057#12167057
[4]: http://chat.stackexchange.com/transcript/message/12167091#12167091
