LATEXMK(1)

💖 LATEXMK 💖

okay bestie, welcome to LATEXMK(1) from the General Commands Manual — yes the section 1 one, the real one. buckle up, this is the lore. 🌸

---

✨ NAME ✨

latexmk — generate LaTeX document 🎀

---

🎀 SYNOPSIS 🎀

latexmk [options] [file ...]

---

💖 DESCRIPTION 💖

okay so latexmk completely automates the whole process of compiling a LaTeX document. like, fully. it's basically a specialized relative of the general make utility, except it figures out dependencies automatically and also has a bunch of other genuinely useful features. in its basic mode of operation you hand it the name of the primary source file for your document, and it fires off the appropriate sequence of commands to generate a .dvi, .ps, .pdf and/or hardcopy version of the document. 💅

by default, latexmk runs the commands necessary to generate a .dvi file — which copies the behavior of earlier versions when only latex was available. iykyk. 🦋

latexmk can also be set to run continuously with a suitable previewer. in that case the latex program (or one of its relatives), etc, get rerun whenever one of the source files is modified, and the previewer automatically updates the on-screen view of the compiled document. main character energy fr fr. ✨

latexmk determines which are the source files by examining the log file. (optionally, it also examines the list of input and output files generated by the -recorder option of modern versions of latex (and pdflatex, xelatex, lualatex). see the documentation for the -recorder option of latexmk below.) when latexmk is run, it examines properties of the source files, and if any have been changed since the last document generation, latexmk will run the various LaTeX processing programs as necessary. in particular, it will repeat the run of latex (or a related program)) often enough to resolve all cross references — depending on the macro packages used. with some macro packages and document classes, four, or even more, runs may be needed. if necessary, latexmk will also run bibtex, biber, and/or makeindex. in addition, latexmk can be configured to generate other necessary files. for example, from an updated figure file it can automatically generate a file in encapsulated postscript or another suitable format for reading by LaTeX. 😭 so helpful.

latexmk has two different previewing options. with the simple -pv option, a dvi, postscript or pdf previewer is automatically run after generating the dvi, postscript or pdf version of the document. the type of file to view is selected according to configuration settings and command line options.

the second previewing option is the powerful -pvc option (mnemonic: "preview continuously"). in this case, latexmk runs continuously, regularly monitoring all the source files to see if any have changed. every time a change is detected, latexmk runs all the programs necessary to generate a new version of the document. a good previewer will then automatically update its display. thus the user can simply edit a file and, when the changes are written to disk, latexmk completely automates the cycle of updating the .dvi (and/or the .ps and .pdf) file, and refreshing the previewer's display. it's not quite WYSIWYG, but usefully close. 💀

for other previewers, the user may have to manually make the previewer update its display, which can be (e.g., with some versions of xdvi and gsview) as simple as forcing a redraw of its display.

latexmk has the ability to print a banner in gray diagonally across each page when making the postscript file. it can also, if needed, call an external program to do other postprocessing on generated dvi and postscript files. (see the options -dF and -pF, and the documentation for the $dvi_filter and $ps_filter configuration variables.) these capabilities are leftover from older versions of latexmk, but are currently non-functional. more flexibility can be obtained in current versions, since the command strings for running *latex can now be configured to run multiple commands. this also extends the possibility of postprocessing generated files. 🫶

latexmk is highly configurable, both from the command line and in configuration files, so that it can accommodate a wide variety of user needs and system configurations. default values are set according to the operating system, so latexmk often works without special configuration on MS-Windows, cygwin, Linux, macOS, and other UNIX systems. see the section "Configuration/Initialization (rc) Files", and then the later sections "How to Set Variables in Initialization Files", "Format of Command Specifications", "List of Configuration Variables Usable in Initialization Files", "Custom Dependencies", and "Advanced Configuration". 👑

a very annoying complication handled very reliably by latexmk is that LaTeX is a multiple pass system. on each run, LaTeX reads in information generated on a previous run, for things like cross referencing and indexing. in the simplest cases, a second run of LaTeX suffices, and often the log file contains a message about the need for another pass. however, there is a wide variety of add-on macro packages to LaTeX, with a variety of behaviors. the result is to break simple-minded determinations of how many runs are needed and of which programs. latexmk has a highly general and efficient solution to these issues. the solution involves retaining between runs information on the source files, and a symptom is that latexmk generates an extra file (with extension .fdb_latexmk, by default) that contains the source file information. 💅 yes it makes a little friend. let it.

---

🌸 LATEXMK OPTIONS AND ARGUMENTS ON COMMAND LINE 🌸

in general the command line to invoke latexmk has the form

latexmk [options] [file]

all options can be introduced by single or double - characters, e.g., latexmk -help or latexmk --help. 🎀

Note 1: in the documentation, *latex means any of the supported engines, i.e., currently latex, lualatex, pdflatex, xelatex. mention of a specific one of these normally refers that specific engines. earlier versions of this documentation weren't so consistent. which of these is used to compile a document, depends on the configuration and the command line arguments.

Note 2: in addition to the options in the list below, latexmk recognizes almost all the options recognized by the *latex programs in their current TeXLive and MiKTeX implementations. some of the options for these programs trigger special action or behavior by latexmk, in which case they have specific explanations in this document; in this case they may or may not be passed to *latex as well.

run latexmk with the -showextraoptions to get a list of these other options that latexmk accepts but that are simply passed through to *latex. for details, see the explanation of the -showextraoptions option. ✨

---

💫 Definitions of options and arguments 💫

• file — one or more files can be specified. if no files are specified, latexmk will, by default, run on all files in the current working directory with a .tex extension. this behavior can be changed: see the description concerning the @default_files variable in the section "List of configuration variables usable in initialization files".

if a file is specified without an extension, then the .tex extension is automatically added, just as LaTeX does. thus, if you specify:

latexmk foo

then latexmk will operate on the file foo.tex. 🦋

there are certain restrictions on what characters can be in a filename; certain characters are either prohibited or problematic for the latex etc programs. these characters are: $, %, \, ~, the double quote character, and the control characters null, tab, form feed, carriage return, line feed, and delete. in addition & is prohibited when it is the first character of a filename.

latexmk gives a fatal error when it detects any of the above characters in the TeX filename(s) specified on the command line. however before testing for illegal characters, latexmk removes matching pairs of double quotes from a filename. this matches the behavior of latex etc, and deals with problems that occasionally result from filenames that have been incorrectly quoted on the command line. in addition, under Microsoft Windows, the \ character is a directory separator, so latexmk replaces it by a forward slash /, which is also a legal directory separator in Windows, and is accepted by latex etc. 😭 (the way Windows does this to us...)

• -auxdir=FOO or -aux-directory=FOO — sets the directory for auxiliary output files of *latex (.aux, .log etc). these are all the generated files, with the exception of final output files (.dvi, .ps, .pdf, .synctex.gz, .synctex). see the -outdir/-output-directory option for directories for the main output files, and the -out2dir option for the final output files.

if the directory specified for the -aux/-aux-directory option is blank, then the default is used, which is to be the same as the output directory.

if you also use the -cd option, and the specified auxiliary output directory is a relative path, then the path is interpreted relative to the document directory.

see the section AUXILIARY AND OUTPUT DIRECTORIES for more details. 🎀

• -bibtex — when the source file uses bbl files for bibliography, run bibtex or biber as needed to regenerate the bbl files.

this property can also be configured by setting the $bibtex_use variable to 2 in a configuration file. ✨

• -bibtex- — never run bibtex or biber. also, always treat .bbl files as precious, i.e., do not delete them in a cleanup operation. 🙈

a common use for this option is when a document comes from an external source, complete with its bbl file(s), and the user does not have the corresponding bib files available. in this situation use of the -bibtex- option will prevent latexmk from trying to run bibtex or biber, which would result in overwriting of the bbl files.

this property can also be configured by setting the $bibtex_use variable to 0 in a configuration file.

• -bibtex-cond — when the source file uses a bbl file for the bibliography and bibtex is used to generate the bibliography, run bibtex as needed to regenerate the bbl files only if the relevant bib file(s) exist. thus when the bib file(s) are not available, bibtex is not run, thereby avoiding overwriting of the bbl file. also, always treat .bbl files as precious, i.e., do not delete them in a cleanup operation. 💖

this is the default setting. it can also be configured by setting the $bibtex_use variable to 1 in a configuration file.

The reason we even bother with this setting is twofold, bestie. First: it lets latexmk auto-switch between using and not-using bibtex, depending on whether a bib file actually exists or not. Second: when you're submitting to a scientific journal, the norm is to send just the .tex and .bbl files (plus your graphics), and no .bib file at all. So like, it's genuinely useful to treat .bbl files as real source files that deserve to be preserved when a cleanup runs. 💖

You can also set this whole thing up by setting the $bibtex_use variable to 1 in a config file.

🚨 Heads up: when biber is the one running, and there's no bib file, this option does not stop biber from running — and then the bbl file ends up incorrect. See the docs on $bibtex_use for the full tea. That said, a bbl file is treated as precious during a cleanup operation.

---

• -bibtex-cond1 — literally -bibtex-cond but the .bbl files only get treated as precious if one or more bibfiles fails to exist.

So: if every bib file is there, bibtex runs and generates .bbl files as needed, and then it's totally appropriate to delete those bbl files in a cleanup, because they can just be re-generated. ✨

You can also configure this by setting $bibtex_use to 1.5 in a config file.

🚨 Same warning as above, fr fr: when biber is used and a bib file doesn't exist, this option does not prevent biber from running, and the bbl file will be incorrect. Check the $bibtex_use docs for more. However — a bbl file is treated as precious in a cleanup operation.

• -bibtexfudge or -bibfudge — turn on the change-directory fudge for bibtex. See the documentation of $bibtex_fudge for the details. 🫶
• -bibtexfudge- or -bibfudge- — turn off the change-directory fudge for bibtex. See the documentation of $bibtex_fudge for the details.
• -bm <message> — a banner message to print diagonally across every page when converting the dvi file to postscript. The message has to be a single argument on the command line, so be careful with quoting spaces and all that. 🙈

Note: if you specify -bm, the -ps option is assumed. Periodt.

• -bi <intensity> — how dark to print that banner message. A decimal number between 0 and 1. 0 is black, 1 is white. The default is 0.95, which is fine unless your toner cartridge is running on fumes. 💀
• -bs <scale> — a decimal number specifying how large the banner message gets printed. You're gonna have to experiment to nail the right scale for your message — rule of thumb, the scale should be roughly 1100 divided by the number of characters in the message. Default is 220.0, which is just right for 5-character messages. ✨
• -commands — list the commands latexmk uses for processing files, and then exit. 👑
• -c — clean up (remove) all the regeneratable files generated by latex and bibtex or biber, except dvi, postscript and pdf. These files are a combo of log files, aux files, latexmk's database file of source file information, and those with extensions specified in the @generated_exts configuration variable. On top of that, files specified by the $clean_ext and @generated_exts configuration variables get removed too.

This cleanup happens instead of a regular make. If you want a cleanup followed by a make, go look at the -gg option. 🦋

Treatment of .bbl files: if $bibtex_use is set to 0 or 1, bbl files are always treated as non-regeneratable. If $bibtex_use is set to 1.5, bbl files are counted as non-regeneratable conditionally — if the bib file exists, then bbl files are regeneratable and get deleted in a clean up. But if $bibtex_use is 1.5 and a bib file doesn't exist, then the bbl files are treated as non-regeneratable and therefore are not deleted.

Meanwhile, if $bibtex_use is set to 2, bbl files are always treated as regeneratable, and get deleted in a cleanup.

Treatment of files generated by custom dependencies: if $cleanup_includes_cusdep_generated is nonzero, regeneratable files are considered as including those generated by custom dependencies, and they get deleted too. Otherwise, these files are not deleted.

• -C — clean up (remove) all regeneratable files generated by latex and bibtex or biber. This is the same as the -c option, plus dvi, postscript and pdf files, and those specified in the $clean_full_ext configuration variable. 🔥

This cleanup is instead of a regular make. See the -gg option if you want a cleanup followed by a make.

See the -c option for the spec on whether or not .bbl files are treated as non-regeneratable or regeneratable.

If $cleanup_includes_cusdep_generated is nonzero, regeneratable files are considered as including those generated by custom dependencies and are also deleted. Otherwise these files are not deleted.

• -CA — (Obsolete). Now equivalent to the -C option. See that option for the details. 💀
• -cc — "Continuous compile" without a previewer. Equivalent to -pvc -view=none.
• -cd — change to the directory containing the main source file before processing it. Then all the generated files (.aux, .log, .dvi, .pdf, etc) will be relative to the source file. 🎀

This option is especially useful when latexmk is invoked from a GUI that's configured to invoke latexmk with a full pathname for the source file.

It works by setting the $do_cd configuration variable to one; you can set that variable if you want latexmk to have the effect of -cd without specifying it on the command line. See the docs for that variable.

• -cd- — do NOT change to the directory containing the main source file before processing it. Then all the generated files (.aux, .log, .dvi, .pdf, etc) will be relative to the current directory rather than the source file.

This is the default behavior and it matches what the *latex programs do. However, it's not desirable behavior when latexmk gets invoked by a GUI configured to pass a full pathname for the source file. See the -cd option.

This option works by setting the $do_cd configuration variable to zero. See the documentation for that variable for more info.

• -CF — remove the file containing the database of source file information, before doing the other actions requested. 🧚
• -d — set draft mode. This prints the banner message DRAFT across your page when converting the dvi file to postscript. Size and intensity can be modified with the -bs and -bi options. The -bm option will override this one, since it's really just a short way of specifying:

latexmk -bm DRAFT

Note: if you specify -d, the -ps option is assumed.

• -deps — show a list of dependent files after processing. This comes in the form of a dependency list of the form used by the make program, so it's suitable for use in a Makefile. It gives you an overall view of the files without listing intermediate files, as far as latexmk can determine them. 👑

By default the list of dependent files is sent to stdout (i.e., normally to the screen, unless you've redirected latexmk's output). But you can set the filename where the list goes using the -deps-out= option.

See the section "USING latexmk WITH make" for an example of how to use a dependency list with make.

If you're familiar with GNU automake and gcc, you'll find that -deps is very similar in purpose and results to the -M option to gcc. (In fact, latexmk also has options -M, -MF, and -MP that behave like those of gcc.)

• -dependents — equivalent to -deps.
• -deps- — do not show a list of dependent files after processing. (This is the default.)
• -dependents- — equivalent to -deps-.
• -deps-escape=<string> — set the kind of escaping used for spaces in the dependency list. The possible values are "none", "unix", "nmake", corresponding respectively to no escaping, escaping with a "\" suitable for standard Unix make, and escaping with "^", suitable for Microsoft's nmake. 🌈
• -deps-out=FILENAME — set the filename to which the list of dependent files is written. If the FILENAME argument is omitted or set to "-", then the output is sent to stdout.

Using this option also turns on the output of the list of dependent files after processing. ✨

• -dF — dvi file filtering. The argument to this option is a filter which will generate a filtered dvi file with the extension ".dviF". All extra processing (e.g. conversion to postscript, preview, printing) will then be performed on this filtered dvi file. 🦋

Example usage — to use dviselect to select only the even pages of the dvi file:

latexmk -dF "dviselect even" foo.tex

• -diagnostics — print detailed diagnostics during a run. This may help when you're debugging problems, or trying to understand latexmk's behavior in difficult situations. 🔍
• -dir-report — for each .tex file processed, list the settings for the aux and out directories, after they've been normalized from the settings specified during initialization. See the description of the variable $aux_out_dir_report for more details.
• -dir-report- — do not report the settings for aux and out directories. (Default)
• -dir-report-only — after all initialization is complete, give the settings for the aux and out directories, and then halt. This option is primarily used for debugging configuration issues. 💅
• -dvi — generate a dvi version of the document using latex. (And turn off any incompatible requests.)
• -dvilua — generate a dvi version of the document using lualatex instead of latex. (And turn off any incompatible requests.) 🌸
• -dvi- — no dvi for you bestie 💅 this turns OFF generating the dvi version of your doc. lowkey a heads up though: this can get overridden — if some other file ends up getting made (say a .ps file) that comes from the dvi file, or if literally no generated file is requested at all, then yeah, it sneaks back on. iykyk.
• -dvilualatex="COMMAND" — sets the string for the command that runs dvi lualatex. it does the same thing as -pdflatex but for the variable $dvilualatex instead 🎀

⚠️ note bestie: when you give it a COMMAND argument, this only sets the command for invoking dvilualatex. it does NOT actually turn on dvilualatex. that part is done by other options or in an initialization file. no cap.

• -e <code> — runs the init code you give it before processing anything. the code is Perl, same flavor as what goes in latexmk's initialization files. want the deep lore? peep the -r option and the section about "Configuration/initialization (RC) files". usually it's just a lil sequence of assignment statements, semicolons between them, you know the vibe.

the code fires the moment the -e option gets hit while latexmk is parsing its command line. (if you want init code from a file instead, that's the -r option's whole thing.) if there's an error, latexmk straight up stops 💀. you can stack multiple -r and -e options and they run in the order they show up on the command line.

okay so quoting special characters in the code is a whole situation, be careful. say you want to set the latex command to use its -shell-escape option — under UNIX/Linux you could do:

latexmk -e '$latex=q/latex %O -shell-escape %S/' file.tex

the single quotes stop normal UNIX/Linux command shells from treating the characters inside as special ✨ (and in this example, that q/.../ thing is a Perl idiom that's basically single quotes — it dodges the whole nightmare of getting a quote character inside an already-quoted string, in a way that doesn't care about your shell or your OS.)

this next bit matters: that command line will NOT work under MS-Windows with cmd.exe or command.com or 4nt.exe. for MS-Windows with those shells, use this instead:

latexmk -e "$latex=q/latex %O -shell-escape %S/" file.tex

or

latexmk -e "$latex='latex %O -shell-escape %S'" file.tex

and those last two? they will NOT work with UNIX/Linux command shells. periodt.

🙈 side note: those examples are just showing how to use -e to feed in init code. but you can get that exact same effect with the -latex option, with way fewer quoting headaches.

• -emulate-aux-dir — emulates having an aux directory instead of leaving it up to the latex programs to do it themselves. (MiKTeX supports -aux-directory, but TeXLive does *not 🫠)

head to the section AUXILIARY AND OUTPUT DIRECTORIES for the full tea.

• -emulate-aux-dir- — turns OFF the emulation that implements an aux directory, and leaves it to the *latex program to handle the case where the aux directory is different from the output directory. heads up: if you're on TeXLive (which doesn't support -aux-directory), latexmk will automatically switch aux_dir emulation back on after the first run of *latex — because it'll find the .log file in the wrong place. iconic behavior honestly.
• -f — force mode, bestie 🔥 makes latexmk keep processing the document even when there are errors. normally, if latexmk notices LaTeX or some other program hit an error that further processing won't fix, it just stops.

note: "further processing" here means running other programs, or rerunning latex (etc), that would've happened if no errors had occurred. if you also (or instead) want the latex (etc) program to not pause waiting on user input after an error, arrange that with an option passed to the program — like latexmk's -interaction=nonstopmode option, which latexmk passes along to *latex.

• -f- — turns off the forced processing-past-errors that -f sets. handy for overriding a setting from a configuration file 👑
• -g — go mode, go mode, GO MODE 🏃‍♀️💨 forces latexmk to run every rule at least once, even in situations where it'd normally decide nothing changed in the source files since the last run. super useful if you, say, changed the configuration and want everything reprocessed.

equivalently: all rules start out regarded as out of date. the downside tho: if you've got, like, a ton of custom dependencies for making graphics files, all of them will run, and that can eat up SO much time. also check out -gt, which only forces a rerun of *latex.

• -g- — turns off -g.
• -gg — "super go mode" aka "clean make" ✨ it cleans out generated files as if you'd given -C, and then does a regular make. fresh start energy.
• -gt — requires at least one run of latex. like, process as normal, except at least one run of the *latex rule *has to happen, even when latexmk's normal methods lead it to conclude a run of *latex isn't needed.

equivalently, treat the latex rule as initially out-of-date. and note: latexmk might still separately detect that *other rules are out-of-date by its normal methods — and if those normally run before *latex, they'll still be run 🎀

this one is especially useful when you've changed some config, or under certain error conditions where latexmk wouldn't correctly detect that it needs to run *latex, but a run is genuinely needed.

• -h or -help — prints help info. classic.
• -hnt — generates an hnt (HINT) version of the document using hilatex. (and turns off any incompatible requests, obviously 💅)
• *-jobname=STRING* — sets the basename of the output file(s) to STRING, instead of the default, which is the basename of the TeX file you specified. (as of rn, STRING shouldn't have spaces in it!)

this is like the same option for current implementations of *latex, and passing this option to those programs is part of how latexmk implements -jobname.

one enhancement tho: STRING can contain the placeholder %A, which gets substituted with the basename of the TeX file. the main reason this exists is when you pass multiple files on latexmk's command line and you want a jobname that differs per file. example time — say you had test1.tex and test2.tex, and you wanted to compare *latex's compilation results against xelatex's. on a unix-type OS you could run:

latexmk -pdf -jobname=%A-pdflatex *.tex
latexmk -pdfxe -jobname=%A-xelatex *.tex

then the .aux, .log, and .pdf files from pdflatex would have basenames test1-pdflatex and test2-pdflatex, while from xelatex they'd be test1-xelatex and test2-xelatex 🦋

under MS-Windows with cmd.exe, you'd need to double the percent sign so the percent character actually gets passed to latexmk instead of being used to substitute an environment variable:

latexmk -pdf -jobname=%%A-pdflatex *.tex
latexmk -pdfxe -jobname=%%A-xelatex *.tex

• -l — run in landscape mode, using landscape mode for the previewers and the dvi-to-postscript converters. ngl you don't really need this nowadays, since current previewers usually figure that info out on their own.
• -l- — turns off -l.
• -latex — this sets the generation of dvi files by latex, and turns off generating pdf and ps files.

note: to set the command used when latex is specified, see the -latex="COMMAND" option.

• -latex="COMMAND" — sets the string specifying the command to run latex, typically used to add whatever options you want. since the string usually has spaces, quote it, like:

latexmk -latex="latex --shell-escape %O %S"  foo.tex

the contents of the string work the same as the $latex configuration variable. depending on your OS and command-line shell, you might need to swap those single quotes for double quotes (or something else entirely) 🙃

note: when you give it a COMMAND argument, this only sets the command for invoking latex — it does NOT turn on the use of latex. that's other options or an initialization file's job.

want to set the command for running pdflatex instead of latex? that's the -pdflatex option, bestie.

• -logfilewarninglist, -logfilewarnings — after a run of *latex, gives you a list of warnings about undefined citations and references (unless silent mode is on 🔇).

also peep the $silence_logfile_warnings configuration variable.

• -logfilewarninglist-, -logfilewarnings- — after a run of *latex, does not give you that list of warnings about undefined citations and references. (this is the default!)

also peep the $silence_logfile_warnings configuration variable.

• -lualatex — use lualatex 💜 like, use lualatex to process the source file(s) to pdf. generation of dvi, hnt, postscript and xdv files gets turned off.

this option = this exact set of options:

-pdflua -dvi- -ps-

note: the method of implementation here differs from some earlier versions of latexmk — but the intended effect does not.

• -lualatex="COMMAND" — sets the string specifying the command to run lualatex. behaves like the -pdflatex option, but sets the variable $lualatex.

note: when you give it a COMMAND argument, this only sets the command for invoking lualatex — it does NOT turn on the use of lualatex. other options or an initialization file do that part.

• -M — shows the list of dependent files after processing. this is equivalent to the -deps option ✨
• -MF file — if a list of dependents is getting made, this is the file it gets written to. That's the whole assignment. 💅
• -MP — if a list of dependents is getting made, include a phony target for each source file. Why do we care? Because if you drop that dependents list into a Makefile, those dummy rules work around the errors the program make gives you when you delete header files without updating the Makefile to match. Protective queen behavior. 🎀
• -makeindexfudge — turns ON the change-directory fudge for makeindex. Full details live in the documentation of $makeindex_fudge.
• -makeindexfudge- — turns OFF the change-directory fudge for makeindex. Same place for the deets: the documentation of $makeindex_fudge. ✨
• $min_sleep_time [0.01] — this is the minimum nonzero value allowed for $sleep_time. Literally the floor, bestie.
• -MSWinBackSlash — only does anything when latexmk is running under MS-Windows. Here's the vibe: when latexmk runs a command under MS-Windows, the Windows standard directory separator "\" is used to separate directory components in a file name. Internally tho, latexmk uses "/" for the directory separator character — which is the one Unix-like systems use.

This is the default behavior. BUT the default may have been overridden by a configuration file (latexmkrc file) that sets $MSWin_back_slash=0. So like, check your rc file if things look weird. 🙈

• -MSWinBackSlash- — also only matters when latexmk is running under MS-Windows. This one means: when latexmk runs a command under MS-Windows, the substitution of "\" for the separator character between directory components of a file name is not done. Instead the forward slash "/" is used, same as on Unix-like systems. This is acceptable in most situations under MS-Windows, provided that filenames are properly quoted, as latexmk does by default. 🫶

See the documentation for the configuration variable $MSWin_back_slash for more details.

• -new-viewer — in continuous-preview mode, always start a new viewer to look at the generated file. By default, latexmk will (in continuous-preview mode) test for a previously running previewer for the same file and not start a new one if a previous previewer is already running. The catch? That test sometimes fails — notably if there's an already-running previewer viewing a file with the same name as the current file, but in a different directory. This option turns off the default behavior. 😭
• -new-viewer- — the inverse of the -new-viewer option. It puts latexmk back in its normal behavior: in preview-continuous mode it checks for an already-running previewer. ⭐
• -nobibtex — never run bibtex or biber. Equivalent to the -bibtex- option. Not me ghosting the bibliography tool entirely 💀
• -nobibtexfudge or -nobibfudge — turn off the change-directory fudge for bibtex. See the documentation of $bibtex_fudge for details.
• -noemulate-aux-dir — turn aux_dir emulation off. Same as -emulate-aux-dir-.
• -nomakeindexfudge — turn off the change-directory fudge for makeindex. See the documentation of $makeindex_fudge for details.
• -norc — turn off the automatic reading of initialization (rc) files.

N.B. Normally the initialization files are read and obeyed, and then command line options are obeyed in the order they are encountered. But -norc is an exception to this rule: it is acted on first, no matter where it occurs on the command line. Main character energy, honestly. 👑

• -outdir=FOO or -output-directory=FOO — sets the directory for the output files of *latex.

If the aux directory is not set, or is the same as the output directory, then all output files of *latex are sent to the output directory.

If the aux directory is set (e.g., by the option -auxdir) and is not equal to the output directory, then only the primary output files (.dvi, .ps, .pdf, .synctex, .synctex.gz) are sent to the output directory. Other generated files are sent to the aux directory.

See the section AUXILIARY AND OUTPUT DIRECTORIES for more details. 🦋

• -out2dir=FOO — (Experimental new feature.) 🧪

Sets the directory for the final output files of a whole round of compilations.

The use of this directory solves, among other things, the problem that when multiple runs of *latex and other programs are needed, files like the main pdf file from pdflatex, etc. will be changed multiple times. A viewer like SumatraPDF that reloads the file whenever it detects changes will show a distracting sequence of intermediate states of the pdf file, rather than just the final version after all the repeated runs of *latex etc. have been done. Instead, when a distinct final-output directory is set — by the -out2dir option or the equivalent $out2_dir variable — the viewer will only see a changed pdf (etc.) file after the full sequence of repeated runs of *latex etc. has finished. Obsessed with the glow-up reveal at the end. ✨

By default the final output directory is the same as the output directory (as specified by the -outdir option or the setting of the $out_dir configuration variable).

• -output-format=FORMAT — this option is one that is allowed for latex, lualatex, and pdflatex. But it is not passed to these programs. Instead latexmk emulates it in a way suitable for the context of latexmk and its workflows.
  • -If FORMAT is dvi, then dvi output is turned on, and postscript, pdf and xdv output are turned off. This is equivalent to using the options -dvi -ps- -pdf- -xdv-.
  • If FORMAT is pdf, then pdf output is turned on, and dvi, postscript and xdv output are turned off. This is equivalent to using the options -pdf -ps- -dvi- -xdv-.
  • If FORMAT is anything else, latexmk gives an error. 🚨
• -p — print out the document. By default the file to be printed is the first in the list postscript, pdf, dvi that is being made. But you can use the -print=... option to change the type of file to be printed, and you can configure this in a start up file (by setting the $print_type variable). 💖

However, printing is enabled by default only under UNIX/Linux systems, where the default is to use the lpr command and only on postscript files. In general, the correct behavior for printing very much depends on your system's software. In particular, under MS-Windows you must have suitable program(s) available, and you must have configured the print commands used by latexmk. This can be non-trivial. 😭 See the documentation on the $lpr, $lpr_dvi, and $lpr_pdf configuration variables to see how to set the commands for printing.

This option is incompatible with the -pv and -pvc options, so it turns them off.

• -pdf — generate pdf version of document using pdflatex. (And turn off any incompatible requests.)

(If you wish to use lualatex or xelatex, you can use whichever of the options -pdflua, -pdfxe, -lualatex or -xelatex applies.) To configure latexmk to have such behavior by default, see the section on "Configuration/initialization (rc) files". 🌸

• -pdfdvi — generate dvi file and then pdf version of document from the dvi file, by default using dvipdf. (And turn off any incompatible requests.)

The program used to compile the document to dvi is latex by default, but this can be changed to dvilulatex by the use of the -dvilua option or by setting $dvi_mode to 2.

• -pdflua — generate pdf version of document using lualatex. (And turn off any incompatible requests.) 💜
• -pdfps — generate dvi file, ps file from the dvi file, and then pdf file from the ps file. (And turn off any incompatible requests.)

The program used to compile the document to dvi is latex by default, but this can be changed to dvilulatex by the use of the -dvilua option or by setting $dvi_mode to 2.

• -pdfxe — generate pdf version of document using xelatex. (And turn off any incompatible requests.)

Note that to optimize processing time, latexmk uses xelatex to generate an .xdv file rather than a pdf file directly. Only after possibly multiple runs to generate a fully up-to-date .xdv file does latexmk then call xdvipdfmx to generate the final .pdf file. 🦋

(Note: The reason why latexmk arranges for xelatex to make an .xdv file instead of the xelatex's default of a .pdf file is as follows: When the document includes large graphics files, especially .png files, the production of a .pdf file can be quite time consuming, even when the creation of the .xdv file by xelatex is fast. So the use of the intermediate .xdv file can result in substantial gains in processing time, since the .pdf file is produced once rather than on every run of xelatex.) — efficiency queen behavior, we love to see it 👑

• -pdf- — turn off generation of pdf version of document. (This can be used to override a setting in a configuration file. It may get overridden if some other option requires the generation of a pdf file.)

If after all options have been processed, pdf generation is still turned off, then generation of a dvi file will be turned on, and then the program used to compiled a document will be latex (or, more precisely, whatever program is configured to be used in the $latex configuration variable).

• -pdflatex — set the generation of pdf files by pdflatex. (And turn off any incompatible requests.)

Note: to set the command used when pdflatex is specified, see the -pdflatex="COMMAND" option.

• -pdflatex="COMMAND" — this sets the string specifying the command to run pdflatex, and is typically used to add desired options. Since the string normally contains spaces, it should be quoted, e.g.,

latexmk -pdf -pdflatex="pdflatex --shell-escape %O %S" foo.tex

The specification of the contents of the string are the same as for the $pdflatex configuration variable. (The option -pdflatex in fact sets the variable $pdflatex.) Depending on your operating system and the command-line shell you are using, you may need to change the single quotes to double quotes (or something else). 🙈

• -pdflatex="COMMAND" — 💅 heads up bestie, when you give this one a COMMAND it only sets the command used to invoke pdflatex. It does not flip pdflatex on for you. That part is somebody else's job — other options do it, or your initialization file does it.

And if what you actually want is to set the command for running latex (not the command for pdflatex), go look at the -latex option instead, okay? 🫶

• -pdflualatex="COMMAND" — literally just the same thing as -lualatex="COMMAND". twin behavior, no notes. 💖
• -pdfxelatex="COMMAND" — and this one? exactly -xelatex="COMMAND". periodt. ✨
• -pretex=CODE — so CODE is some TeX code, and this option tells latexmk to run that code before inputting the source file. It only works if the command for invoking the relevant *latex is set up the right way. For the deets, see the docs on the variable $pre_tex_code, plus the substitution strings %P and %U. Under the hood, this option works by setting the variable $pre_tex_code. 🧚

Also peep the -usepretex option.

Like, an example:

latexmk -pretex='\AtBeginDocument{Message\par}' -usepretex foo.tex

but honestly this is better written as

latexmk -usepretex='\AtBeginDocument{Message\par}' foo.tex

And if you already have a suitable command configured, you only need

latexmk -pretex='\AtBeginDocument{Message\par}' foo.tex

• -print=dvi, -print=ps, -print=pdf, -print=auto — picks which kind of file gets printed. This option also makes sure the file you need actually gets made, and it turns printing on. 🔥

The default case, -print=auto, figures out the print file type all by itself based on the set of files being made. It goes down the list postscript, pdf, dvi, and the first one of those that's among the files to be made is the one that gets printed out.

• -ps — generate a postscript version of the document. (And turn off any requests that don't play nice with it.) 👑
• -ps- — turn off generating the postscript version. Use this to override a setting in a configuration file. Fair warning though: it may get overridden right back by some other option that needs a postscript file — like a request to print. 💀
• -pF — postscript file filtering ✨. The argument here is a filter, and it'll generate a filtered postscript file with the extension .psF. All the extra processing after that (preview, printing, all of it) happens on this filtered postscript file instead.

Example of usage — use psnup to print two pages on one page:

latexmk -ps -pF 'psnup -2' foo.tex

or

latexmk -ps -pF "psnup -2" foo.tex

Whether you go single or double quotes round the "psnup -2" depends on your command interpreter, i.e. on the particular version of perl and the operating system on your computer. iykyk 🐚

• -pv — run the file previewer 🎀. If the -view option is used, that's what selects which kind of file gets previewed (.pdf, .ps or .dvi). Otherwise the viewer looks at the "highest" kind of output file that's made, and the ordering there goes .pdf, .ps, .dvi (high to low). This option does not get along with the -p and -pvc options, so it turns them off. 💅
• -pv- — turn off -pv. simple as that bestie.
• -pvc — "Continuous preview mode" 👑, aka: compile the document, run a file previewer, then regularly check for changed source files and recompile as needed. (See the Description above.) Which files get generated and which one gets viewed is governed by the other options, and it works the same as for the -pv option.

The preview-continuous option -pvc can only work with one file. So when you use this option, you should only specify one filename on the command line. It's also incompatible with the -p and -pv options, so it turns those off too.

-pvc also turns off force mode, because that's normally the best vibe for continuous preview mode. If you really want force mode, use the options in the order -pvc -f.

If you want a "continuous compile" but do not want a previewer running, then do -pvc -view=none. 😌

With a good previewer, the display updates automatically when the viewed file changes. (Under some but not all versions of UNIX/Linux, gv -watch does this for postscript files; this can be set by a configuration variable. It would also work for pdf files except for an apparent bug in gv that causes an error when the newly updated pdf file is read.) Many other previewers will need a manual update. 🦋

Important note: the acroread program on MS-Windows locks the pdf file and prevents new versions from being written, so it is a bad idea to use acroread to view pdf files in preview-continuous mode. Use a different viewer instead: SumatraPDF and gsview are good possibilities. 💀

There are some other methods for arranging an update, notably useful for many versions of xdvi and xpdf. These are best set in latexmk's configuration; see below.

Note that if latexmk dies or is stopped by the user, the "forked" previewer keeps running. Successive invocations with the -pvc option will not fork new previewers, but latexmk will normally use the existing previewer. (At least this happens when latexmk is running under an operating system where it knows how to determine whether an existing previewer is running.) 🫶

• -pvc- — turn off -pvc.
• -pvctimeout — do a timeout in pvc mode after a period of inactivity, which is 30 min. by default. "Inactivity" means a stretch where latexmk has detected no file changes and therefore hasn't taken any actions like compiling the document. ⏰
• -pvctimeout- — don't do a timeout in pvc mode after inactivity.
• -pvctimeoutmins=<time> — set the period of inactivity, in minutes, for the pvc timeout.
• -quiet — same as -silent 🤫
• -r <rcfile> — read the specified initialization file ("RC file") before processing.

Be careful about the ordering, bestie, this is the part people get wrong: (1) Standard initialization files — see the section below on "Configuration/initialization (RC) files" — are read first. (2) Then the options on the command line are acted on in the order they're given. So if an initialization file is specified by the -r option, it gets read during this second step. Which means an initialization file specified with -r can override both the standard initialization files and previously specified options. But all of these can be overridden by later options. 💅

The contents of the RC file are just a piece of code in the Perl programming language (typically a sequence of assignment statements); they're executed when the -r option is encountered during latexmk's parsing of its command line. See the -e option for a way of giving initialization code directly on latexmk's command line. An error results in latexmk stopping. Multiple instances of the -r and -e options can be used, and they are executed in the order they appear on the command line. 🌸

• -rc-report — after initialization, give a list of the RC files read. (This is the default.) 📋
• -rc-report- — after initialization, do not give a list of the RC files read.
• -recorder — give the -recorder option with *latex. In (most) modern versions of these programs, this results in a file of extension .fls containing a list of the files these programs have read and written. Latexmk will then use this file to improve its detection of source files and generated files after a run of *latex. This is the default setting of latexmk, unless overridden in an initialization file. 🔥

For further info, see the documentation for the $recorder configuration variable.

• -recorder- — do not supply the -recorder option with *latex.
• -rules — show a list of latemk's rules and dependencies after processing. 👑
• -rules- — do not show a list of latexmk's rules and dependencies after processing. (This is the default.)
• -showextraoptions — show the list of extra *latex options that latexmk recognizes, but that it simply passes straight through to the programs *latex when they're run. ✨

These options are (currently) a combination of those allowed by the TeXLive and MiKTeX implementations. (If a particular option is given to latexmk but isn't handled by the particular implementation of *latex being used, that program will probably give a warning or an error.) These options are very numerous, but they aren't listed in this documentation because they have no direct effect on latexmk's actions.

There are a few options (e.g., -includedirectory=dir, -initialize, -ini) that are not recognized, either because they don't fit with latexmk's intended operations, or because they need special processing by latexmk that isn't implemented (at least, not yet). 🙈

There are certain options for *latex (e.g., -recorder) that trigger special actions or behavior by latexmk itself. Depending on the action, they may also be passed in some form to the called *latex program, and/or may affect other programs as well. These options do have entries in this documentation. Among these options are: -jobname=STRING, -aux-directory=dir, -output-directory=DIR, -quiet, and -recorder. 💖

There are also options that are accepted by *latex, but instead trigger actions purely by latexmk: -help, -version.

Notes that may help when debugging problems: the method latexmk uses to pass any of the accepted extra options to *latex is that when it constructs the command line for running *latex, it inserts the options where the placeholder %O appears in the strings specifying the command line. (I.e., in the strings given by the configuration variables $pdflatex etc.) Note that latexmk uses this same method to add other options to the command line, and that the strings in $pdflatex etc may contain other options. So depending on the situation and the configuration, using an extra option on the latexmk command line might not achieve the desired effect; e.g., it could be overridden by a later option in the command line. 💀

---

• -silent — run all the commands in quiet mode, aka with options that cut down on the diagnostics spam. With default settings, for example, latex gets run as latex -interaction=batchmode, and its little friends get treated the same way. 💅

Also check out -logfilewarninglist and -logfilewarninglist-options, they're the girlies for this.

This also turns down how many informational messages latexmk itself yells at you.

If you wanna change the options used to make commands go silent, you have to configure latexmk with different values of its config variables, and the relevant ones are $bibtex_silent_switch, $biber_silent_switch, $dvipdf_silent_switch, $dvips_silent_switch, $dvilualatex_silent_switch, $latex_silent_switch, $lualatex_silent_switch $makeindex_silent_switch, $pdflatex_silent_switch, and $xelatex_silent_switch.

• -stdtexcmds — sets up the commands for latex and friends so they're the standard ones. Super handy for overriding special configurations you've got going on. ✨

The outcome is that $latex = 'latex %O %S', and same energy for $pdflatex, $lualatex, and $xelatex. (The -no-pdf option that $xelatex needs gets provided automatically, since %O shows up in the definition.)

• -time — show the time used. (On MS Windows what you get is clock time; on other systems it's CPU time.) Peep the config variable $show_time too.
• -time- — do NOT show the time used. Same config variable $show_time, bestie.
• -use-make — so after a run of *latex, if there are warnings about missing files (like when the LaTeX \input, \include, and \includgraphics commands ask for something), latexmk tries to make them by a custom dependency. But if no relevant custom dependency with a fitting source file turns up, and -use-make is on, then as a last resort latexmk will straight up try to use the make program to make those missing files. 🛠️

Note that the filename might be given without an extension, like \includegraphics{drawing} in a LaTeX file. In that case, latexmk will try making drawing.ext with ext set in turn to each of the possible extensions that matter for latex (or as appropriate for pdflatex, lualatex, xelatex).

Go read the docs for the $use_make_for_missing_files config variable too.

• -use-make- — do not use the make program to try to make missing files. (This is the default.)
• -usepretex — sets the command lines for latex and friends so they use the code defined by the variable $pre_tex_code, or the code set by the option -pretex=CODE, to execute that specified TeX code before the source file gets read. This option overrides any previous definition of the command lines. 🔥

The result is $latex = 'latex %O %P', and same for $pdflatex, $lualatex, and $xelatex. (Again, the -no-pdf option that $xelatex needs is provided automatically, given that %O appears in the definition.)

• -usepretex=CODE — exactly the same as -pretex=CODE -usepretex. Example:

latexmk -usepretex='\AtBeginDocument{Message\par}' foo.tex

• -v or -version — print the version number of latexmk. 💅
• -verbose — the opposite of -silent. This is the default setting, bestie, so this is the vibe you're already living in.
• -view=default, -view=dvi, -view=hnt, -view=ps, -view=pdf, -view=none — pick which kind of file gets used when previewing is requested (like by the -pv or -pvc switches). The default is to view the "highest" kind of requested file, going low-to-high as .dvi, .hnt, .ps, .pdf.

Note that -view=none is a whole possibility where no viewer opens at all. One example of using it is together with the -pvc option, when you want latexmk to recompile automatically whenever source file(s) change, but you do NOT want a previewer popping up. 🙈

• -Werror — this makes latexmk return a non-zero status code if any of the files it processes throws a warning about problems with citations or references (like undefined citations or references, or multiply defined references). This happens after latexmk has finished all the runs it needs to try and resolve references and citations. So -Werror makes latexmk treat those warnings as errors, but only when they show up on the last run of *latex and only after processing is complete. You can also set this with the config variable $warnings_as_errors.
• -xdv — generate an xdv version of the document using xelatex. (And turn off any incompatible requests.)
• -xelatex — use xelatex. As in, use xelatex to process the source file(s). This causes generation of a pdf (but indirectly, through an xdv file). (And turn off any incompatible requests.)

This option is equivalent to using this option:

-pdfxe

[Note: note that the method of implementation of this option — though not its intended primary effect — differs from some earlier versions of latexmk. Latexmk first uses xelatex to make an .xdv file, and does all the extra runs needed (including those of bibtex, etc). Only after that does it make the pdf file from the .xdv file, using xdvipdfmx. See the documentation for -pdfxe for why this is done.]

• -xelatex="COMMAND" — this sets the string specifying the command to run xelatex. It sets the variable $xelatex.

Warning: it is important to make sure that -no-pdf is used when xelatex is invoked, because latexmk expects xelatex to produce an .xdv file, not a .pdf file. If you provide %O in the command specification, this gets done automatically. See the docs for the -pdfxe option for why latexmk makes an .xdv file rather than a .pdf file when xelatex is used.

An example of using the -xelatex option:

latexmk -pdfxe -xelatex="xelatex --shell-escape %O %S" foo.tex

Note: this option, when given the COMMAND argument, only sets the command for invoking xelatex; it does not turn on the use of lualatex. That's done by other options or in an initialization file.

🎀 Compatibility between options 🎀

The preview-continuous option -pvc can only work with one file. So in this case you'll normally only specify one filename on the command line.

Options -p, -pv and -pvc are mutually exclusive. So each one of these options turns the others off. Periodt. 💅

---

✨ EXAMPLES ✨

% latexmk thesis    # run latex enough times to resolve
                    cross-references

% latexmk -pvc -ps thesis# run latex enough times to resolve
                    cross-references, make a postscript
                    file, start a previewer.  Then
                    watch for changes in the source
                    file thesis.tex and any files it
                    uses.  After any changes rerun latex
                    the appropriate number of times and
                    remake the postscript file.  If latex
                    encounters an error, latexmk will
                    keep running, watching for
                    source file changes.

% latexmk -c        # remove .aux, .log, .bbl, .blg, .dvi,
                    .pdf, .ps & .bbl files

---

💀 DEALING WITH ERRORS, PROBLEMS, ETC 💀

Some possibilities, bestie:

a. If you get a strange error, look carefully at the output on your screen and in the log files. Yeah there's a lot that's famously verbose in latex output (and latexmk adds to it), but the verbosity is there for a reason: so you can diagnose problems. Latexmk does repeat some messages at the end of a run that it thinks you'd otherwise miss in the middle of all the other output. 👑

b. Generally, remember that latexmk does its work by running other programs. Your first priority when dealing with errors should be to look at what went wrong with the individual programs. Then you fix the causes of the errors in the runs of those programs. (Often they come from errors in the source document, but they could also be about missing LaTeX packages, etc.)

c. If latexmk doesn't run the programs the way you'd like, then you gotta look in this documentation at the list of command line options and then at the sections on configuration/initialization files. A lot of latexmk's behavior is configurable for particular situations. (But yeah, there is a LOT of reading. 😭)

The rest of these notes is ideas for dealing with the harder situations.

d. Further tricks can involve replacing the standard commands that latexmk runs with other commands or scripts.

e. For possible examples of code to use in an RC file, see the directory example_rcfiles in the distribution of latexmk (e.g., at http://mirror.ctan.org/support/latexmk/example_rcfiles). Even if these examples don't do what you want, they might give you suitable inspiration. ✨

f. There's a useful trick you can use when you're using lualatex instead of pdflatex (and in some related situations). The problem: latexmk won't notice a dependency on a file, bar.baz say, that gets input by the lua code in your document instead of by the LaTeX part. (So if you change bar.baz and rerun latexmk, latexmk will think no files have changed and won't rerun lualatex — whereas if you had '\input{bar.baz}' in the LaTeX part of the document, latexmk would notice the change.) One solution is just to put this somewhere in the LaTeX part of the document:

\typeout{(bar.baz)}

This puts a line in the log file that latexmk will treat as implying that the file bar.baz was read. (At present the author doesn't know a way of doing this automatically.) Of course, if the file has a different name, change bar.baz to the name of your file.

g. Also see the section "Advanced Configuration: Some extra resources".

h. Look on tex.stackexchange, i.e., at http://tex.stackexchange.com/questions/tagged/latexmk — someone may have already solved your problem. 🫶

i. Ask a question at tex.stackexchange.com.

j. Or ask the author of latexmk directly. The e-mail is at the end of this documentation. 💖

💖 AUXILIARY AND OUTPUT DIRECTORIES 💖

okay bestie, so here's the tea ☕ — when you run latex and all its little helper programs, they're gonna spit out a *whole bunch of files. and sometimes it's just so much nicer to have all those generated files living somewhere that isn't the same directory as your actual source files. so let's talk about it.

for our purposes, we're gonna sort these generated files into two whole classes. periodt.

the first class? that's what we call the final output files. think: the .pdf you get from running pdflatex, or the .dvi from latex. also in this club is the ps file you get when you apply dvips to a .dvi file. oh and don't forget the .synctec or .synctex.gz files — those lil guys are used by programs that display .pdf files and the like, to relate positions in them to positions in your source files. iconic. 💅

the second class is literally everything else that gets generated. notably this includes .aux files — they're used for implementing cross referencing, and they get generated on one run and read on a later run. so many packages generate yet more intermediate files like these, plus programs like bibtex, makeindex, etc. and yes there's also the .log files from *latex and corresponding files from other programs. a whole ecosystem fr fr. 🌸

so let's get our vocabulary right, bestie:

• "output directory" = the directory that receives the final output files 👑
• "aux directory" = the directory for all those other generated files 🎀

if you don't hand the *latex programs any special options, both of these directories just default to the current directory — which means nothing gets segregated, everything's just vibing together. and if the two directories are the same (which is literally the simplest situation), then all generated files get written to the same directory, and people will often just say "output directory" without even mentioning a separate aux directory. nbd.

support for all this lives inside the latex programs themselves: there's a single option -output-directory for the TeXLive implementations, and there's -aux-directory *and -output-directory for the MiKTeX implementations.

so why do these programs need special support like this? two reasons, bestie:

1. there are so many packages that write files, and it needs to be arranged that these get automatically written to the appropriate directory — without any rewriting of the packages' code. we're not out here editing everybody's stuff.
2. the files are often read in again on subsequent runs of *latex, so the program needs to know where to find them. obviously.

---

the emulation saga 🫶

here's where it gets a lil complicated. the TeXLive implementation does not allow for separate aux and output directories. 💀

latexmk deals with this by being able to emulate a separate aux directory. how? it invokes latex with just an -output-directory option — but sets that directory not to the desired output directory, but to the *aux directory. then, after running *latex, it moves the relevant final output file(s) to the intended output directory. slay. ✨

you can turn emulation on by setting the configuration variable $emulate_aux to one in a configuration file, or by using latexmk's -emulate-aux-dir option. and plot twist: the emulation method works equally well if MiKTeX is used. 🌈

latexmk will also turn emulation on if it finds out it's needed. here's how that goes down:

suppose emulation is initially off, but the aux and output directories are different. then latexmk invokes latex with an -aux-directory option — and after the run, it finds that this option hasn't been obeyed, notably because the .log file is sitting in the output directory instead of the aux directory. 😭 latexmk then sets emulation on, and retries. conceivably, it *could move all the appropriate generated files from the output directory to the aux directory — but there's such a large variety of possibilities for these files that it's hard to identify all of them reliably, except for simple cases. so, retry it is.

note: this whole emulation issue only arises when the user has arranged for the aux and output directories to be different. if instead they're equal — e.g., because the user only set the $out_dir variable — then latexmk invokes *latex with only an -output-directory option, which works as intended with both TeXLive and MiKTeX. no drama. 💜

on top of all that, latexmk arranges the invocations of any auxiliary programs like bibtex and makeindex so that they'll read and write the relevant files from and to the aux directory. and programs like dvips, dvipdf, ps2pdf, and xdvipdfmx are invoked so that they read from the appropriate places and write their output to the output directory. everyone knows their assignment. 🎀

---

which files count as final output? 👑

files considered final output files — i.e., the ones that belong in the output directory rather than the aux directory — have these extensions:

• .dvi
• .ps.
• .pdf
• .synctex
• .synctex.gz

there's also one special case, because of compatibility issues: .fls files. (see below, bestie, we get to it. 🦋)

now, a lil nuance about .xdv: when xelatex is invoked with its -no-pdf option — which latexmk does — it generates an .xdv file, which would appear to have the same status as a .dvi file generated by latex. nevertheless, latexmk treats .xdv as an intermediate file that's found in the aux directory. why? to match MiKTeX's treatment of the -aux-directory option. and as further justification, one can say that under modern conditions an .xdv file is (almost) always an intermediate file. historically, the situation with .dvi files from latex was different — and currently dvi previewers do exist. so there's that. 💅

---

variables and options for directories

okay so the variables for setting the aux and output directories are $aux_dir and $out_dir, with corresponding command line options -auxdir (or -aux-directory) and -outdir (or -output-directory).

when a value for these is blank (which is the default value, btw), it implies the use of a default:

• for the aux directory, the default is to set it equal to the output directory.
• for the output directory, the default is to be the current directory.

and for turning the emulation mode on and off, you've got the configuration variable $emulate_aux and the options -emulate-aux-dir, -emulate-aux-dir-, and -noemulate-aux-dir.

---

interaction with the -cd option 🧚

when the -cd option is used (or the equivalent setting of the $do_cd variable), then latexmk changes the working directory to the document directory before invoking *latex.

here's the important bit: if the aux and/or output directories are given by relative paths — e.g., by -outdir=output for a directory named "output" — then the directories are relative to the document directory, rather than relative to the working directory that was in effect when latexmk was invoked. this matches the behavior of *latex as invoked with the provided command line directory argument(s) after the change of working directory to the document directory. consistency is key, bestie. ✨

---

automatic creation of aux and output directories

plot twist that's actually a good one: unlike *latex, if latexmk finds the requested directory/ies don't exist, it creates it/them — thereby avoiding errors when *latex is invoked. no cap, it's just out here making folders for you. 🫶

and one more scenario: if the document uses the \include macro to read a .tex file from a subdirectory, *latex will attempt to write an extra aux file to the corresponding subdirectory of the aux directory. if that subdirectory doesn't exist, then *latex will complain that it can't write the aux file. 😭 but after the run of *latex, latexmk detects this situation, creates the necessary directory, and reruns *latex with the error situation corrected. problem solved, we move. 💅

---

choice of aux and output directories 🌸

often the aux and output directories are given as subdirectories of the document directory, e.g., by -outdir=output. but it's possible to provide, for example, an absolute path or a path relative to a parent directory — e.g., "/tmp/foo" or "../output".

⚠️ be aware that in general this can cause problems, notably with makeindex or bibtex.

why? because modern versions of these programs, by default, will refuse to work when they find they're being asked to write to a file in a directory that appears not to be the current working directory or one of its subdirectories. this is part of the security measures by the whole TeX system that try to prevent malicious or errant TeX documents from incorrectly messing with a user's files. they're just being protective, honestly. 🔥

by default, latexmk evades this issue: before running bibtex and makeindex, latexmk changes the working directory to the aux directory, with appropriate settings of search paths. the use or non-use of this trick is governed by the variables $bibtex_fudge and $makeindex_fudge. unfortunately, the trick sometimes makes bibtex and makeindex unable to find files. 😭 we love a tradeoff.

if necessary, the trick can be turned off. but this is incompatible with an aux directory like "/tmp/foo" or "../output". if you really have to deal with this situation — and only if you have to deal with it — then you need to disable the security measures (and assume any risks). one way of doing this is to temporarily set an operating system environment variable openout_any to "a" (as in "all"), to override the default "paranoid" setting. 👑

---

certain names of aux and output directories not allowed on Microsoft Windows 💀

so it's totally natural to want to use the name "aux" for the aux directory, e.g., by using the option -auxdir=aux. but on Microsoft operating systems, "aux" is one of the names that is not allowed for a file or directory. rip. 🙈

i find it useful to standardize on a name like "auxdir" (e.g., by -auxdir=auxdir); this works independently of operating system. cross-platform queen behavior. 💅

---

location of the .fls file 🌈

much of the dependency information that latexmk uses comes from the .fls file generated when *latex is invoked with the -recorder option — which latexmk does by default, btw.

it may seem rational that this gets written to the aux directory. but in fact, versions of MiKTeX prior to Oct. 2020 wrote it to the output directory. later versions do write it to the aux directory. messy. so to deal with this, latexmk does two things:

1. first, if latexmk finds that the .fls file has only been generated in the "wrong" directory, then latexmk copies it to the expected directory, after which latexmk's operation continues correctly — independently of the behavior of *latex. 😌
2. second, it allows its idea of the "correct" (or expected) directory to be configured by the variable $fls_uses_aux_dir. this defaults to zero, to correspond to MiKTeX's current behavior.

and that's the whole .fls situation, bestie. 🦋

🌈 ALLOWING FOR CHANGE OF OUTPUT FILE TYPE 🌈

okay so bestie, when one of the latex engines runs, the usual vibe is that latex produces a .dvi file, while pdflatex and lualatex produce a .pdf file. For xelatex the default is to produce a .pdf file, BUT to optimize processing time latexmk runs xelatex with its -no-pdf option so it produces an .xdv file instead. Then latexmk's further processing takes that as a starting point. ✨

But plot twist: the actual output file may differ from the normal expectation, and latexmk can adjust its processing to accommodate that situation. This difference in output file type can happen for two reasons. One is that for latex, pdflatex, and lualatex the document itself can override the defaults. The other is that there may be a configuration (or a misconfiguration) such that the program latexmk invokes to compile the document isn't the expected one, or gets options incompatible with what latexmk initially expects. 💀

Under latex and pdflatex, control of the output format by the document is done by setting the \pdfoutput macro. Under lualatex, the \outputmode macro is used instead. 👑

One example of an important use-case for document control of the output format is a document that uses the psfrag package to insert graphical elements in the output file. The psfrag package achieves its effects by inserting postscript code in the output of the compilation of the document. This entails compiling to a .dvi file, followed by conversion to a postscript file (either directly, as by dvips, or implicitly, as an intermediate step by dvipdf). Then it's useful to force output to be of the .dvi format by inserting \pdfoutput=0 in the preamble of the document. 💅

Another example is where the document uses graphics files of the .pdf, .jpg, and png types. With the default setting for the graphicx package, these can be processed in compilation to .pdf but not with compilation to .dvi. In this case, it's useful to insert \pdfoutput=1 in the preamble of the document to force compilation to .pdf output format. 🎀

In all of these cases, it's needed that latexmk adjust its processing to deal with a mismatch between the actual output format (out of .pdf, .dvi, .xdv) and the initially expected output, if possible. Latexmk does this provided the following conditions are met.

The first is that latexmk's $allow_switch configuration variable is set to a non-zero value, as it is by default. If this variable is zero, a mismatch of filetypes in the compilation results in an error. 🚨

The second condition for latexmk to be able to handle a change of output type is that no explicit requests for .dvi or .ps output files are made. Explicit requests are by the -dvi and -ps, -print=dvi, -print=ps, -view=dvi, and -view=ps options, and by corresponding settings of the $dvi_mode, $postscript_mode, $print_type, and $view configuration variables. The print-type and view-type restrictions only apply when printing and viewing are explicitly requested, respectively. For this purpose, the use of the -pdfdvi and -pdfps options (and the corresponding setting of the $pdf_mode variable) does not count as an explicit request for the .dvi and .ps files; they are merely regarded as a request for making a .pdf file together with an initial proposal for the processing route to make it. 🦋

Note bestie: when accommodating a change in output file type, there's a substantial change involved in the network of rules that latexmk uses in its actions. The second condition applied to accommodate a change is to avoid situations where the change in the rule network is too radical to be readily handled automatically.

---

🌸 CONFIGURATION/INITIALIZATION (RC) FILES 🌸

This section explains which configuration files are read by latexmk. The subsequent sections "How to Set Variables in Initialization Files", "Format of Command Specifications", "List of Configuration Variables Usable in Initialization Files", "Custom Dependencies", and "Advanced Configuration" give all the deets on what can be configured and how. 💖

Latexmk can be customized using initialization files, which are read at startup in the following order:

1. The system RC file, if it exists. On a UNIX system, latexmk searches the following directories for a system RC file, which may be named either LatexMk or latexmkrc. The directories are searched in the following order, and latexmk uses the first such file it finds (if any):
   • /etc
   • /opt/local/share/latexmk
   • /usr/local/share/latexmk
   • /usr/local/lib/latexmk

On a MS-Windows system it looks just in C:\latexmk.

On a cygwin system (i.e., a MS-Windows system in which Perl is that of cygwin), latexmk looks in the directories:

• /cygdrive/c/latexmk
• /etc
• /opt/local/share/latexmk
• /usr/local/share/latexmk
• /usr/local/lib/latexmk

If the environment variable LATEXMKRCSYS is set, its value is used as the name of the system RC file, instead of any of the above. 👑

2. The user's RC file, if it exists. This can be in one of two places. The traditional one is .latexmkrc in the user's home directory. The other possibility is latexmk/latexmkrc in the user's XDG configuration home directory. The actual file read is the first of $XDG_CONFIG_HOME/latexmk/latexmkrc or $HOME/.latexmkrc which exists. (See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html for details on the XDG Base Directory Specification.)

Here $HOME is the user's home directory. [Latexmk determines the user's home directory as follows: it's the value of the environment variable HOME, if this variable exists, which normally is the case on UNIX-like systems (including Linux and macOS). Otherwise the environment variable USERPROFILE is used, if it exists, which normally is the case on MS-Windows systems. Otherwise a blank string is used instead of $HOME, in which case latexmk does not look for an RC file in it.]

$XDG_CONFIG_HOME is the value of the environment variable XDG_CONFIG_HOME if it exists. If this environment variable does not exist, but $HOME is non-blank, then $XDG_CONFIG_HOME is set to the default value of $HOME/.config. Otherwise $XDG_CONFIG_HOME is blank, and latexmk does not look for an RC file under it. 🫶

3. The RC file in the current working directory. This file can be named either latexmkrc or .latexmkrc, and the first of these to be found is used, if any.
4. Any RC file(s) specified on the command line with the -r option.

Each RC file is a sequence of Perl commands. Naturally, a user can use this in creative ways. But for most purposes, one simply uses a sequence of assignment statements that override some of the built-in settings of Latexmk. Straightforward cases can be handled without knowledge of the Perl language by using the examples in this document as templates. Comment lines are introduced by the # character. ✨

Note bestie: command line options are obeyed in the order in which they are written. So any RC file specified on the command line with the -r option can override previous options, but can itself be overridden by later options on the command line. There's also the -e option, which allows initialization code to be specified in latexmk's command line. 😭

For possible examples of code for an RC file, see the directory example_rcfiles in the distribution of latexmk (e.g., at http://mirror.ctan.org/support/latexmk/example_rcfiles). 💜

---

🦋 HOW TO SET VARIABLES IN INITIALIZATION FILES 🦋

The important variables that can be configured are described in the section "List of configuration variables usable in initialization files". (See the earlier section "Configuration/Initialization (rc) Files" for the files where the configurations are done.) The syntax for setting these variables is of the following forms:

$bibtex = 'bibtex %O %S';

for the setting of a string variable,

$preview_mode = 1;

for the setting of a numeric variable, and

@default_files = ('paper', 'paper1');

for the setting of an array of strings. It's possible to append an item to an array variable as follows:

push @default_files, 'paper2';

Note that simple "scalar" variables have names that begin with a $ character, and array variables have names that begin with a @ character. Each statement ends with a semicolon. 💅

Strings should be enclosed in single quotes. (You could use double quotes, as in many programming languages. But then the Perl programming language brings into play some special rules for interpolating variables into strings. People not fluent in Perl will want to avoid these complications.) 🎀

You can do much more complicated things, but for this you'll need to consult a manual for the Perl programming language. 🔥

---

✨ FORMAT OF COMMAND SPECIFICATIONS ✨

Okay bestie, so some of these variables are the ones that literally tell latexmk which command to run for each lil task it does — like turning a .tex file into a .dvi, or opening a postscript file in a viewer. 💅 This section spills all the tea on how you actually write those commands.

Heads up: a few of the things listed down here do not apply to the $kpsewhich variable — go read its own docs for the deets. 🫶

---

🎀 Placeholders 🎀

So imagine you're like "bestie I want latexmk to use elatex instead of the regular latex command," and also you wanna hand it the option --shell-escape. Easy. You'd write:

$latex = 'elatex --shell-escape %O %S';

See those two lil items starting with the % character? Those are placeholders, and they get swapped out for the right values before the command actually runs. 🌟 So %S gets replaced by the source file that elatex is being applied to, and %O gets replaced by whatever options latexmk decided to use for that command. (Like — if you threw -silent into your latexmk invocation, that makes %O turn into -interaction=batchmode.)

Here's every placeholder you can use, no gatekeeping:

• %A — the basename of the main tex file. Unlike %R, this one is not affected by a jobname set via the -jobname option or the $jobname configuration value. 💖
• %B — the base of the filename for the current command. For example, if a postscript file document.ps is being made from the dvi file document.dvi, then the basename is document.
• %D — the destination file (like, the name of the postscript file when you're converting a dvi file to postscript).
• %O — options.
• %P — if the variable $pre_tex_code is non-empty, then %P gets substituted by the contents of $pre_tex_code followed by \input{SOURCE}, where SOURCE stands for the name of the source file. Appropriate quoting is done for you. This is what lets TeX code be passed to one of the *latex engines so it runs before the source file is read. And if $pre_tex_code is the empty string? Then %P is just equivalent to %S. ✨
• %R — the root filename. By default it's the basename of the main tex file. But the value can change if you use the -jobname option or the $jobname configuration variable. When that happens, this becomes the basename for files like the .aux and .log files produced by running *latex, as well as for the main .dvi, .pdf, .ps and/or .xdvi files. 👑
• %S — the source file (e.g., the name of the dvi file when converting a .dvi file to ps).
• %T — the name of the primary tex file.
• %U — if the variable $pre_tex_code is non-empty, then its value is substituted for %U (appropriately quoted, ofc). Otherwise it gets replaced by a null string.
• %Y — the name of the directory for auxiliary output files (peep the configuration variable $aux_dir). A directory separation character (/) is appended if $aux_dir is non-empty and doesn't end in a suitable character — and "suitable" here means the ones appropriate to UNIX and MS-Windows, i.e., :, / and \. Note that if after initialization $out_dir is set but $aux_dir is not set (i.e., it's blank), then latexmk sets $aux_dir to the same value as $out_dir. 🌸
• %Z — the name of the directory for output files (see the configuration variable $out_dir). A directory separation character (/) is appended if $out_dir is non-empty and doesn't end in a suitable character, with suitable characters again being the ones appropriate to UNIX and MS-Windows, i.e., :, / and \.

If for some reason you need a literal % character in your string that is not subject to all these rules, just write "%%". 🎀

Appropriate quoting gets applied to the filename substitutions, so you mustn't supply it yourself even if your filenames have spaces in them. (But if your TeX filenames have spaces in them — beware, because some older versions of the TeX program can't correctly handle filenames with spaces. 😭) And in case latexmk's quoting doesn't work right on your system, you can turn it off — go read the documentation for the variable $quote_filenames.

Wanna know what's normally the most appropriate usage? Check the default values over in the section "List of configuration variables usable in initialization files". ⭐

And if you just... don't supply any placeholders at all in the specification of a command? latexmk will supply what its author thinks are appropriate defaults. This gives compatibility with configuration files for previous versions of latexmk, which didn't use placeholders. 💜

---

💀 "Detaching" a command 💀

Normally when latexmk runs a command, it waits for that command to run to completion. Which is totally the right call for commands like latex, obviously. But for previewers? Nah — the command should normally run detached, so latexmk gets the previewer running and then goes back to its next task (or exits if there's nothing else to do). 🌈

To get that detaching effect, you need to precede the command name with "start ", like this:

$dvi_previewer = 'start xdvi %O %S';

This will be translated to whatever is appropriate for your operating system. 🦋

Notes, bestie, and you know I'm listing all of them:

1. In some circumstances, latexmk will always run a command detached. This is the case for a previewer in preview continuous mode — since otherwise, previewing continuously makes no sense. 🙈
2. This precludes the possibility of running a command named start.
3. If the word start occurs more than once at the beginning of the command string, that's equivalent to having just one.
4. Under cygwin, some complications happen, since cygwin amounts to a complicated merging of UNIX and MS-Windows. See the source code for how I've handled the problem.

---

🌟 Command names containing spaces 🌟

Under MS-Windows it's super common for a command name to include spaces, since software is often installed in a subdirectory of "C:\Program Files". Such command names should be enclosed in double quotes, like so:

$lpr_pdf = '"c:/Program Files/Ghostgum/gsview/gsview32.exe" /p %S';
$pdf_previewer = 'start "c:/Program Files/SumatraPDF/SumatraPDF.exe" %O %S';
$pdf_previewer = 'start "c:/Program Files/SumatraPDF (x86)/SumatraPDF.exe" %O %S';

Note about the above example: under MS-Windows, forward slashes are equivalent to backslashes in a filename under almost all circumstances — provided the filename is inside double quotes. It's easier to use forward slashes in examples like the one above, since then you don't have to worry about the rules for dealing with forward slashes in strings in the Perl language. 🫶

💅 Command names under Cygwin 💅

If latexmk is executed by Cygwin's Perl, be particularly certain that pathnames in commands have forward slashes and not the usual backslashes for the separator of pathname components. See the examples above. Backslashes often get misinterpreted by the Unix shell that Cygwin's Perl uses to execute external commands. Forward slashes don't suffer from this problem, and (when quoted, as above) are equally acceptable to MS-Windows. ✨

🔥 Using MS-Windows file associations 🔥

A useful trick under modern versions of MS-Windows (e.g., WinXP) is to use just the command 'start' all by itself:

$dvi_previewer = 'start %S';

Under MS-Windows, this will cause whatever program the system has associated with dvi files to be run. (The same applies for a postscript viewer and a pdf viewer.) But note that this trick is not always suitable for the pdf previewer, if your system has acroread as the default pdf viewer. As explained elsewhere, acroread under MS-Windows does not work well with latex and latexmk, because acroread locks the pdf file. 😭

🎀 Not using a certain command 🎀

If a command is not to be run, the command name NONE is used, like this:

$lpr  = 'NONE lpr';

This is typically used when an appropriate command doesn't exist on your system. And the string after the "NONE" is effectively a comment. 💖

👑 Options to commands 👑

Setting the name of a command can be used not only to change the name of the command called, but also to add options to it. Suppose you want latexmk to use latex with source specials enabled — then you might use the following line in an initialization file:

$latex = 'latex --src-specials %O %S';

🧚 Running a subroutine instead of an external command 🧚

Use a specification starting with "internal", like:

$latex = 'internal mylatex %O %S';
sub mylatex {
    my @args = @_;
    # Possible preprocessing here
    return system 'latex', @args;
}

For some of the more exotic possibilities that then become available, check out the section "Advanced configuration: Some extra resources and advanced tricks". Also peep some of the examples in the directory example_rcfiles in the latexmk distribution. 🌸

🌈 Advanced tricks 🌈

Normally you specify a single command for the commands that latexmk invokes. And naturally, if there's some complicated additional processing you need to do in your special situation, you can write a script (or batch file) to do the processing, and then configure latexmk to use your script in place of the standard program. 💜

You can also use a Perl subroutine instead of a script — see above. This is generally the most flexible and portable solution. ⭐

It's also possible to configure latexmk to run multiple commands. For example, if when running pdflatex to generate a pdf file from a tex file you need to run another program after pdflatex to do some extra processing, you could do something like:

$pdflatex = 'pdflatex --shell-escape %O %S; pst2pdf_for_latexmk %B';

This definition assumes you're using a UNIX-like system (which includes Linux and macOS), so that the two commands to be run are separated by the semicolon in the middle of the string. 🦋

And if you're using MS-Windows, you'd replace the above line with:

$pdflatex = 'cmd /c pdflatex --shell-escape %O %S'
            . '&& pst2pdf_for_latexmk %B';

Here, the UNIX command separator ; is replaced by &&. In addition, there's a problem that some versions of Perl on MS-Windows don't obey the command separator; this problem is overcome by explicitly invoking the MS-Windows command-line processor cmd.exe. 💅

---

✨ LIST OF CONFIGURATION VARIABLES USABLE IN INITIALIZATION FILES ✨

In this section are specified the variables whose values you can adjust to configure latexmk. 🎀

(See the earlier section "Configuration/Initialization (rc) Files" for the files where the configurations are done.)

Quick heads-up bestie: the default value for each variable is chillin' in brackets right next to its name. And for the boolean-ish ones — the ones that are basically "does latexmk do the thing or not" — a non-zero value (usually 1) means true, aka yes the behavior happens, and a zero value means false, aka nope, no behavior today. Periodt.

---

🎀 $allow_subdir_creation [1]

This one is all about what to do when the .log file starts complaining that a *latex compilation tried to write a file into a subdirectory of the output directory and couldn't, because the subdirectory literally did not exist.

• If $allow_subdir_creation is 0 — no action taken, we simply do not.
• If it's 1 — the right subdirectory gets created and a rerun of *latex is triggered, but only if the file being written is an .aux file. (This exact thing happens, for example, when the document pulls in a file from a subdirectory of the document directory via the \include command.)
• If it's 2 — the subdirectory gets created no matter what type of file is in question.

✨ $allow_switch [1]

This controls what goes down when the output extension of latex, pdflatex, lualatex or xelatex is not what was expected. (The possible extensions in play are .dvi, .pdf, .xdv.) This can happen because of the \pdfoutput macro in a document compiled under latex or pdflatex, or because of the \outputmode macro under lualatex. It can also happen from certain kinds of incorrect configuration. 🙈

When it does happen, latexmk can adjust its network of rules to fit. That adjustment gets made if $allow_switch is on, and if nobody has asked for a dvi or ps file.

See the section ALLOWING FOR CHANGE OF OUTPUT EXTENSION.

🦋 $always_view_file_via_temporary [0]

Whether .ps and .pdf files are initially made in a temporary directory and then moved to their final location. (This applies to dvips, dvipdf, and ps2pdf operations, plus the filtering operators on .dvi and .ps files. It does not apply to pdflatex, unfortunately, because pdflatex gives you no way to specify a chosen name for the output file. 😭)

Why bother with a temp file? Because making these files can eat up a substantial amount of time, and if a viewer (notably gv) notices the file has changed, it might read the new file before the program writing it has finished its work — and that can cause havoc.

See $pvc_view_file_via_temporary for a setting that only kicks in when preview-continuous mode (the -pvc option) is used. See $tmpdir for the setting of the directory where the temporary file gets created.

🌸 $analyze_input_log_always [1]

After a run of latex (etc), always analyze the .log for input files in the <...> and (...) constructions. Otherwise, only do that analysis when the fls file doesn't exist or is out of date.

Under normal circumstances the data in the fls file is reliable, and testing the log file racks up lots of false positives; usually $analyze_input_log_always is best set to zero. But the log-file test is needed at least in this situation: when a user needs to persuade latexmk that a certain file is a source file, and latexmk just doesn't find it otherwise. Then the user can write code that causes a line with (...) to be written to the log file. One important case is lualatex, which doesn't always generate lines in the .fls file for input lua files. (And the situation with lualatex is HIGHLY version dependent — there was a big change between TeXLive 2016 and TeXLive 2017, iykyk.)

To keep backward compatibility with older versions of latexmk, the default is to set $analyze_input_log_always to 1.

💜 $auto_rc_use [1]

Whether to automatically read the standard initialization (rc) files — that's the system RC file, the user's RC file, and the RC file in the current directory. The command line option -norc can be used to turn this setting off. Each RC file could also turn this setting off itself, i.e. it could set $auto_rc_use to zero to prevent automatic reading of the later RC files.

Heads up: this variable does not affect the reading of RC files specified on the command line by the -r option.

🫶 $aux_dir [""]

The aux directory, i.e. the directory where auxiliary files (aux, log, etc) get written by a run of *latex.

• If this variable isn't set, but $out_dir is set, then latexmk takes the aux directory to equal the output directory — which is the directory where final output files get written.
• If neither variable is set, then the current directory when *latex is invoked is used for both the aux and output directories.
• If the aux and output directories are distinct, then the aux directory holds all generated files except for "final output files", which are defined to be .dvi, .ps, .pdf, .synctex, and .synctex.gz files.

See the section AUXILIARY AND OUTPUT DIRECTORIES for more details.

⭐ $aux_out_dir_report [0]

If this is set to 1, then before each primary .tex file gets processed, latexmk lists the settings for the aux and output directories, after they've been normalized from whatever you specified during initialization.

This report is basically a lil reminder of where to go look for generated files. 👀

It's done per primary .tex file, because directories can change for each file (that's what happens when the -cd option is used). In the simplest cases the directory names are exactly what you originally specified. But in general some clean up/normalization gets performed — this helps performance and tidies up what you see on screen.

If this variable is set to 2, then latexmk halts after reporting the aux and out directory settings, instead of continuing to process tex files. This setting is mostly for debugging configuration issues. See the -dir-report-only option.

💀 $bad_warning_is_error [0]

Whether to treat bad warnings reported by *latex in the log file as errors. The specs for those warning messages live in @bad_warnings.

🎀 @bad_warnings

An array of regular expressions specifying messages in the log file that *latex officially treats as warnings rather than errors — but which a user might want to treat as errors anyway. See $bad_warning_is_error.

Currently the default set of these warnings is the ones about \end occurring inside constructs.

🌈 $banner [0]

If nonzero, the banner message gets printed across each page when converting the dvi file to postscript. Without modifying the variable $banner_message, this is equivalent to specifying the -d option.

Note: if $banner is nonzero, $postscript_mode is assumed and the postscript file is always generated — even if it's newer than the dvi file.

✨ $banner_intensity [0.95]

Equivalent to the -bi option. It's a decimal number between 0 and 1 that says how dark to print the banner message. 0 is black, 1 is white. The default is just right if your toner cartridge isn't running too low. 🖨️

💖 $banner_message ["DRAFT"]

The banner message printed across each page when converting the dvi file to postscript. Equivalent to the -bm option.

🦋 $banner_scale [220.0]

A decimal number specifying how large the banner message gets printed. You'll need to experiment to get the right scale for your message — rule of thumb, the scale should be about equal to 1100 divided by the number of characters in the message. The default is just right for 5 character messages. Equivalent to the -bs option.

🍓 @BIBINPUTS

This is an array variable, now mostly obsolete, that specifies directories where latexmk should look for .bib files. By default it's set from the BIBINPUTS environment variable of the operating system. If that environment variable isn't set, a single-element list consisting of the current directory is set. The format of the directory names depends on your operating system, obviously. Examples of setting this variable:

@BIBINPUTS = ( ".", "C:\\bibfiles" );
@BIBINPUTS = ( ".", "\\server\bibfiles" );
@BIBINPUTS = ( ".", "C:/bibfiles" );
@BIBINPUTS = ( ".", "//server/bibfiles" );
@BIBINPUTS = ( ".", "/usr/local/texmf/bibtex/bib" );

Note that under MS Windows, either a forward slash "/" or a backward slash "\" can separate pathname components, so the first two and the second two examples are equivalent. Each backward slash should be doubled to avoid running afoul of Perl's rules for writing strings. Generally, it's simplest to always use forward slashes instead of backward slashes.

Important note: this variable is now mostly obsolete in the current version of latexmk, since it now uses a better method of searching for files using the kpsewhich command. But if your system is an unusual one without the kpsewhich command, you may need to set @BIBINPUTS.

👑 $biber ["biber %O %S"]

The biber processing program.

💅 $biber_silent_switch ["--onlylog"]

Switch(es) for the biber processing program when silent mode is on.

🌸 $bibtex ["bibtex %O %S"]

The BibTeX processing program.

🧚 $bibtex_fudge [1]

When using bibtex, whether to change directory to $aux_dir before running bibtex.

The need for this arises like so:

1. With bibtex before about 2019, if the filename given to it contains a path component, there was a bug where bibtex would not find extra aux files — the kind produced by the \include command in TeX.
2. With all moderately recent versions of bibtex, bibtex may refuse to write its bbl and blg files, for security reasons, for certain cases of the path component of the filename given to it.

But also, there are rare cases where the change-directory method prevents bibtex from finding certain bib or bst files. In those cases $bibtex_fudge needs to be set to 0. 😭

• $bibtex_silent_switch ["-terse"] — the switch (or switches, plural, do your thing) that gets handed to the BibTeX processing program when silent mode is switched on. 🤫
• $bibtex_use [1] — this one decides under what conditions we're gonna run bibtex or biber. So here's the tea: when latexmk peeps at the log file and sees that one (or more) bibtex/biber-generated bibliographies are in play, it can run bibtex or biber whenever it looks like the bbl file(s) need regenerating from their source bib database file(s). 🎀

But plot twist — sometimes the bib file(s) just aren't there (think: a document you got from an external archive), while the bbl files are provided. And in that case, running bibtex or biber would straight-up overwrite those precious bbl files with incorrect content. Not the vibe. 😭 So $bibtex_use controls whether that happens, and also controls whether .bbl files get deleted during a cleanup operation.

The possible values of $bibtex_use are:

• 0: never use bibtex or biber; never delete .bbl files in a cleanup.
• 1: only use bibtex or biber if the bib file(s) exist; never delete .bbl files in a cleanup.
• 1.5: only use bibtex or biber if the bib files exist; conditionally delete .bbl files in a cleanup (i.e., delete them only when the bib files all exist).
• 2: run bibtex or biber whenever it appears necessary to update the bbl file(s), without testing for the existence of the bib files; always delete .bbl files in a cleanup.

Note: when biber is the one being used, conditional use of biber can be problematic. 👀 From latexmk's point of view the problem is that, because of how biber works, full knowledge of its source files can only be obtained after running biber. In contrast, for bibtex, full information on which bib files are used is obtained from the .aux file(s) after a run of *latex. But for biber, the corresponding information is somewhat incomplete; this the information obtained in the .bcf file that is generated by the biblatex package during a run of *latex.

• $cleanup_includes_cusdep_generated [0] — if it's nonzero, cleanup also deletes files that are generated by custom dependencies. (And when we say a clean up, bestie, we mean like the one you get from the -C option — custom dependencies here are those listed in the .fdb_latexmk file from a previous run.) 🧹
• $cleanup_includes_generated [0] — if it's nonzero, cleanup also deletes files that are detected in the fls file (or, if that fails, in the log file) as being generated. It will also include files made from these first-generation generated files. 🌈

This operation is somewhat dangerous, and can have unintended consequences, since the files to be deleted are determined from a file created by *latex, which can contain erroneous information. 💀 So yeah, this variable is turned off by default, and then the files to be deleted are restricted to those explicitly specified by patterns configured in the variables clean_ext, clean_full_ext, and @generated_exts. Standard cases (e.g., .log files) appear in latexmk's initial value for the array @generated_exts.

• $cleanup_mode [0] — if nonzero, specifies cleanup mode: 1 for full cleanup, 2 for cleanup except for .dvi, .ps and .pdf files, 3 for cleanup except for dep and aux files. (There's also extra cleaning as specified by the $clean_ext, $clean_full_ext and @generated_exts variables.) ✨

This variable is equivalent to specifying one of the -c or -C options. But there should be no need to set this variable from an RC file.

• $clean_ext [""] — extra extensions of files for latexmk to remove when any of the clean-up options (-c or -C) is selected. The value of this variable is a string containing the extensions separated by spaces. 🧼

It is also possible to specify a more general pattern of file to be deleted, by using the place holder %R, as in commands, and it is also possible to use wildcards. Thus setting

$clean_ext = "out %R-blx.bib %R-figures*.log pythontex-files-%R/*";

in an initialization file will imply that when a clean-up operation is specified, not only is the standard set of files deleted, but also files of the form FOO.out, FOO-blx.bib, FOO-figures*.log, and pythontex-files-FOO/*, where FOO stands for the basename of the file being processed (as in FOO.tex).

Most of the files to be deleted are relative to the directory specified by $aux_dir. Note that if $out_dir but not $aux_dir is set, then in its initialization, latexmk sets $aux_dir equal to $out_dir. A normal situation is therefore that $aux_dir equals $out_dir, which is the only case directly supported by TeXLive, unlike MiKTeX. Note that even with TeXLive latexmk does now support different values for the directories — see the explanation of the $emulate_aux variable. 🫶

If $out_dir and $aux_dir different, latexmk actually deletes any files of the specified names in both $aux_dir and $out_dir; this is because under certain error conditions, the files may be put in $out_dir instead of $aux_dir. This also handles the case of deleting any fls file, since that file is in $out_dir.

The filenames specified for a clean-up operation can refer not only to regular files but also to directories. Directories are only deleted if they are empty. An example of an application is to pythontex, which creates files in a particular directory. You can arrange to remove both the files and the directory by setting

$clean_ext = "pythontex-files-%R/* pythontex-files-%R";

See also the (array) variable @generated_exts. In the past, this variable had certain uses beyond that of $clean_ext. But now, they accomplish the same things. In fact, after initialization including the processing of command line options, latexmk simply appends the list of extensions in $clean_ext to the array @generated_exts.

• $clean_full_ext [""] — extra extensions of files for latexmk to remove when the -C option is selected, i.e., extensions of files to remove when the .dvi, etc. files are to be cleaned-up. 💅

More general patterns are allowed, as for $clean_ext.

The files specified by $clean_full_ext to be deleted are relative to the directory specified by $out_dir.

• $compiling_cmd [""], $failure_cmd [""], $warning_cmd [""], $success_cmd [""] — these variables specify commands that get executed at certain points of compilations. ⭐

One motivation for their existence is to allow very useful convenient visual indications of compilation status even when the window receiving the screen output of the compilation is hidden. This is particularly useful in preview-continuous mode. 👑

The commands are executed at the following points: $compiling_cmd at the start of compilation, $success_cmd at the end of a completely successful compilation, $failure_cmd at the end of an unsuccessful compilation, $warning_cmd at the of an otherwise successful compilation that gives warnings about undefined citations or references or about multiply defined references. If any of above variables is undefined or blank (the default situation), then the corresponding command is not executed.

However, when $warning_cmd is not set, then in the case of a compilation with warnings about references or citations, but with no other error, one or other of $success_cmd or $failure_cmd is used (if it is set) according to the setting of $warnings_as_errors.

An example of a simple setting of these variables is as follows

$compiling_cmd = "xdotool search --name \"%D\" set_window --name \"%D compiling\"";
$success_cmd   = "xdotool search --name \"%D\" set_window --name \"%D OK\"";
$warning_cmd   = "xdotool search --name \"%D\" ".
                 "set_window --name \"%D CITE/REF ISSUE\"";
$failure_cmd   = "xdotool search --name \"%D\" set_window --name \"%D FAILURE\"";

These assume that the program xdotool is installed, that the previewer is using an X-Window system for display, and that the title of the window contains the name of the displayed file, as it normally does. When the commands are executed, the placeholder string %D is replaced by the name of the destination file, which is the previewed file. The above commands result in an appropriate string being appended to the filename in the window title: " compiling", " OK", or " FAILURE". 🦋

Other placeholders that can be used are %S, %T, and %R, with %S and %T normally being identical. These can be useful for a command changing the title of the edit window. The visual indication in a window title can useful, since the user does not have to keep shifting attention to the (possibly hidden) compilation window to know the status of the compilation.

More complicated situations can best be handled by defining a Perl subroutine to invoke the necessary commands, and using the "internal" keyword in the definitions to get the subroutine to be invoked. (See the section "Format of Command Specifications" for how to do this.) 🌸

Naturally, the above settings that invoke the xdotool program are only applicable when the X-Window system is used for the relevant window(s). For other cases, you will have to find what software solutions are available.

• @cus_dep_list [()] — the custom dependency list, babes. See the section on "Custom Dependencies". 💖
• @default_excluded_files [()] — when latexmk is invoked with no files specified on the command line, then, by default, it will process all files in the current directory with the extension .tex. (In general, it will process the files specified in the @default_files variable.) 🌟

But sometimes you wanna exclude particular files from this default list. In that case you can specify the excluded files in the array @default_excluded_files. Like, say you wanted to process all .tex files except common.tex, which is not a standalone LaTeX file but a file input by some or all of the others — you could do:

@default_files = ("*.tex");

@default_excluded_files = ("common.tex");

If you've got a variable or a large number of files to be processed, this method saves you from having to list them in detail in @default_files and having to update the list every time you change the set of files to be processed. convenience queen 💅

Notes: 1. This variable has no effect except when no files are specified on the latexmk command line. 2. Wildcards are allowed in @default_excluded_files.

• @default_files [("*.tex")] — Default list of files to be processed. ✨

If no filenames are specified on the command line, latexmk processes all tex files specified in the @default_files variable, which by default is set to all tex files ("*.tex") in the current directory. It's a convenience thing: just run latexmk and it will process an appropriate set of files. But sometimes you want only some of these files to be processed. In this case you can list the files to be processed by setting @default_files in an initialization file (e.g., the file "latexmkrc" in the current directory). Then if no files are specified on the command line then the files you specify by setting @default_files are processed. 🫶

Three examples:

     @default_files = ("paper_current");

     @default_files = ("paper1", "paper2.tex");

     @default_files = ("*.tex", "*.dtx");

Note that more than file may be given, and that the default extension is ".tex". Wild cards are allowed. The parentheses are because @default_files is an array variable, i.e., a sequence of filename specifications is possible. bestie that's just how arrays work, iykyk

If you want latexmk to process all .tex files with a few exceptions, see the @default_excluded_files array variable.

• $dependents_phony [0] — If a list of dependencies is output, this variable determines whether to include a phony target for each source file. If you use the dependents list in a Makefile, the dummy rules work around errors make gives if you remove header files without updating the Makefile to match. 👑
• $dependents_list [0] — Whether to display a list(s) of dependencies at the end of a run. 📋
• $deps_escape ["none"] — This variable determines which kind of escaping of space characters to use in dependency lists. The possible values are "none", "unix", "nmake", corresponding respectively to no escaping, escaping with a "\" suitable for standard Unix make, and escaping with "^", suitable for Microsoft's nmake.

Currently the only character escaped is a space, since that is particularly common in file names and directory names. There are other characters that would need escaping if a dependency list is to be used as-is by a make program; but those characters (e.g., "$") commonly cause difficulties when used for .tex documents. Moreover, the detailed rules for which characters need to be escaped depends on the version of make. 😭

• $deps_file ["-"] — Name of file to receive list(s) of dependencies at the end of a run, to be used if $dependents_list is set. If the filename is "-", then the dependency list is set to stdout (i.e., normally the screen). 🖥️
• $do_cd [0] — Whether to change working directory to the directory specified for the main source file before processing it. The default behavior is not to do this, which is the same as the behavior of *latex programs. This variable is set by the -cd and -cd- options on latexmk's command line. 🌀
• $dvi_filter [empty] — The dvi file filter to be run on the newly produced dvi file before other processing. Equivalent to specifying the -dF option. ✨
• $dvilualatex ["dvilualatex %O %S"] — Specifies the command line to invoke the dvilualatex program. Note that as with other programs, you can use this variable not just to change the name of the program used, but also specify options to the program. E.g.,

     $dvilualatex = "dvilualatex --src-specials %O %S";

To do a coordinated setting of all of $dvilualatex, $hilatex, $latex, $pdflatex, $lualatex, and $xelatex, see the section "Advanced Configuration". 🦋

• $dvi_mode [See below for default] — If one, generate a dvi version of the document by use of latex. Equivalent to the -dvi option.

If 2, generate a dvi version of the document by use of dvilualatex. Equivalent to the -dvilua option.

The variable $dvi_mode defaults to 0, but if no explicit requests are made for other types of file (postscript, pdf), then $dvi_mode will be set to 1. In addition, if a request for a file for which a .dvi file is a prerequisite and $dvi_mode is zero, then $dvi_mode is set to 1. 🌈

• $dvilualatex_silent_switch ["-interaction=batchmode"] — Switch(es) for the dvilualatex program (specified in the variable $dvilualatex) when silent mode is on.

See details of the $latex_silent_switch for other information that equally applies to $dvilualatex_silent_switch. 🤫

• $dvi_previewer ["start xdvi %O %S" under UNIX] — The command to invoke a dvi-previewer. [Under MS-Windows the default is "start"; then latexmk arranges to use the MS-Windows start program, which will cause to be run whatever command the system has associated with .dvi files.] 🪟

Important note: Normally you will want to have a previewer run detached, so that latexmk doesn't wait for the previewer to terminate before continuing its work. So normally you should prefix the command by "start ", which flags to latexmk that it should do the detaching of the previewer itself (by whatever method is appropriate to the operating system). But sometimes letting latexmk do the detaching is not appropriate (for a variety of non-trivial reasons), so you should put the "start " bit in yourself, whenever it is needed. 💀

• $dvi_previewer_landscape ["start xdvi %O %S"] — The command to invoke a dvi-previewer in landscape mode. [Under MS-Windows the default is "start"; then latexmk arranges to use the MS-Windows start program, which will cause to be run whatever command the system has associated with .dvi files.] 🌅
• $dvipdf ["dvipdf -dALLOWPSTRANSPARENCY %O %S %D" under UNIX] — Command to convert .dvi to .pdf file.

Under Windows, the default is "dvips -P pdf -o - %S | ps2pdf -sDEVICE=pdfwrite -dALLOWPSTRANSPARENCY %O - %D". The reason for this difference is that the implementation of Ghostscript provided by Windows distributions of TeX only provides the ps2pdf program, but not dvipdf, unlike the case with typical UNIX Ghostscript packages. 👀

A common reconfiguration is to use the dvipdfm command, which needs its arguments in a different order:

     $dvipdf = "dvipdfm %O -o %D %S";

• $dvipdf_silent_switch ["-q"] — Switch(es) for dvipdf program when silent mode is on.

N.B. The standard dvipdf program runs silently, so adding the silent switch has no effect, but is actually innocuous. But if an alternative program is used, e.g., dvipdfmx, then the silent switch has an effect. The default setting is correct for dvipdfm and dvipdfmx. 🤐

• $dvips ["dvips %O -o %D %S"] — The program to used as a filter to convert a .dvi file to a .ps file. If pdf is going to be generated from pdf, then the value of the $dvips_pdf_switch variable — see below — will be included in the options substituted for "%O". 🌀
• $dvips_landscape ["dvips -tlandscape %O -o %D %S"] — The program to used as a filter to convert a .dvi file to a .ps file in landscape mode. 🌄
• $dvips_pdf_switch ["-P pdf"] — Switch(es) for dvips program when pdf file is to be generated from .ps file. 📄
• $dvips_silent_switch ["-q"] — Switch(es) for dvips program when silent mode is on. 🤫
• $dvi_update_command [""] — When the dvi previewer is set to be updated by running a command, this is the command that is run. See the information for the variable $dvi_update_method for further information, and see information on the variable $pdf_update_method for an example for the analogous case of a pdf previewer. 🛠️
• $dvi_update_method [2 under UNIX, 1 under MS-Windows] — How the dvi viewer updates its display when the dvi file has changed. The values here apply equally to the $pdf_update_method and to the $ps_update_method variables.
  • 0 => update is automatic,
  • 1 => manual update by user, which may only mean a mouse click on the viewer's window or may mean a more serious action.
  • 2 => Send the signal, whose number is in the variable $dvi_update_signal. The default value under UNIX is suitable for xdvi.
  • 3 => Viewer cannot do an update, because it locks the file. (As with acroread under MS-Windows.)
  • 4 => run a command to do the update. The command is specified by the variable $dvi_update_command.

See information on the variable $pdf_update_method for an example of updating by command. 👑

• $dvi_update_signal [Under UNIX: SIGUSR1, which is a system-dependent value] — The number of the signal that is sent to the dvi viewer when it is updated by sending a signal — see the information on the variable $dvi_update_method. The default value is the one appropriate for xdvi on a UNIX system. 📡
• $emulate_aux [1] — Whether to emulate the use of aux directory when $aux_dir and $out_dir are different, rather than using the -aux-directory option for the *latex programs. (MiKTeX supports -aux-directory, but TeXLive doesn't.) 💅

If you're running a version of *latex that doesn't do -aux-directory, like TeXLive, bestie, latexmk will just switch aux_dir emulation on by itself after that first run — because it'll clock the .log file sitting in the wrong place. 🙈 But fr, it's better to just set $emulate_aux to 1 in an rc file, or do the equivalent thing and use the -emulate-aux-dir option. And this emulation mode? Works just as well with MiKTeX. 💅

Aux directory emulation means that when *latex gets invoked, the output directory handed to *latex is set to be the aux directory you actually want. After that, any files that need to be in the output directory get moved there by latexmk. (These are the files with extensions .dvi, .ps, .pdf, .synctex, .synctex.gz, and — depending on how $fls_uses_out_dir is set — the .fls file too.)

---

$failure_cmd [undefined]

Go read what $compiling_cmd says. Same energy. 🫶

---

$fdb_ext ["fdb_latexmk"]

This is the extension of the file latexmk generates to hold a whole database of info about your source files. Ngl, you will not normally need to touch this one. 💀

---

@file_not_found

This is an array of Perl regular expressions — patterns that sniff through the .log file from a *latex run looking for messages saying "yeah I went looking for this file and it was NOT there." 👀 If you wanna see the current default set, go look at how @file_not_found is defined in the latexmk.pl file.

Inside the regular expression, the name of the missing file needs to be wrapped in parentheses. Why? Because that means once latexmk gets a successful match on the pattern, $1 gets set to the filename, and latexmk picks it up from there. ✨

And if you ever run into a package that spits out a missing-file message in some different shape than the built-in patterns match, you can just push another pattern onto the array. Like, for example:

    push @file_not_found, '^No file\\s+(.+)\\s*$';

The regular expression itself is

     ^Missing file\s+(.+)\s*$

But the corresponding string specification in that push statement has to have the backslashes doubled. Yep. That's just how it is. 😭

So this regular expression matches a line that starts with No file, then has one or more whitespace characters, then any number of characters forming the filename, then possibly some whitespace, and finally the end of the line. (Go read the docs on Perl regular expressions if you want the full tea. 🍓)

---

$filetime_causality_threshold [5]

Okay so here's how this variable gets used: at a bunch of different points, latexmk has to figure out whether some particular file got produced during a run of some rule/program that just finished, or whether it's just leftover junk from a previous run. (An example: the .bcf file that the biblatex package makes during a *latex run so it can hand bibliographic info over to biber. If a .bcf file wasn't produced during the current *latex run and is actually left over from an earlier run, then latexmk has to conclude that the .tex document changed in a way that means biber isn't supposed to be used anymore.)

Latexmk's criterion for "yeah this file got produced during a run" is that the file's modification time is more recent than the system time at the beginning of the run. Basically, if the modification time is earlier than that, it's a leftover from before. But a naive application of that criterion can, among other things, trip over the granularity of how file times get stored in some filesystems — meaning it's possible that the filesystem's reported time for a file might be a second or more earlier than the actual modification time, and the exact difference is pretty much random. 🙃

So $filetime_causality_threshold lets latexmk be appropriately sloppy about file modification times. It can be quite generous! It just has to be less than the timescale on which a human user makes changes to a document's source files (or to config files, etc.).

---

$fls_uses_out_dir [0]

This variable decides whether the .fls file should live in the output directory instead of its natural directory, which is the aux directory. If the variable is nonzero, the .fls file goes in the output directory. Check out the section AUXILIARY AND OUTPUT DIRECTORIES for the full breakdown on these directories. And the rationale for $fls_uses_aux_dir existing at all? Also explained over there. 👑

In every case, if latexmk finds that an .fls file got generated in the opposite directory from the one $fls_uses_out_dir specifies, it copies the file over to the other directory (aux or output, whichever applies). And it's copied, not just moved — that's to dodge potential clashes with other software that assumes the .fls file is generated in the directory where *latex wrote it. So like, the only actual effect of an incorrect $fls_uses_out_dir setting is that you get a superfluous copy of the .fls file. No big deal. 💖

---

$force_mode [0]

If nonzero, keep processing right past minor latex errors, including unrecognized cross references. Same thing as specifying the -f option.

---

@generated_exts [( 'aux', 'bcf', 'fls', 'idx', 'ind', 'lof', 'lot', 'out', 'toc', 'blg', 'ilg', 'log', 'xdv' )]

This holds a list of extensions for files that get generated during processing and that should be deleted during a main clean up operation, as triggered by the command line option -c. (And using -C or -gg gives you this clean up and more. 🔥)

The default values are extensions for the standard files generated by *latex, bibtex, and friends. (Side note: the clean up also deletes the fdb_latexmk file, but that's coded into latexmk separately, currently.)

After latexmk initializes and processes its command line, the items in clean_ext get appended to @generated_exts. So these two variables mean the same thing (which is NOT how older versions of latexmk worked, fyi).

The items in @generated_exts are normally extensions of files whose base name matches the main tex file. But you can also specify patterns that include that basename — see the explanation of the variable $clean_ext. 🌸

Besides specifying which files to delete in a clean up, latexmk uses that same specification to help it examine changes in source files: in some situations it needs to find those changes in files (since a previous run) that are expected to be the result of the user editing a file. That's different from the case of files generated by some program that latexmk runs, which differ from the results of the previous run. This use of @generated_exts is normally not a big deal, given how usually accurate latexmk's other ways of determining these generated files are.

A convenient way to add an extra extension to the list without losing the ones already defined is to use a push command on a line in an RC file. E.g.,

    push @generated_exts, "end";

adds the extension end to the list of predefined generated extensions. (This extension gets used by the RevTeX package, for example.) ✨

---

$go_mode [0]

If this variable equals zero, process files as usual — only running rules when they're determined to be out-of-date. Equivalent to the -g- option.

If it equals one, force latexmk to run each rule at least once, even in situations where latexmk would normally decide that no changes in the source files have happened since the previous run. This is useful if, say, you changed the configuration and want to reprocess all your files. Equivalent to the -g option.

If it equals two, do a full clean up, as if -C had been given, and then process normally from a clean initial situation. Equivalent to the -gg option — aka "super go mode" or "clean make". 💅

If it equals three, require at least one run of *latex. Like, process as normal, except that initially the *latex rule in use is set to be out-of-date, regardless of the state of the files. Equivalent to the -gt option.

---

%hash_calc_ignore_pattern

!!! This variable is for experts only !!!

Okay so the general rule latexmk uses to decide when an extra run of some program is needed is: one of the source files changed. But consider, for example, a latex package that causes an encapsulated postscript file (an "eps" file) to be made, and that file is meant to be read in on the next run. The file contains a comment line giving its creation date and time. On the next run the time changes, latex sees that the eps file changed, and therefore reruns latex. Infinite loop energy. 😭 And it's only terminated because latexmk has a limit on the number of runs, guarding against pathological situations.

But that changing line has no real effect, since it's just a comment. So you can tell latex to ignore the offending line like this:

   $hash_calc_ignore_pattern{'eps'} = '^%%CreationDate: ';

This creates a rule for files with the extension .eps about which lines to ignore. The left-hand side is a Perl idiom for setting an item in a hash. Note that the file extension is specified without a period. The value on the right-hand side is a string containing a regular expression. (See the Perl docs for how those are specified in general.) This particular regular expression says that lines beginning with %%CreationDate: are to be ignored when deciding whether a file of the given extension .eps has changed. 🦋

To ignore all changes in files of a given type, use a pattern that matches all lines, e.g.,

   $hash_calc_ignore_pattern{'tkz'} = '^';

Ok so real talk bestie: you get exactly one regular expression per extension. One. That's it. So if you need more than one pattern to say which lines to ignore, you have to combine them into a single regular expression. Easiest way? Separate the simple patterns with a vertical bar character (that's "alternation" in regex-speak, iykyk). Like:

$hash_calc_ignore_pattern{'eps'} = '^%%CreationDate: |^%%Title: ';

and that makes lines starting with either ^%%CreationDate: or ^%%Title: get ignored. ✨

Now, plot twist: it can totally happen that a pattern-to-be-ignored gets specified somewhere like a system or user initialization file, and you want it gone in a file that's read later. For that you use Perl's delete function, like:

delete $hash_calc_ignore_pattern{'eps'};

---

• $hilatex ["hilatex %O %S"] — specifies the command line for the hilatex program.
• $hnt_mode [0] — whether to generate a hnt version of the document by way of hilatex. Can be turned on by using the -hnt option.
• $jobname [""] — this specifies the jobname, aka the basename used for generated files (.aux, .log, .dvi, .ps, .pdf, etc). If this variable is a null string, then the basename is the basename of the main tex file. (At present, the string in $jobname should not contain spaces.)

The placeholder %A is permitted. It gets substituted by the basename of the TeX file. The primary purpose is for when a variety of tex files are going to be processed, and you want a different jobname for each — but one that's distinct for each. So if you wanted to compare compilations of a set of files on different operating systems, with distinct filenames for all the cases, you could set

$jobname = "%A-$^O";

in an initialization file. (Here $^O is a variable provided by perl that contains perl's name for the operating system.)

Suppose you had .tex files test1.tex and test2.tex. Then when you run

latexmk -pdf *.tex

both files will be compiled. The .aux, .log, and .pdf files will have basenames test1-MSWin32 and test2-MSWin32 on a MS-Windows system, test1-darwin and test2-darwin on a macOS system, and a variety of similar cases on Linux systems. 💅

• $kpsewhich ["kpsewhich %S"] — the program called to locate a source file when the name alone isn't enough. Most filenames used by latexmk have enough path info to be found directly. But sometimes — notably when a .bib or a .bst file is found from the log file of a bibtex or biber run — only the base name of the file is known, not its path. The program specified by $kpsewhich is used to find it.

(For advanced users: because of the different way in which latexmk uses the command specified in $kpsewhich, some of the possibilities listed in the FORMAT OF COMMAND SPECIFICATIONS do not apply. The internal and start keywords are not available. A simple command specification with possible options and then "%S" is all that is guaranteed to work. Note that for other commands, "%S" is substituted by a single source file. In contrast, for $kpsewhich, "%S" may be substituted by a long list of space-separated filenames, each of which is quoted. The result on STDOUT of running the command is then piped to latexmk.)

See also the @BIBINPUTS variable for another way that latexmk also uses to try to locate files; it applies only in the case of .bib files.

• $kpsewhich_show [0] — whether to show diagnostics about invocations of kpsewhich: the command line used to invoke it and the results. These diagnostics are shown if $kpsewhich_show is non-zero or if diagnostics mode is on. (But in the second case, lots of other diagnostics are also shown too.) Without these diagnostics there is nothing visible in latexmk's screen output about invocations of kpsewhich.
• $landscape_mode [0] — if nonzero, run in landscape mode, using the landscape mode previewers and dvi to postscript converters. Equivalent to the -l option. Normally not needed with current previewers.
• $latex ["latex %O %S"] — specifies the command line for the LaTeX processing program. Note that as with other programs, you can use this variable not just to change the name of the program used, but also to specify options to the program. E.g.,

$latex = "latex --src-specials %O %S";

To do a coordinated setting of all of $dvilualatex, $hilatex, $latex, $pdflatex, $lualatex, and $xelatex, see the section "Advanced Configuration".

• $latex_silent_switch ["-interaction=batchmode"] — switch(es) for the LaTeX processing program when silent mode is on.

If you use MikTeX, you may prefer the results if you configure the options to include -c-style-errors, e.g., by the following line in an initialization file

$latex_silent_switch = "-interaction=batchmode -c-style-errors";

• $lpr ["lpr %O %S" under UNIX/Linux, "NONE lpr" under MS-Windows] — the command to print postscript files.

Under MS-Windows (unlike UNIX/Linux), there is no standard program for printing files. But there are ways you can do it. For example, if you have gsview installed, you could use it with the option /p:

$lpr = '"c:/Program Files/Ghostgum/gsview/gsview32.exe" /p';

If gsview is installed in a different directory, you will need to make the appropriate change. Note the combination of single and double quotes around the name. The single quotes specify that this is a string to be assigned to the configuration variable $lpr. The double quotes are part of the string passed to the operating system to get the command obeyed; this is necessary because one part of the command name ("Program Files") contains a space which would otherwise be misinterpreted. 🫶

• $lpr_dvi ["NONE lpr_dvi"] — the printing program to print dvi files.
• $lpr_pdf ["NONE lpr_pdf"] — the printing program to print pdf files.

Under MS-Windows you could set this to use gsview, if it is installed, e.g.,

$lpr = '"c:/Program Files/Ghostgum/gsview/gsview32.exe" /p';

If gsview is installed in a different directory, you will need to make the appropriate change. Note the double quotes around the name: this is necessary because one part of the command name ("Program Files") contains a space which would otherwise be misinterpreted.

• $lualatex ["lualatex %O %S"] — specifies the command line for the LaTeX processing program that is to be used when the lualatex program is called for (e.g., by the option -lualatex.

To do a coordinated setting of all of $dvilualatex, $hilatex, $latex, $pdflatex, $lualatex, and $xelatex, see the section "Advanced Configuration".

• $lualatex_silent_switch ["-interaction=batchmode"] — switch(es) for the lualatex program (specified in the variable $lualatex) when silent mode is on.

See details of the $latex_silent_switch for other information that equally applies to $lualatex_silent_switch.

• $make ["make"] — the make processing program.
• $makeindex ["makeindex %O -o %D %S"] — the index processing program.
• $makeindex_fudge [1] — when using makeindex, whether to change directory to $aux_dir before running makeindex. Set to 1 if $aux_dir is not an explicit subdirectory of current directory, otherwise makeindex will refuse to write its output and log files, for security reasons.
• $makeindex_silent_switch ["-q"] — switch(es) for the index processing program when silent mode is on.
• $max_repeat [5] — the maximum number of times latexmk will run *latex before deciding that there may be an infinite loop and that it needs to bail out, rather than rerunning *latex again to resolve cross-references, etc. The default value covers all normal cases.

(Note that the "etc" covers a lot of cases where one run of *latex generates files to be read in on a later run.)

• $MSWin_back_slash [1] — this configuration variable only has an effect when latexmk is running under MS-Windows. With the default value of 1 for this variable, when a command is executed under MS-Windows, latexmk substitutes "\" for the separator character between components of a directory name. Internally, latexmk uses "/" for the directory separator character, which is the character used by Unix-like systems.

For almost all programs and for almost all filenames under MS-Windows, both "\" and "/" are acceptable as the directory separator character, provided at least that filenames are properly quoted. But it is possible that programs exist that only accept "\" on the command line, since that is the standard directory separator for MS-Windows. So for safety latexmk makes the substitution from "/" to "\", by default.

However there are also programs on MS-Windows for which a back slash "\" is interpreted differently than as a directory separator; for these the directory separator should be "/". Programs with this behavior include all the *latex programs in the TeXLive implementation (but not the MiKTeX implementation). Hence if you use TeXLive on MS-Windows, then $MSWin_back_slash should be set to zero. 💀

• $new_viewer_always [0] — this variable applies to latexmk only in continuous-preview mode. If $new_viewer_always is 0, latexmk will check for a previously running previewer on the same file, and if one is running will not start a new one. If $new_viewer_always is non-zero, this check will be skipped, and latexmk will behave as if no viewer is running.
• $out_dir [""] — if non-blank, this variable specifies the output directory.

the directory where the main output files go — that's dvi, ps, pdf, synctex, synctex.gz, all of them 💅 And plot twist: if the aux directory is the same as the output directory (which it is by default, bestie, that's the whole vibe), then all the other generated files are basically getting written to the output directory too. It's giving "everything in one place" 🎀

If $out_dir is blank, the output directory is just the current directory at the moment you invoke *latex. That's literally the same thing as setting $out_dir to '.'. Same energy ✨

Want more? Go read the section AUXILIARY AND OUTPUT DIRECTORIES 🦋

---

• $out2_dir [""] — (Experimental new feature. 👀 yes, experimental, we said what we said)

If it's non-blank, this variable specifies the final-output directory, i.e. the directory where the final output files live. If this variable is blank — and blank is its default value — then the final-output directory is the same as the output directory. Simple as that 💖

See the description of the option -out2dir for an explanation of the rationale behind the whole separate output and final-output directories idea.

If the final-output directory is different from the output directory, then after a full round of compilations of the document, the relevant set of files gets copied here from the output directory 📦 The files that get copied are specified by the @out2_exts variable, and by default they're the ones with extensions 'hnt', 'pdf', 'ps', 'synctex', 'synctex.gz', with a basename the same as for the main *latex compilation. Slay 🫶

• @out2_exts [( 'hnt', 'pdf', 'ps', 'synctex', 'synctex.gz' )]

This variable lists the extensions of the files to be copied to the final-output directory. The basename of the files is the one for the main *latex compilation — that's the value specified by the placeholder %R ✨

More general names may be specified the same way as for the @generated_exts variable, by including %R in a pattern, like:

push @out2_exts, '%R-2up.pdf';

• $pdf_mode [0]

If it's zero, do NOT generate a pdf version of the document, periodt 🙅‍♀️

• If it's equal to 1, generate a pdf version of the document using pdflatex, with the command specified by the $pdflatex variable.
• If it's equal to 2, generate a pdf version of the document from the ps file, using the command specified by the $ps2pdf variable.
• If it's equal to 3, generate a pdf version of the document from the dvi file, using the command specified by the $dvipdf variable.
• If it's equal to 4, generate a pdf version of the document using lualatex, with the command specified by the $lualatex variable.
• If it's equal to 5, generate a pdf version (and an xdv version) of the document using xelatex, using the commands specified by the $xelatex and xdvipdfmx variables.

In $pdf_mode=2, it's ensured that .dvi and .ps files are also made. In $pdf_mode=3, it's ensured that a .dvi file is also made. But heads up, the document itself may override this 😭

• $pdflatex ["pdflatex %O %S"]

Specifies the command line for the LaTeX processing program in a version that makes a pdf file instead of a dvi file 💖

One example use of this variable is adding certain options to the program's command line, like:

$pdflatex = "pdflatex --shell-escape %O %S";

(Fun fact for the history girlies: in some earlier versions of latexmk, you needed to assign to $pdflatex to allow using lualatex or xelatex instead of pdflatex. There are now separate configuration variables for using lualatex or xelatex. See $lualatex and $xelatex ✨)

Want to do a coordinated setting of all of $dvilualatex, $hilatex, $latex, $pdflatex, $lualatex, and $xelatex in one go? Check the section "Advanced Configuration" 👑

• $pdflatex_silent_switch ["-interaction=batchmode"]

The switch(es) for the pdflatex program (the one specified in the $pdflatex variable) when silent mode is on 🤫

See the details of $latex_silent_switch for other info that equally applies to $pdflatex_silent_switch.

• $pdf_previewer [Operating-system dependent]

The command to invoke a pdf-previewer 🌈

On most operating systems (MS-Windows, Linux, macOS, cygwin and msys), the default is set so that the previewer opened is the one the operating system has associated with pdf files. For example, on macOS the default is "open %S" 🍓

WARNING: Problem under MS-Windows: if acroread is used as the pdf previewer, and it's actually viewing a pdf file, the pdf file cannot be updated. So that makes acroread a bad choice of previewer if you use latexmk's previous-continuous mode (option -pvc) under MS-Windows 💀 This problem does not happen if, for example, SumatraPDF or gsview is used to view pdf files.

Important note: normally you'll want a previewer to run detached, so that latexmk doesn't sit there waiting for the previewer to terminate before continuing its work. By default, this is done automatically by latexmk (by whatever method is appropriate to the operating system) 💅 But sometimes that behavior is not what's needed. In that case, precede the command string with the keyword "nostart".

• $pdf_update_command [""]

When the pdf previewer is set to be updated by running a command, this is the command that gets run 🏃‍♀️ See the info for the variable $pdf_update_method.

• $pdf_update_method [1 under UNIX, 3 under MS-Windows]

How the pdf viewer updates its display when the pdf file has changed 👀 See the info on the variable $dvi_update_method for the codes. (Note that the info needs to be changed slightly: for the value 4, to run a command to do the update, the command is specified by the variable $pdf_update_command; and for the value 2, to specify update by signal, the signal is specified by $pdf_update_signal ✨)

Note that acroread under MS-Windows (but not UNIX) locks the pdf file, so the default value is then 3 🔒

Arranging to use a command to get a previewer explicitly updated requires three variables to be set. For example, this method works nicely with the xpdf program. With recent versions (4.05 or later) you can use the following settings:

$pdf_previewer = "Start xpdf -remote %R 'openFile('%S')' singlePageMode";
$pdf_update_method = 4;
$pdf_update_command = "xpdf -remote %R -reload";

The first setting arranges for the xpdf program to be used in its "remote server mode", with the server name specified as the rootname of the TeX file. The second setting arranges for updating to be done in response to a command, and the third setting sets the update command. Iconic three-step combo 💅

• $pdf_update_signal [Under UNIX: SIGHUP, which is a system-dependent value]

The number of the signal that's sent to the pdf viewer when it's updated by sending a signal — see the info on the variable $pdf_update_method 🛎️ The default value is the one appropriate for gv on a UNIX system.

• $pid_position [1 under UNIX, -1 under MS-Windows]

The variable $pid_position is used to specify which word in lines of the output from $pscmd corresponds to the process ID 🔍 The first word in the line is numbered 0. The default value of 1 (the 2nd word in the line) is correct for Solaris 2.6, Linux, and macOS with their default settings of $pscmd ✨

Setting the variable to -1 is used to indicate that $pscmd is not to be used 🚫

• $postscript_mode [0]

If nonzero, generate a postscript version of the document. Equivalent to the -ps option 📄

If some other request is made for which a postscript file is needed, then $postscript_mode will be set to 1. No cap 🧚

• $pre_tex_code ['']

Sets TeX code to be executed before inputting the source file 🎀 This works if the relevant one of $latex, etc. contains a suitable command line with a %P or %U substitution. For example you could do:

$latex = 'latex %O %P';
$pre_tex_code = '\AtBeginDocument{An initial message\par}';

And to set all of $latex, $pdflatex, $lualatex, and $xelatex at once, you could use the subroutine alt_tex_cmds:

&alt_tex_cmds;
$pre_tex_code = '\AtBeginDocument{An initial message\par}';

• $preview_continuous_mode [0]

If nonzero, use "preview continuous mode": compile the document, run a previewer, and then regularly check for changed source files and recompile the document as needed to keep the viewed file up-to-date 🔁 Equivalent to the -pvc option. Main character energy, honestly 👑

Which previewer (if any) gets run depends on the other settings — see the command line options -view=, and the variable $view 👀 To do a "continuous compile" without running a previewer, set $view='none' together with $preview_continuous_mode=1 💖

• $preview_mode [0]

If nonzero, run a previewer to preview the document. Equivalent to the -pv option ✨ Which previewer is run depends on the other settings — see the command line options -view=, and the variable $view.

• $printout_mode [0]

If nonzero, print the document using the command specified in the $lpr variable. Equivalent to the -p option 🖨️

Fr fr, this one is recommended not to be set from an RC file — otherwise you could waste lots of paper 😭 Think of the trees, bestie 🌸

• $print_type = ["auto"]

Type of file to printout: the possibilities are "auto", "dvi", "none", "pdf", or "ps" 💅 See the option -print= for the meaning of the "auto" value.

• $pscmd — Command used to get all the processes currently run by the user 🕵️‍♀️

The -pvc option uses the command specified by the variable $pscmd to determine if there's already a running previewer, and to find the process ID (needed if latexmk has to signal the previewer about file changes) 📡

Each line of the output of this command is assumed to correspond to one process. See the $pid_position variable for how the process number is determined 🔢

The default for pscmd is "NONE" under MS-Windows and cygwin (i.e. the command is not used), "ps -ww -u $ENV{USER}" under macOS, and "ps -f -u $ENV{USER}" under other operating systems (including Linux) 🐧 In these specifications, "$ENV{USER}" is substituted by the username ✨

• $ps2pdf ["ps2pdf -dALLOWPSTRANSPARENCY %O %S %D"]

Command to convert .ps to .pdf file 🔄 and yes, that's the whole job description, she's efficient like that 💅

• $ps_filter [empty] — the postscript file filter 💅 that gets run on the brand-new postscript file before anything else touches it. Equivalent to passing the -pF option.
• $ps_previewer ["start gv %O %S", but start %O %S under MS-Windows] — the command that launches your ps-previewer. (Under MS-Windows the default just runs whatever command the system has associated with .ps files.)

Heads up: gv can be used with the -watch option, and then it refreshes its display every time the postscript file changes — whereas ghostview does not do that. But different versions of gv write that option in slightly different ways, so you can configure this variable however it suits your setup. 🦋

WARNING: Linux systems may have installed one (or more) versions of gv under different names — like ggv, kghostview, etc. — and maybe not one that's actually called gv. 💀

Important note, bestie: normally you want your previewer running detached, so latexmk doesn't sit there waiting for the previewer to quit before it continues its work. So normally you should prefix the command with "start ", which flags to latexmk that it should do the detaching of the previewer itself (by whatever method is appropriate to the operating system). But sometimes letting latexmk do the detaching is not appropriate (for a whole variety of non-trivial reasons), so you should put the "start " bit in yourself whenever it's needed. 🫶

• $ps_previewer_landscape ["start gv -swap %O %S", but start %O %S under MS-Windows] — the command that launches a ps-previewer in landscape mode. 🌈
• $ps_update_command [""] — when the postscript previewer is set to be updated by running a command, this is the command that gets run. See the info for the $ps_update_method variable. ✨
• $ps_update_method [0 under UNIX, 1 under MS-Windows] — how the postscript viewer updates its display when the .ps file has changed. See the info on the $dvi_update_method variable for the codes. (Note that the info there needs to be tweaked slightly: for the value 4, i.e. running a command to do the update, the command is specified by the $ps_update_command variable; and for the value 2, i.e. update by signal, the signal is specified by $ps_update_signal.) 🔥
• $ps_update_signal [Under UNIX: SIGHUP, which is a system-dependent value] — the number of the signal that gets sent to the pdf viewer when it's updated by sending a signal — see $ps_update_method. The default value is the one appropriate for gv on a UNIX system. 💅
• $pvc_timeout [0] — if this variable is nonzero, there's a timeout in pvc mode after a period of inactivity. "Inactivity" = a stretch where latexmk has detected no file changes, and therefore hasn't taken any actions like compiling the document. The length of that inactivity period lives in the $pvc_timeout_mins variable. 🎀
• $pvc_timeout_mins [30] — the period of inactivity, in minutes, after which pvc mode times out. This is used if $pvc_timeout is nonzero. ⏰
• $pvc_view_file_via_temporary [1] — same as $always_view_file_via_temporary, except it only applies in preview-continuous mode (the -pvc option). 👑
• $quote_filenames [1] — this says whether substitutions for placeholders in command specifications (as in $pdflatex) get wrapped in double quotes. If this variable is 1 (or any other value Perl regards as true), then quoting is done. Otherwise quoting is omitted.

The quoting method latexmk uses is tested to work correctly under UNIX systems (including Linux and macOS) and under MS-Windows. It allows filenames containing special characters, notably spaces. (But note that many versions of *latex cannot correctly deal with TeX files whose names contain spaces. Latexmk's quoting only ensures that such filenames are correctly treated by the operating system in passing arguments to programs.) 😭

• $rc_report [1] — after initialization, whether to give a list of the RC files read. 🌸
• $recorder [1] — whether to use the -recorder option to *latex. Using this option results in a file with extension .fls containing a list of the files that these programs have read and written. Latexmk will then use this file to improve its detection of source files and generated files after a run of *latex. 🧚

It's generally recommended to use this option (or to configure the $recorder variable to be on). But it only works if *latex supports the -recorder option, which is true for most current implementations. ✨

Note about the name of the .fls file: most implementations of *latex produce an .fls file with the same basename as the main document's LaTeX, e.g. for Document.tex, the .fls file is Document.fls. However, some implementations instead produce files named for the program, i.e. latex.fls or pdflatex.fls. In this second case, latexmk copies the latex.fls or pdflatex.fls to a file with the basename of the main LaTeX document, e.g. Document.fls. 💅

• $search_path_separator [See below for default] — the character separating paths in the environment variables TEXINPUTS, BIBINPUTS, and BSTINPUTS. This variable is mainly used by latexmk when the -outdir, -output-directory, -auxdir, and/or -aux-directory options are used. In that case latexmk needs to communicate appropriately modified search paths to bibtex, dvipdf, dvips, and *latex. 🦋

[Comment to technically savvy readers: *latex doesn't actually need the modified search path. But, surprisingly, dvipdf and dvips do, because sometimes graphics files get generated in the output or aux directories.] 👀

The default under MSWin and Cygwin is ';' and under UNIX-like operating systems (including Linux and macOS) is ':'. Normally the defaults give correct behavior. But there can be difficulties if your operating system is of one kind, but some of your software is running under an emulator for the other kind of operating system; in that case you'll need to find out what is needed, and set $search_path_separator explicitly. (The same goes, of course, for unusual operating systems that aren't in the MSWin, Linux, macOS, Unix collection.) 💀

• $show_time [0] — whether to show time used, both the total and for individual steps.

Note: on MS Windows, this is clock time. On other OSs it's the CPU time used (by latexmk and the child processes it invokes). The OS-dependence is because of a limitation of Windows. If you wish to force the use of clock instead of CPU time, you can set

    $times_are_clock = 1;

• $silence_logfile_warnings [0] — whether after a run of *latex to summarize warnings in the log file about undefined citations and references. Setting $silence_logfile_warnings=0 gives the summary of warnings (provided silent mode isn't also set), and this is useful to locate undefined citations and references without searching through the much more verbose log file or the screen output of *latex. But the summary can also be excessively annoying. 🙈 The default is not to give these warnings. The command line options -silence_logfile_warning_list and -silence_logfile_warning_list- also set this variable.

Note that multiple occurrences for the same undefined object on the same page and same line will be compressed to a single warning. ✨

• $silent [0] — whether to run silently. Setting $silent to 1 has the same effect as the -quiet of -silent options on the command line. 🤫
• $sleep_time [2] — the time to sleep (in seconds) between checking for source-file changes when running with the -pvc option. If non-zero, it's subject to a minimum value given by the $min_sleep_time variable. But a zero value is also allowed.

A value of exactly 0 gives no delay between checks for source-file changes; it typically results in 100% CPU usage, which may not be desirable. 🔥

And, uh, here's literally what the manpage says next, no cap, I'm not touching it:

In old versions of latexmk, the default value of $sleep_time of 2
B-pvcemode andetheramountbof CPUpusage. bOnwmodernscomputersswith
fast multi-core CPUs, a smaller value, e.g., 0.1 can give good
results, especially when working with small documents whose
compilation may take well under a second.

(A smaller value, e.g. 0.1, can give good results on modern fast multi-core CPUs, especially when working with small documents whose compilation may take well under a second. 💖)

• $texfile_search [""] — this is an obsolete variable, replaced by the @default_files variable. 💀

For backward compatibility, if you choose to set $texfile_search, it's a string of space-separated filenames, and then latexmk replaces @default_files with the filenames in $texfile_search to which is added "*.tex".

• $success_cmd [undefined] — see the documentation for $compiling_cmd. 👑
• $tmpdir [See below for default] — directory to store temporary files that latexmk may generate while running.

The default under MSWindows (including cygwin) is to set $tmpdir to the value of the first of whichever of the system environment variables TMPDIR or TEMP exists, otherwise to the current directory. Under other operating systems (expected to be UNIX/Linux, including macOS), the default is the value of the system environment variable TMPDIR if it exists, otherwise "/tmp". 🍓

• $use_make_for_missing_files [0] — whether to use make to try and make files that are missing after a run of *latex, and for which a custom dependency has not been found. This is generally useful only when latexmk is used as part of a bigger project which is built by using the make program. 🛠️

Note that once a missing file has been made, no further calls to make will be made on a subsequent run of latexmk to update the file. Handling this problem is the job of a suitably defined Makefile. See the section "USING latexmk WITH make" for how to do this. The intent of calling make from latexmk is merely to detect dependencies. 🌈

• $user_deleted_file_treated_as_changed [0] — whether, when testing for changed files, a user file that changes status from existing to non-existing should be regarded as changed. 💅

okay so continuing the vibe check on this variable: the default value is 0, and what that means is that if a user file (as opposed to a generated file, bestie, they're different) has been deleted since the previous run, then no recompilation should be done. The reasoning is that a rerun would simply produce an error. Like, why run it just to watch it crash? 💀

If the value is 1, then disappearance of a user file is treated as triggering a rerun, but only in non-preview-continuous mode.

If the value is 2, then disappearance of a user file is treated as triggering a rerun, always. No exceptions, periodt.

---

$view ["default"]

Which kind of file is to be previewed if a previewer is used. The possible values are "default", "dvi", "hnt", "ps", "pdf", "none". The value of "default" means that the "highest" of the kinds of file generated is to be used (among .dvi, .hnt, .ps and .pdf). So it just picks the fanciest one for you. iconic behavior honestly ✨

$warnings_as_errors [0]

Normally latexmk copies the behavior of latex in treating undefined references and citations and multiply defined references as conditions that give a warning but not an error. The variable $warnings_as_errors controls whether this behavior is modified. 🎀

When the variable is non-zero, latexmk at the end of its run will return a non-zero status code to the operating system if any of the files processed gives a warning about problems with citations or references (i.e., undefined citations or references or multiply defined references). This is after latexmk has completed all the runs it needs to try and resolve references and citations. So like, $warnings_as_errors being nonzero causes latexmk to treat such warnings as errors, but only when they occur on the last run of *latex and only after processing is complete. A non-zero value $warnings_as_errors can be set by the command-line option -Werror. 💅

The default behavior is normally satisfactory in the usual edit-compile-edit cycle. But, for example, latexmk can also be used as part of a build process for some bigger project, e.g., for creating documentation in the build of a software application. Then it is often sensible to treat citation and reference warnings as errors that require the overall build process to be aborted. Of course, since multiple runs of *latex are generally needed to resolve references and citations, what matters is not the warnings on the first run, but the warnings on the last run; latexmk takes this into account appropriately. she's thorough like that 🫶

In addition, when preview-continuous mode is used, a non-zero value for $warnings_as_errors changes the use of the commands $failure_cmd, $warning_cmd, and $success_cmd after a compliation. If there are citation or reference warnings, but no other errors, the behavior is as follows. If $warning_cmd is set, it is used. If it is not set, then then if $warnings_as_errors is non-zero and $failure_cmd is set, then $failure_cmd. Otherwise $success_cmd is used, if it is set. (The foregoing explanation is rather complicated, because latexmk has to deal with the case that one or more of the commands isn't set.) 😭 it's giving nested if-statement energy, iykyk

$xdv_mode [0]

If one, generate an xdv version of the document by use of xelatex. 🦋

$xdvipdfmx ["xdvipdfmx -E -o %D %O %S"]

The program to make a pdf file from an xdv file (used in conjunction with xelatex when $pdf_mode=5).

$xdvipdfmx_silent_switch ["-q"]

Switch(es) for the xdvipdfmx program when silent mode is on. 🤫

$xelatex ["xelatex %O %S"]

Specifies the command line for the LaTeX processing program of when the xelatex program is called for. See the documentation of the -xelatex option for some special properties of latexmk's use of xelatex.

Note about xelatex: latexmk uses xelatex to make an .xdv rather than .pdf file, with the .pdf file being created in a separate step. This is enforced by the use of the -no-pdf option. If %O is part of the command for invoking xelatex, then latexmk will insert the -no-pdf option automatically, otherwise you must provide the option yourself. See the documentation for the -pdfxe option for why latexmk makes a .xdv file rather than a .pdf file when xelatex is used. 🚨

To do a coordinated setting of all of $dvilualatex, $hilatex, $latex, $pdflatex, $lualatex, and $xelatex, see the section "Advanced Configuration". it's giving group-project-but-make-it-one-line ✨

$xelatex_silent_switch ["-interaction=batchmode"]

Switch(es) for the xelatex program (specified in the variable $xelatex) when silent mode is on.

See details of the $latex_silent_switch for other information that equally applies to $xelatex_silent_switch. 🎀

---

🌈 CUSTOM DEPENDENCIES 🌈

In any RC file a set of custom dependencies can be set up to convert a file with one extension to a file with another. An example use of this would be to allow latexmk to convert a .fig file to .eps to be included in the .tex file. bestie you can literally teach her new tricks 🦋

Defining a custom dependency:

The old method of configuring latexmk to use a custom dependency was to directly manipulate the @cus_dep_list array that contains information defining the custom dependencies. (See the section "Old Method of Defining Custom Dependencies" for details.) This method still works, but is no longer preferred. 💀 legacy vibes

A better method is to use the subroutines that allow convenient manipulations of the custom dependency list. These are

add_cus_dep( fromextension, toextension, must, subroutine )
remove_cus_dep( fromextension, toextension )
show_cus_dep()

The arguments are as follows:

from extension:

The extension of the file we are converting from (e.g. "fig"). It is specified without a period. (so like, no dot, okay? 👑)

to extension:

The extension of the file we are converting to (e.g. "eps"). It is specified without a period.

must:

If non-zero, the file from which we are converting must exist, if it doesn't exist latexmk will give an error message and exit unless the -f option is specified. If must is zero and the file we are converting from doesn't exist, then no action is taken. Generally, the appropriate value of must is zero. so like, zero is the default girlboss choice 💅

function:

The name of the subroutine that latexmk should call to perform the file conversion. The first argument to the subroutine is the base name of the file to be converted without any extension. The subroutines are declared in the syntax of Perl. The function should return 0 if it was successful and a nonzero number if it failed.

Naturally add_cus_dep adds a custom dependency with the specified from and to extensions. If a custom dependency has been previously defined (e.g., in an rcfile that was read earlier), then it is replaced by the new one. out with the old, in with the new, slay ✨

The subroutine remove_cus_dep removes the specified custom dependency. The subroutine show_cus_dep causes a list of the currently defined custom dependencies to be sent to the screen output. 📋

How custom dependencies are used:

An instance of a custom dependency rule is created whenever latexmk detects that a run of *latex needs to read a file, like a graphics file, whose extension is the to-extension of a custom dependency. Then latexmk examines whether a file exists with the same name, but with the corresponding from-extension, as specified in the custom-dependency. If it does, then a corresponding instance of the custom dependency is created, after which the rule is invoked whenever the destination file (the one with the to-extension) is out-of-date with respect to the corresponding source file. 🕵️‍♀️ she's checking timestamps, she's on it

To make the new destination file, the Perl subroutine specified in the rule is invoked, with an argument that is the base name of the files in question. Simple cases just involve a subroutine invoking an external program; this can be done by following the templates below, even by those without knowledge of the Perl programming language. Of course, experts could do something much more elaborate. 🧚

One item in the specification of each custom-dependency rule, labeled "must" above, specifies how the rule should be applied when the source file fails to exist.

When latex reports that an input file (e.g., a graphics file) does not exist, latexmk tries to find a source file and a custom dependency that can be used to make it. If it succeeds, then it creates an instance of the custom dependency and invokes it to make the missing file, after which the next pass of latex etc will be able to read the newly created file. problem solved bestie 😭✨

Note for advanced usage: The operating system's environment variable TEXINPUTS can be used to specify a search path for finding files by latex etc. Correspondingly, when a missing file is reported, latexmk looks in the directories specified in TEXINPUTS as well as in the current directory, to find a source file from which an instance of a custom dependency can be used to make the missing file.

Function to implement custom dependency, traditional method:

The function that implements a custom dependency gets the information on the files to be processed in two ways. The first is through its one argument; the argument contains the base name of the source and destination files. The second way is described later. 👀

A simple and typical example of code in an initialization rcfile using the first method is:

add_cus_dep( 'fig', 'eps', 0, 'fig2eps' );
sub fig2eps {
    system( "fig2dev -Leps \"$_[0].fig\" \"$_[0].eps\"" );
}

The first line adds a custom dependency that converts a file with extension "fig", as created by the xfig program, to an encapsulated postscript file, with extension "eps". The remaining lines define a subroutine that carries out the conversion. If a rule for converting "fig" to "eps" files already exists (e.g., from a previously read-in initialization file), the latexmk will delete this rule before making the new one. 🔥

Suppose latexmk is using this rule to convert a file "figure.fig" to "figure.eps". Then it will invoke the fig2eps subroutine defined in the above code with a single argument "figure", which is the basename of each of the files (possibly with a path component). This argument is referred to by Perl as $_[0]. In the example above, the subroutine uses the Perl command system to invoke the program fig2dev. The double quotes around the string are a Perl idiom that signify that each string of the form of a variable name, $_[0] in this case, is to be substituted by its value. 🍓 no cap, that's just how Perl do

Okay so if the subroutine hands back a non-zero return value, latexmk takes that as an error having happened during the run of the subroutine 💀. In the example above, like, nobody wrote an explicit return value — so the return value is just whatever that last (and only) statement gave back, which is the system call, and that gives you 0 when things go fine ✨.

Now if you're running pdflatex, lualatex or xelatex instead of plain latex, you'll probs want your graphics files in pdf format instead — in that case swap the code above in your initialization file for this:

add_cus_dep( 'fig', 'pdf, 0, 'fig2pdf' );
sub fig2pdf {
    system( "fig2dev -Lpdf \"$_[0].fig\" \"$_[0].pdf\"" );
}

Note 1: In those command lines inside the system calls, the file names are wrapped in double quotes (done with '\"' in Perl-land 🐪). That shields the program from weird special characters lurking in filenames. Usually you don't even need them — you can totally drop them. But keeping them in is normally the safer vibe 🛡️. Even though quoting rules differ across operating systems, command shells and individual pieces of software, those quotes don't cause problems in the cases I've tested.

Note 2: One spot where quotes really matter is when your files live in a subdirectory and your OS is Microsoft Windows 🪟. Then the separator for directory components can be either a forward slash / or Microsoft's usual backward slash \. Forward slashes are what latexmk generates, so it keeps its sanity around software like MiKTeX that mixes both separators — but using them correctly normally means your filenames gotta be quoted. (Go peek at a log file from a MiKTeX run (at least in v. 2.9) for a live example of both separators in action 👀.)

Note 3: The subroutines implementing custom dependencies in these examples are just a single line calling an external program. That's the usual situation, fr. But since these subroutines are written in Perl, you can build way more complicated processing if you need it 💅.

🗑️ Removing custom dependencies, and when you might need to do this:

So say you've got some general custom dependencies defined in the system or user initialization file, and for one specific project they're just... not it 🙈. You might wanna delete the unneeded ones. A situation where that's desirable: when there are multiple custom dependencies sharing the same from-extension or the same to-extension. In that case latexmk might pick a different one than the one you wanted for that specific project 😭. Example — to nuke any fig → eps rule you'd write:

remove_cus_dep( 'fig', 'eps' );

And if your custom dependencies are a whole complicated mess, you might want a listing of them. Do that with the line:

show_cus_dep();

inside an initialization file ✨.

🧩 Function implementing custom dependency, alternative methods:

So far, all the example functions implementing custom dependencies used the function's argument to specify the base name of the converted file. That method's been around since super old versions of latexmk, and you can find tons of examples of it, like, all over the web 🌐.

But in later versions of latexmk, the internal structure of how its "rules" for the processing steps work — custom dependencies included — got way more powerful. The function implementing a custom dependency runs inside a special context where a bunch of extra variables and subroutines are defined. The publicly documented ones, meant to be long-term stable, are listed below under the heading "Variables and subroutines for processing a rule" 👑.

Examples of their use are in the following examples, all about multiple index files and glossaries 📚.

The only index-file conversion built into latexmk is from an .idx file written on one run of *latex to an .ind file read in on a later run. But with the index.sty package, for example, you can create extra indexes with extensions you configure. latexmk has no idea how to deduce those extensions from the info it has. But you can totes write a custom dependency 💅. For example, if your latex file uses the command \newindex{special}{ndx}{nnd}{Special index}, you'll need to get latexmk to convert files with extension .ndx to .nnd. The most elementary method is to define a custom dependency like this:

add_cus_dep( 'ndx', 'nnd', 0, 'ndx2nnd' );
sub ndx2nnd {
    return system( "makeindex -o \"$_[0].nnd\" \"$_[0].ndx\"" );
}
push @generated_exts, 'ndx', 'nnd';

Notice the extra line compared to earlier examples 👀. That line adds the extensions ndx and nnd to the list of extensions for generated files — so then those extra index files get deleted by clean-up operations 🧹.

But if you have yet more indexes with yet different extensions, like adx and and, then you'd need a separate function for each pair of extensions. Which is, honestly, so annoying 😤. You can use the Run_subst function to simplify the definitions down to a single function:

add_cus_dep( 'ndx', 'nnd', 0, 'dx2nd' );
add_cus_dep( 'adx', 'and', 0, 'dx2nd' );
sub dx2nd {
    return Run_subst( "makeindex -o %D %S" );
}
push @generated_exts, 'ndx', 'nnd', 'adx', 'and';

Or you could instead use:

add_cus_dep( 'ndx', 'nnd', 0, 'dx2nd' );
add_cus_dep( 'adx', 'and', 0, 'dx2nd' );
sub dx2nd {
    return Run_subst( $makeindex );
}
push @generated_exts, 'ndx', 'nnd', 'adx', 'and';

That last example uses the command specification in $makeindex, so any customization you made for the standard index also applies to your extra indexes 🎀.

Similar techniques can be applied for glossaries ✨.

Now, those of you with Makefile experience might be like "wait 😳 the .ndx file gets written during a run of *latex and is always later than the .nnd that was last read in — so the .nnd looks perpetually out-of-date??". Yeah. This situation, circular dependencies, is endemic to latex, and it's one of the issues latexmk is literally programmed to overcome 💪. It examines the contents of the files (via a checksum) and only remakes when the file contents have actually changed. Slay.

And obvs, if you choose to write random data into the .nnd (or the .aux file, etc.) that changes on every new run, then yeah, you're gonna have a problem 🙈. For real experts: check out the %hash_calc_ignore_pattern if you gotta deal with problems like that.

🕰️ Old Method of Defining Custom Dependencies:

In much older versions of latexmk, the only way to define custom dependencies was to directly manipulate the table of custom dependencies. That table lives in the @cus_dep_list array. It's an array of strings, and each string in it holds four items separated by spaces: the from-extension, the to-extension, the "must" item, and the name of the subroutine for the custom dependency. All of those were defined above ☝️.

Here's an example of the old method — it's the code in an RC file to make sure .fig files auto-convert to .eps files:

push @cus_dep_list, "fig eps 0 fig2eps";
sub fig2eps {
    return system( "fig2dev -Lps \"$_[0].fig\" \"$_[0].eps\"" );
}

This method still works, and it's almost equivalent to the code given earlier that used the add_cus_dep subroutine. However, the old method doesn't delete any previous custom-dependency for the same conversion 😬. So the new method is preferable 💅.

---

🌈 ADVANCED CONFIGURATION: SOME EXTRA RESOURCES AND ADVANCED TRICKS

For most purposes, a simple latexmk config along the lines of the examples given is plenty. But sometimes you need something harder 😤. In this section I point out some extra possibilities. Generally, to use these you gotta be fluent in Perl, since that's what's used in the rc files 🐪.

In this section I'll first include a description of a bunch of variables and subroutines that give you, among other things, access to latexmk's internal data structures for handling dependencies. Then I'll describe the hook mechanism, whereby at certain points in the processing latexmk can call user-defined subroutines 🪝.

See also the section DEALING WITH ERRORS, PROBLEMS, ETC. See also the examples in the directory example_rcfiles in the latexmk distributions 👀. Even if none of the examples apply to your case, they might give you useful ideas ✨.

🧠 Variables and subroutines for processing a rule

A step in the processing is called a rule. One way to implement the processing of a rule is with a Perl subroutine. This is always the case for custom dependencies. And for any other rule, you can use a subroutine too — just prefix the command specification with the word internal (see the section FORMAT OF COMMAND SPECIFICATIONS).

When you use a subroutine for processing a rule, all the possibilities of Perl programming are available, obvs 💅. Plus, some of latexmk's internal variables and subroutines are available. The ones listed below are meant to be available to (advanced) users, and their specs will generally stay stable under upgrades. Generally, treat the variables as read-only 🙅: changing their values can have bad consequences, since it's liable to mess up the consistency of what latexmk is doing.

• $rule — This variable holds the name of the rule, as known to latexmk. Note that the exact contents of this variable for a given rule may depend on the version of latexmk.
• $$Pbase — This gives the basename for the rule. Generally it determines the names of generated files. E.g., for a run of *latex, the name of the .log file is the aux directory concatenated with the basename and then .log.

For a *latex rule, the basename is without a directory component. For other rules, it includes the directory component (if any is used).

This (annoying) difference is tied to the different ways the commands latexmk invokes behave when the command line includes a name for a source file that has a directory component 😭. For the *latex commands, the directory of the source file is irrelevant to the directory component of the generated files — that instead is determined by the values in the -aux-directory and/or -output-directory options.

In contrast, lots of other programs (e.g., biber, bibtex) put their generated files in the same directory as the source file, just with a changed extension 🎀.

Note the double dollar signs: in Perl-speak, $Pbase is a reference to a variable that holds the basename. That second dollar sign dereferences the reference so you actually get the value out. 🫶 (A reference is used kinda like a pointer, and the P — for "pointer" — at the front of the variable name is a whole latexmk convention meaning "bestie, this one's a reference variable".)

• $$Pdest — gives you the name of the main output file, if there is one. Double dollar signs, always. ✨
• $$Psource — gives you the name of the primary source file. Again: double dollar signs. 💖
• add_hook( <stack_name>, <subroutine> ) — see the section Hooks for more deets. This adds the subroutine from the second argument onto latexmk's stack of hooks, the one named by the stack name. It returns 1 on success and zero otherwise (like, say, if that hook stack doesn't exist). The subroutine can be given as a reference to the subroutine, as in

add_hook( 'after_xlatex_analysis', mmz_analyze )

given that the subroutine mmz_analyze has been defined in the rc file. Or the subroutine can be given as a string whose value is the name of the subroutine, e.g.

add_hook( 'after_xlatex_analysis', 'mmz_analyze' )

And in the simple cases, the subroutine can just be an anonymous subroutine defined right there in the call to add_hooks,

add_hook( 'after_main_pdf', sub{ print "TEST\n"; return 0; } );

Observe that on success the subroutine should return 0 (exactly like a call to Perl's system subroutine), so normally you'd code that explicitly. If a hook subroutine returns a non-zero value, latexmk treats that as an error condition. 😭

• ensure_path( var, values ...) — the first parameter is the name of one of the system's environment variables for search paths. The remaining parameters are values that should be in that variable. For each of the value parameters, if it isn't already in the variable, it gets prepended to the variable — and in that case the environment variable is created if it doesn't already exist. For separating the values, whatever character is appropriate for your operating system gets used — see the configuration variable $search_path_separator. Example:

ensure_path( 'TEXINPUTS', './custom_cls_sty_files//' );

(In this example, the trailing '//' is documented by TeX systems to mean that *latex searches for files in the specified directory and in all subdirectories. 👑) Technically, ensure_path works by setting Perl's variable $ENV{var}, where var is the name of the target variable. The changed value is then passed as an environment variable to any invoked programs. 💅

• pushd( path ), popd() — these subroutines are for when you need to temporarily change the working directory, as in

pushd( 'some_directory' );
... Processing done with 'some_directory' as the working directory
popd()

They do exactly the same thing as the commands of the same names in operating system shells like bash on Unix and cmd.exe on Windows. 🐚

• rdb_add_generated( file, ... ) — this subroutine is to be used in the context of a rule, that is, from within a subroutine that's carrying out the processing of a rule. That's the case for the subroutine implementing a custom dependency, or for the subroutine invoked by using the "internal" keyword in the command specification like the one in the variable $latex. Its arguments are a sequence of filenames that get generated during the running of the rule. Those names might come from an analysis of the results of the run (like, from a log file), or from knowledge of properties of that specific rule. Calling rdb_add_generated with these filenames makes sure those files are flagged as generated by the rule in latexmk's internal data structures. Basically, if the files have already been flagged as generated, no action is taken. A main purpose of using this subroutine is the situation where a generated file is also the source file for some rule, so that latexmk can correctly link the dependency information in its network of rules. 🔗

Note: unlike some other subroutines in this section, there is no argument for a rule for rdb_add_generated. Instead, the subroutine is to be invoked during the processing of a rule, when latexmk has set up an appropriate context (i.e., appropriate variables). In contrast, subroutines with a rule argument can be used also outside a rule context.

• rdb_ensure_file( $rule, file ) — this subroutine makes sure the given file is among the source files for the specified rule. It's typically used when, during the processing of a rule, it's known that some particular extra file is among the dependencies latexmk should know about, but its default methods don't find that dependency. Almost always the first argument is the name of the rule currently being processed, so it's then appropriate to specify it as $rule. For examples of its use, see some of the files in the directory example_rcfiles of latexmk's distribution. Currently the cases that use this subroutine are bib2gls-latexmkrc, exceltex_latexmkrc and texinfo-latexmkrc. These illustrate typical cases where latexmk's normal processing fails to detect certain extra source files. 👀

Note that rdb_ensure_file only has one filename argument, unlike other subroutines in this section. If you want to apply its action to multiple files, you'll need one call to rdb_ensure_file for each file.

• rdb_ensure_files_here( file, ... ) — like subroutine rdb_ensure_files, except that (a) it assumes the context is of a rule, and the files are to be added to the source list for that rule; and (b) multiple files are allowed. 🌸
• rdb_remove_files( $rule, file, ... ) — this subroutine removes one or more files from the dependency list for the given rule.
• rdb_remove_generated( file, ... ) — this subroutine is to be used in the context of a rule, that is, from within a subroutine that's carrying out the processing of a rule. It performs the opposite action to rdb_add_generated. Its effect is to make sure the given filenames are not listed in latexmk's internal data structures as being generated by the rule.
• rdb_list_source( $rule ) — this subroutine returns the list of source files (i.e., the dependency list) for the given rule. 🎀
• rdb_set_source( $rule, file, ... )
• rdb_set_source( $rule, @files ) — this subroutine sets the dependency list for the given rule to be the specified files. Files that are already in the list keep their information unchanged. Files that weren't in the list get added to it. And files that were in the previous dependency list but aren't in the newly specified list of files get removed from the dependency list. ✨
• Run_subst( command_spec ) — this subroutine runs the command specified by command_spec. That specification is a string in the format listed in the section "Format of Command Specifications". A big important action of Run_subst is making substitutions of placeholders, e.g. %S and %D for source and destination files; these get substituted in before the command is run. On top of that, the command after substitution gets printed to the screen unless latexmk is running in silent mode. 🖨️
• test_gen_file_time ( <file> ) — this subroutine is used in the context of a rule. It returns true or false depending on whether or not a file of the given name both exists and was generated in the latest run of the rule. If the subroutine returns false but the file does exist, then that file is a leftover from a previous run. 👻

The test for a file being generated on the current run is whether the modification time of the file is at least as recent as the time the run of the rule was started. An allowance for the granularity of the values of modification time on file systems is made. See the description of the variable $filetime_causality_threshold for details.

On top of that, latexmk makes allowance for the possibility that files are hosted on a different computer than the one running latexmk, and that the system clock times on those two computers are mismatched. Latexmk automatically detects (and reports) any significant mismatch, and corrects for it. 🕰️

---

🎀 Coordinated Setting of Commands for *latex 🎀

To set all of $dvilualatex, $hilatex, $latex, $pdflatex, $lualatex, and $xelatex to one common pattern, you can use one of these subroutines: std_tex_cmds, alt_tex_cmds, and set_tex_cmds. 🫶

To get the standard commands, use

&std_tex_cmds;

This results in $latex = 'latex %O %S', and similarly for $dvilualatex, $hilatex, $pdflatex, $lualatex, and $xelatex. Note the ampersand in the invocation — that's how Perl knows a subroutine is being called. (Using this subroutine lets you override previous redefinitions of the $latex, etc. variables, which might have happened in an earlier-read rc file.)

To be able to use the string provided by the -pretex option (if any), you can use

&alt_tex_cmds;

This results in $latex = 'latex %O %P', etc. Again, note the ampersand in the invocation; that indicates to Perl that a subroutine is being called. 💅

A more general way of specifying the variables is using

set_tex_cmds( 'CMD_SPEC' );

Here CMD_SPEC is the command line without the program name. This results in $latex = 'latex CMD_SPEC', and similarly for $pdflatex, etc. (An ampersand preceding the subroutine name isn't necessary here, since the parentheses show Perl that a subroutine is being invoked.) 👑

An example that provides the --interaction=batchmode option to the *latex commands would be

set_tex_cmds( '--interaction=batchmode %O %S' );

This results in $latex = 'latex --interaction=batchmode %O %S ', etc. Note that when '%O' appears after the added option, as it does here, options provided on the command line to latexmk can override the supplied one. 🔥

Okay so if you want a more general command line, you can drop the placeholder %C into CMD_SPEC and it's literally doing the most. 💫 The %C gets substituted by the basic name of the command — like whichever of latex, pdflatex, etc. is the appropriate one in that moment. (And yes bestie, you can use %C more than once. It's not a one-time thing. 🙈)

So say you want to run the dev / pre-release versions of latex and friends, the ones named latex-dev, pdflatex-dev, etc. — you'd write this:

set_tex_cmds( '%C-dev %O %S' );

And that gives you $latex = 'latex-dev %O %S', etc. ✨ (Those pre-release programs like latex-dev are provided in the current distributions of TeXLive and MiKTeX, so you're not out here on your own. 🫶)

---

🪝 Hooks 🪝

Latexmk lets you arrange for user-defined subroutines to get called at certain points during processing. It's giving customization era. 💅 You can use them to configure behavior and actions that go beyond latexmk's normal behavior. For a genuinely good example of how to use them to bend latexmk's behavior to fit particular packages, go look at the file memoize_latexmkrc in the example_rcfiles subdirectory of the latexmk distribution. (In a standard TeXLive installation, that subdirectory lives at texmf-dist/doc/support/latexmk/.) 🎀

The hook mechanism is complementary to the method of redefining command strings like $pdflatex etc. The two methods have overlapping domains of usefulness, so it's not a this-or-that situation.

Heads up fr fr: the hook mechanism was newly made public in v. 4.84 of latexmk. It is subject to change and improvement as experience is gained. So like… don't build your whole personality on it just yet. 😭

The hooks live in named hook stacks, and a hook subroutine gets added to a given stack by latexmk's add_hook subroutine (documented above). Here are the currently available stacks, listed in the approximate order you'll encounter them while processing a document:

• before_xlatex — The subroutines in this hook stack are called just before a *latex program is run.
• after_xlatex — The subroutines in this hook stack are called after a *latex program is run. Before the subroutines are called, latexmk has already done some immediate postprocessing, e.g., moving the generated pdf file from the aux directory to the output directory when $emulate_aux is set to 1. 🚚
• after_xlatex_analysis — The subroutines in this hook stack are called after latexmk has done its dependency analysis following a run of a *latex program. Subroutines in this stack are a genuinely useful way to add items to the dependency information associated with particular packages — the stuff latexmk doesn't automatically deal with. 👑
• after_main_pdf — The subroutines in this hook stack are called after one of the rules that creates the document's pdf file. (This covers any of pdflatex, lualatex, dvipdf, ps2pdf, xdvipdfmx.) 🔥
• cleanup — The subroutines in this hook stack are called whenever latexmk is about to do a cleanup operation. You can use them, for example, to tailor the deleted files to the peculiarities of particular packages when latexmk's general mechanisms for specifying files to be deleted are too inflexible. These subroutines are called before latexmk does any of its own file deletion, which means the hook subroutines have access to all the generated files that give package-specific information. 🗂️
• cleanup_extra_full — The subroutines in this hook stack are called in addition to the ones in the cleanup stack, whenever a full cleanup operation is to be done (i.e., one that includes the pdf, ps etc files). They're called immediately after those in the cleanup stack, but still before latexmk does any of its own file deletion.

(Any other stacks defined in latexmk.pl but not listed above are to be regarded as experimental and subject to change. You have been warned, bestie. 💀)

Each subroutine should return 0 on success and a non-zero value on failure. This matches the convention used for running programs, e.g., by Perl's system subroutine, and the matching convention used for subroutines for custom dependencies in latexmk. ✅

For most of the hook stacks, the subroutines are called in the context of a rule, with variables like $rule defined. But some hook stacks — like the cleanup ones — are called from outside any rule, and in those cases latexmk adjusts the relevant variables to refer to the overall task (i.e., of processing a particular main .tex file). 🌸

---

Advanced configuration: Using latexmk with make

This section is targeted only at advanced users who use the make program for complex projects, like software development, where the dependencies are specified by a Makefile. 🛠️

So here's the deal. The basic task of latexmk is to run the appropriate programs to make a viewable version of a LaTeX document. But the usual make program is just not suited to this purpose, for at least two reasons. First: using LaTeX involves circular dependencies (e.g., via .aux files), and those cannot be handled by the standard make program. Second: in a large document, the set of source files can change quite frequently, particularly with included graphics files; in that situation, keeping a Makefile manually updated is inappropriate and error-prone, especially when the dependencies can be determined automatically. Latexmk solves both of these problems robustly. 💪

So for many standard LaTeX documents, latexmk can be used by itself without the make program. In a complex project it simply needs to be suitably configured. A standard configuration would be to define custom dependencies to make graphics files from their source files (e.g., as created by the xfig program). Custom dependencies are latexmk's equivalent of pattern rules in Makefiles. 🎯

Nevertheless, there are projects for which a Makefile is appropriate, and it's useful to know how to use latexmk from a Makefile. A typical example would be generating documentation for a software project. Potentially the interaction with the rest of the rules in the Makefile could be quite complicated — for example, if some of the source files for a LaTeX document are generated by the project's software. 😵‍💫

In this section, I give a couple of examples of how latexmk can be usefully invoked from a Makefile. The examples use specific features of current versions of GNU make, which is the default on both Linux and macOS systems. They may need modifications for other versions of make.

The simplest method is simply to delegate all the relevant tasks to latexmk, as is suitable for a straightforward LaTeX document. For this, a suitable Makefile is like:

    .PHONY : FORCE_MAKE
    all : try.pdf
    %.pdf : %.tex FORCE_MAKE
        latexmk -pdf -dvi- -ps- $<

(Note: the last line must be introduced by a tab for the Makefile to function correctly!) 🚨

Naturally, if making try.pdf from its associated LaTeX file try.tex were the only task to be performed, a direct use of latexmk without a Makefile would normally be better. The benefit of using a Makefile for a LaTeX document would be in a larger project, where lines such as the above would only be a small part of a larger Makefile.

The above example has a pattern rule for making a .pdf file from a .tex file, and it's defined to use latexmk in the obvious way. There's a conventional default target named "all", with a prerequisite of try.pdf. So when make is invoked, by default it makes try.pdf. The only complication is that there may be many source files beyond try.tex, but these aren't specified in the Makefile, so changes in them will not by themselves cause latexmk to be invoked. Instead, the pattern rule is equipped with a "phony" prerequisite FORCE_MAKE; this has the effect of causing the rule to be always out-of-date, so that latexmk is always run. It's latexmk that decides whether any action is needed, e.g., a rerun of pdflatex. Effectively the Makefile delegates all decisions to latexmk, while make has no knowledge of the list of source files except for the primary LaTeX file for the document. If there are, for example, graphics files to be made, these must be made by custom dependencies configured in latexmk. 🦋

But something better is needed in more complicated situations — for example, when the making of graphics files needs to be specified by rules in the Makefile. To do this, one can use a Makefile like the following:

     TARGETS = document1.pdf document2.pdf
     DEPS_DIR = .deps
     LATEXMK = latexmk -recorder -use-make -deps \
           -e 'warn qq(In Makefile, turn off custom dependencies\n);' \
           -e '@cus_dep_list = ();' \
           -e 'show_cus_dep();'
     all : $(TARGETS)
     $(foreach file,$(TARGETS),$(eval -include $(DEPS_DIR)/$(file)P))
     $(DEPS_DIR) :
            mkdir $@
     %.pdf : %.tex
            if [ ! -e $(DEPS_DIR) ]; then mkdir $(DEPS_DIR); fi
            $(LATEXMK) -pdf -dvi- -ps- -deps-out=$(DEPS_DIR)/$@P $<
     %.pdf : %.fig
            fig2dev -Lpdf $< $@

(Again, the lines containing the commands for the rules should be started with tabs.) 🚨

This example was inspired by how GNU automake handles automatic dependency tracking of C source files. 👑

After each run of latexmk, dependency information is put in a file in the .deps subdirectory. The Makefile causes these dependency files to be read by make, which now has the full dependency information for each target .pdf file. To make things less trivial it is specified that two files document1.pdf and document2.pdf are the targets. The dependency files are .deps/document1.pdfP and .deps/document2.pdfP. 📁

There is now no need for the phony prerequisite for the rule to make .pdf files from .tex files. But I've added a rule to make .pdf files from .fig files produced by the xfig program; these are commonly used for graphics insertions in LaTeX documents. Latexmk is arranged to output a dependency file after each run. It's given the -recorder option, which improves its detection of files generated during a run of pdflatex; such files should not be in the dependency list. The -e options are used to turn off all custom dependencies, and to document this. Instead the -use-make is used to delegate the making of missing files to make itself. ✨

Suppose in the LaTeX file there is a command \includegraphics{graph}, and an xfig file "graph.fig" exists. On a first run, pdflatex reports a missing file, named "graph". Latexmk succeeds in making "graph.pdf" by calling "make graph.pdf", and after completion of its work, it lists "fig.pdf" among the dependents of the file latexmk is making. Then let "fig.fig" be updated, and then let make be run. make first remakes "fig.pdf", and only then reruns latexmk. 🔄

Thus we now have a method by which all the subsidiary processing is delegated to make. 💅

🫧 Escaping of characters in dependency lists 🫧

okay so listen — there are certain special characters that have to be escaped when names of files and directories containing them show up in a dependency list that a make program is gonna read. and bestie, the vibe here is: generally, such special characters are best avoided. like, just don't, it's giving chaos 💀

By default, latexmk does no escaping of this kind, and you, the user, will have to arrange to deal with the issue separately if those relevant special characters are actually being used. ngl that's on you. And heads up — the rules for escaping depend on which make program is used, and on its version. so it's not even one fixed answer, it's giving ✨it depends✨.

One special case tho is spaces, because spaces are particularly prevalent, notably in standard choices of name for a user's home directory 😭. So latexmk does provide an option to escape spaces. See the option -deps_escape=... and the variable $deps_escape for details. iykyk 🎀

---

🌈 NON_ASCII CHARACTERS IN FILENAMES, RC FILES, ETC 🌈

Modern operating systems and file systems allow non-ASCII characters in the names of files and directories that encompass the full Unicode range. Mostly, latexmk deals with these correctly ✨. However — and this is the part where we hold hands 🫶 — there are some situations in which there are problems, notably on Microsoft Windows. Prior to version 4.77, latexmk had problems with non-ASCII filenames on Windows, even though there were no corresponding problems on macOS and Linux. These problems are corrected in the present version. slay 💅

DETAILS TO BE FILLED IN

---

👀 SEE ALSO 👀

latex(1), bibtex(1), lualatex(1), pdflatex(1), xelatex(1).

---

💀 BUGS (SELECTED) 💀

Sometimes a viewer (gv) tries to read an updated .ps or .pdf file after its creation is started but before the file is complete. the audacity honestly 🙈 Work around: manually refresh (or reopen) display. Or use one of the other previewers and update methods. periodt.

(The following isn't really a bug, but concerns features of previewers.) Preview continuous mode only works perfectly with certain previewers:

• Xdvi on UNIX/Linux works for dvi files.
• Gv on UNIX/Linux works for both postscript and pdf.
• Ghostview on UNIX/Linux needs a manual update (reopen); it views postscript and pdf.
• Gsview under MS-Windows works for both postscript and pdf, but only reads the updated file when its screen is refreshed.
• Acroread under UNIX/Linux views pdf, but the file needs to be closed and reopened to view an updated version.
• Under MS-Windows, acroread locks its input file and so the pdf file cannot be updated. 😭 (Remedy: configure latexmk to use sumatrapdf instead.)

---

🫶 THANKS TO 🫶

Authors of previous versions. Many users with their feedback, and especially David Coppit (username david at node coppit.org) who made many useful suggestions that contributed to version 3, and Herbert Schulz. (Please note that the e-mail addresses are not written in their standard form to avoid being harvested too easily.) iconic behaviour honestly 👑

---

👑 AUTHOR 👑

Current version, by John Collins (Version 4.88). Report bugs etc to his e-mail (jcc8 at psu.edu).

Released version can be obtained from CTAN: <http://www.ctan.org/pkg/latexmk/>, and from the author's website <https://www.cantab.net/users/johncollins/latexmk/>.

Modifications and enhancements by Evan McLean (Version 2.0).

Original script called "go" by David J. Musliner (RCS Version 3.2).

---

and that's a wrap on the whole LATEXMK(1) page bestie 🎀✨ this one's from 9 March 2026, and the version we've been stanning all along is LATEXMK(1) — go forth and compile, you absolute main character 🌸💅🦋