neulab/tldr huggingface dataset:
$pdf_mode [0] If zero, do NOT generate a pdf version of the document.  If equal to 1, generate a pdf version of the document using pdflatex.  If equal to 2, generate a pdf version of the document from the ps file, by using the command specified by the $ps2pdf variable.  If equal to 3, generate a pdf version of the document from the dvi file, by using the command specified by the $dvipdf variable.
Equivalent to the -pdf-, -pdf, -pdfdvi, -pdfps options.
$pdflatex ["pdflatex %O %S"] The LaTeX processing program in a version that makes a pdf file instead of a dvi file.
An example of the use of this variable is to arrange for lualatex, xelatex or some similar program to be used instead of pdflatex. Note that lualatex and xelatex only produce .pdf files (and not .dvi), so to use them you will also need to turn on production of .pdf files, and to turn off the production of .dvi (and .ps) files, either by command line options or by suitable settings in a configuration file. Thus to use lualatex, the following settings are appropriate:
$pdflatex = "lualatex %O %S"; $pdf_mode = 1; $postscript_mode = $dvi_mode = 0;
To use xelatex, the corresponding settings are:
$pdflatex = "xelatex %O %S"; $pdf_mode = 1; $postscript_mode = $dvi_mode = 0;
Another use of the same variable is to add certain options to the command line for the program, e.g.,
$pdflatex = "pdflatex --shell-escape %O %S";
%pdflatex_input_extensions This variable specifies the extensions tried by latexmk when it finds that a pdflatex run resulted in an error that a file has not been found, and the file is given without an extension.  This typically happens when LaTeX commands of the form \input{file} or \includegraphics{figure}, when the relevant source file does not exist.
In this situation, latexmk searches for custom dependencies to make the missing file(s), but restricts it to the extensions specified by the variable %pdflatex_input_extensions.  The default extensions are 'tex', 'pdf', 'jpg, and 'png'.
(For Perl experts: %pdflatex_input_extensions is a hash whose keys are the extensions.  The values are irrelevant.)  Two subroutines are provided for manipulating this and the related variable %latex_input_extensions, add_input_ext and remove_input_ext.  They are used as in the following examples are possible lines in an initialization file:
remove_input_ext( 'pdflatex', 'tex' );
removes the extension 'tex' from pdflatex_input_extensions
add_input_ext( 'pdflatex', 'asdf' );
add the extension 'asdf to pdflatex_input_extensions.  (Naturally with such an extension, you should have made an appropriate custom dependency for latexmk, and should also have done the appropriate programming in the LaTeX source file to enable the file to be read.  The standard extensions are handled by pdflatex and its graphics/graphicx packages.)
$pdflatex_silent_switch ["-interaction=batchmode"] Switch(es) for the pdflatex program (specified in the variable $pdflatex when silent mode is on.
$pdf_previewer ["start acroread %O %S"] The command to invoke a pdf-previewer.
On MS-WINDOWS, the default is changed to "cmd /c start """; under more recent versions of Windows, this will cause to be run whatever command the system has associated with .pdf files.  But this may be undesirable if this association is to acroread -- see the notes in the explanation of the -pvc option.]
On OS-X the default is changed to "open %S", which results in OS-X starting up (and detaching) the viewer associated with the file. By default, for pdf files this association is to OS-X's preview, which is quite satisfactory.
WARNING:  Problem under MS-Windows: if acroread is used as the pdf previewer, and it is actually viewing a pdf file, the pdf file cannot be updated.  Thus makes acroread a bad choice of previewer if you use latexmk's previous-continuous mode (option -pvc) under MS-windows.  This problem does not occur if, for example, SumatraPDF or gsview is used to view pdf files.
$pdf_update_command [""] When the pdf previewer is set to be updated by running a command, this is the command that is run.  See the information 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 information on the variable $dvi_update_method for the codes.  (Note that information needs be changed slightly so that 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:
$pdf_previewer = "start xpdf -remote %R %O %S"; $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.
$pdf_update_signal [Under UNIX: SIGHUP, which is a system-dependent value] The number of the signal that is sent to the pdf viewer when it is updated by sending a signal -- see the information 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 (2nd word in line) is correct for Solaris 2.6 and Linux.  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.
$preview_continuous_mode [0] If nonzero, run a previewer to view the document, and continue running latexmk to keep .dvi up-to-date.  Equivalent to the -pvc option.  Which previewer is run depends on the other settings, see the command line options -view=, and the variable $view.
$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 lpr.  Equivalent to the -p option.  This is recommended not to be set from an RC file, otherwise you could waste lots of paper.
$print_type = ["auto"] Type of file to printout: 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 is an already running previewer, and to find the process ID (needed if latexmk needs 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 --width 200 -f -u $ENV{USER}" under linux, "ps -ww -u $ENV{USER}" under darwin (Macintosh OS-X), and "ps -f -u $ENV{USER}" under other operating systems (including other flavors of UNIX).  In these specifications "$ENV{USER}" is substituted by the username.
$ps2pdf ["ps2pdf %O %S %D"] Command to convert ps to pdf file.
$ps_filter [empty] The postscript file filter to be run on the newly produced postscript file before other processing.  Equivalent to specifying the -pF option.
$ps_previewer ["start gv %O %S", but start %O %S under MS-WINDOWS] The command to invoke a ps-previewer.  (The default under MS- WINDOWS will cause to be run whatever command the system has associated with .ps files.)
Note that gv could be used with the -watch option updates its display whenever the postscript file changes, whereas ghostview does not.  However, different versions of gv have slightly different ways of writing this option.  You can configure this variable appropriately.
WARNING: Linux systems may have installed one (or more) versions of gv under different names, e.g., ggv, kghostview, etc, but perhaps not one called gv.
$ps_previewer_landscape ["start gv -swap %O %S", but start %O %S under MS-WINDOWS] The command to invoke 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 is run.  See the information for the variable $ps_update_method.
$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 information on the variable $dvi_update_method for the codes.  (Note that information needs be changed slightly so that for the value 4, to run a command to do the update, the command is specified by the variable $ps_update_command, and for the value 2, to specify 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 is sent to the pdf viewer when it is updated by sending a signal -- see $ps_update_method.  The default value is the one appropriate for gv on a UNIX system.
$pvc_view_file_via_temporary [1] The same as $always_view_file_via_temporary, except that it only applies in preview-continuous mode (-pvc option).
$quote_filenames [1] This specifies whether substitutions for placeholders in command specifications (as in $pdflatex) are surrounded by 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 used by latexmk is tested to work correctly under UNIX systems (including Linux and Mac OS-X) and under MS- Windows.  It allows the use of filenames containing special characters, notably spaces.  (But note that many versions of LaTeX and PdfLaTeX 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.)
$recorder [0] Whether to use the -recorder option to latex and pdflatex. Use of this option results in a file of 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 or pdflatex.
It is generally recommended to use this option (or to configure the $recorder variable to be on.)  But it only works if (pdf)latex supports the -recorder option, which is true for most current implementations
Note about the name of the .fls file: Most implementations of (pdf)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 (pdf)latex.
[Comment to technically savvy readers: (pdf)latex doesn't actually need the modified search path, because it corrects it internally. 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 OS-X) 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 are not in the MSWin, Linux, OS-X, Unix collection.)
$silence_logfile_warnings [0] Whether after a run of (pdf)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 (pdf)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.  This is subject to a minimum of one second delay, except that zero delay is also allowed.
A value of exactly 0 gives no delay, and typically results in 100% CPU usage, which may not be desirable.
$texfile_search [""] This is an obsolete variable, replaced by the @default_files variable.
For backward compatibility, if you choose to set $texfile_search, it is 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 OS-X), 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 or pdflatex, 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.
$view ["default"] Which kind of file is to be previewed if a previewer is used.  The possible values are "default", "dvi", "ps", "pdf".  The value of "default" means that the "highest" of the kinds of file generated is to be used (among dvi, ps and pdf).
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.
The old method of configuring latexmk was to directly manipulate the @cus_dep_list array that contains information defining the custom dependencies.  This method still works.  But now there are 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 custom dependency is a list of rules, each of which is specified as follow:
from extension: The extension of the file we are converting from (e.g. "fig").  It is specified without a period.
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.
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.
It is invoked whenever latexmk detects that a run of latex/pdflatex 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 rule.  If it does, then whenever the destination file (the one with the to-extension) is out-of-date with respect to the corresponding source file.
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 other item in each custom-dependency rule labeled "must" above specifies how the rule should be applied when the source file fails to exist.
A simple and typical example of code in an initialization rcfile 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.
If the return value of the subroutine is non-zero, then latexmk will assume an error occurred during the execution of the subroutine.  In the above example, no explicit return value is given, and instead the return value is the value returned by the last (and only) statement, i.e., the invocation of system, which returns the value 0 on success.
If you use pdflatex instead of latex, then you will probably prefer to convert your graphics files to pdf format, in which case you would replace the above code in an initialization file by
add_cus_dep( 'fig', 'pdf, 0, 'fig2pdf' ); sub fig2pdf { system( "fig2dev -Lpdf \"$_[0].fig\" \"$_[0].pdf\"" ); }
Note 1: In the command lines given in the system commands in the above examples, double quotes have been inserted around the file names (implemented by '\"' in the Perl language).  They immunize the running of the program against special characters in filenames.  Very often these quotes are not necessary, i.e., they can be omitted.  But it is normally safer to keep them in.  Even though the rules for quoting vary between operating systems, command shells and individual pieces of software, the quotes in the above examples do not cause problems in the cases I have tested.
Note 2: One case in which the quotes are important is when the files are in a subdirectory and your operating system is Microsoft Windows.  Then the separator character for directory components can be either a forward slash '/' or Microsoft's more usual backward slash Â´\'.  Forward slashes are generated by latexmk, to maintain its sanity from software like MiKTeX that mixes both directory separators; but their correct use normally requires quoted filenames.  (See a log file from a run of MiKTeX (at least in v. 2.9) for an example of the use of both directory separators.)
If you have some general custom dependencies defined in the system or user initialization file, you may find that for a particular project they are undesirable.  So you might want to delete the unneeded ones.  For example, you remove any "fig" to "eps" rule by the line
remove_cus_dep( 'fig', 'eps' );
If you have complicated sets of custom dependencies, you may want to get a listing of the custom dependencies.  This is done by using the line
show_cus_dep();
in an initialization file.
Another example of a custom dependency overcomes a limitation of latexmk concerning index files.  The only index-file conversion built-in to latexmk is from an ".idx" file written on one run of latex/pdflatex to an ".ind" file to be read in on a subsequent run.  But with the index.sty package you can create extra indexes with extensions that you configure. Latexmk does not know how to deduce the extensions from the information it has.  But you can easily write a custom dependency.  For example if your latex file uses the command "\newindex{special}{ndx}{nnd}{Special index}" you will need to convert files with the extension .ndx to .nnd. The following lines in an initialization RC file will cause this to happen:
add_cus_dep('ndx', 'nnd', 0, 'makendx2nnd'); sub makendx2nnd { system( "makeindex -o \"$_[0].nnd\" \"$_[0].ndx\"" ); }
(You will need to modify this code if you use filenames with spaces in them, to provide correct quoting of the filenames.)
Those of you with experience with Makefiles, will undoubtedly be concerned that the .ndx file is written during a run of latex/pdflatex and is always later than the .nnd last read in.  Thus the .nnd appears to be perpetually out-of-date.  This situation, of circular dependencies, is endemic to latex, and latexmk in its current version works correctly with circular dependencies.  It examines the contents of the files (by use of an md5 checksum), and only does a remake when the file contents have actually changed.
Of course if you choose to write random data to the .nnd (or and .aux file, etc) that changes on each new run, then you will have a problem. For real experts: See the %hash_cal_ignore_pattern if you have to deal with such problems.
Glossaries can be dealt with similarly.
In previous versions of latexmk, the only method of defining custom dependencies was to directly manipulate the table of custom dependencies. This is contained in the @cus_dep_list array.  It is an array of strings, and each string in the array has four items in it, each separated by a space, the from-extension, the to-extension, the "must" item, and the name of the subroutine for the custom dependency.  These were all defined above.
An example of the old method of defining custom dependencies is as follows. It is the code in an RC file to ensure automatic conversion of .fig files to .eps files:
push @cus_dep_list, "fig eps 0 fig2eps"; sub fig2eps { system( "fig2dev -Lps \"$_[0].fig\" \"$_[0].eps\"" ); }
This method still works, and is equivalent to the earlier code using the add_cus_dep subroutine, except that it doesn't delete any previous custom-dependency for the same conversion.  So the new method is preferable.
USING latexmk WITH make This section is targeted only at advanced users who use the make program for complex projects, as for software development, with the dependencies specified by a Makefile.
Now the basic task of latexmk is to run the appropriate programs to make a viewable version of a LaTeX document.  However, the usual make program is not suited to this purpose for at least two reasons.  First is that the use of LaTeX involves circular dependencies (e.g., via .aux files), and these cannot be handled by the standard make program.  Second is that in a large document the set of source files can change quite frequently, particularly with included graphics files; in this 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.
Thus 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 is useful to know how to use latexmk from a Makefile.  A typical example would be to generate 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 OS-X 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 be 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 is defined to use latexmk in the obvious way.  There is 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 is 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 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 specificed 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 have 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 is 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.
latex(1), bibtex(1).
Sometimes a viewer (gv) tries to read an updated .ps or .pdf file after its creation is started but before the file is complete.  Work around: manually refresh (or reopen) display.  Or use one of the other previewers and update methods.
(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.)
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 by worms and viruses.)
Current version, by John Collins (username jcc8 at node psu.edu). (Version 4.41).
Released version can be obtained from CTAN: <http://www.ctan.org/tex- archive/support/latexmk/>, and from the author's website <http://www.phys.psu.edu/~collins/software/latexmk/>. Modifications and enhancements by Evan McLean (Version 2.0) Original script called "go" by David J. Musliner (RCS Version 3.2)
SPI(5)                            File Formats                            SPI(5)
spi - Alliance parser and driver for Spice netlist.
This software belongs to the  ALLIANCE CAD SYSTEM developed by the ASIM team at LIP6 laboratory of UniversitÃ© Pierre et Marie CURIE, in Paris, France.
Web : http://asim.lip6.fr/recherche/alliance/ E-mail : alliance-users@asim.lip6.fr
The description of a netlist foo must be contained  in a .SUBCKT of a file named foo.spi. This description can include others .SUBCKT that must be in the same file or files included with the command .INCLUDE in the source file.
Recognized elements are :
Resistances
Capacitances
MOS  transistors.
Others elements are not considered.
Nodes can be either numbered or nameed. It's possible to assign a name to a node which is designated by a number with the directive
* NET number = name
in the .SUBCKT. The word NET can be replaced by positioning the environment variable MBK_SPI_NETNAME. Names are used to named the signals and the connectors in the LOFIG.
On the .SUBCKT interface, nodes of the same name followed by a period and a number are considered to be on the net, even if no connected in the circuit. For example :
.SUBCKT nand2 in out out.1 out.2 vss vdd out.3
The nodes out, out.1, out.2 and out.3 are considered to be the same signal of the Alliance LOFIG. This feature can be turned off if the environment variable MBK_SPI_MERGE is set, and the period can be replaced by another character with the environment variable MBK_SPI_SEPAR.
No particular information is needed to build a LOFIG from a .SUBCKT, the parser rebuild all signals, even they contains many resistances and capacitances. If names are not provided, the parser will create then in order to provide a valid lofig.
The driver creates a Spice netlist of the LOFIG passed as a parameter. The file contain a single .SUBCKT representing the figure and commands .INCLUDE with name of instances contained in the LOFIG.  Nodes are number named with the directive * NET, or strings, depending on MBK_SPI_NAMEDNODES. A comment at the beginning of the file represents the interface of the LOFIG. This comment is not used by the parser.
Environment variable considered are
MBK_SPI_MODEL
MBK_SPI_NETNAME
MBK_SPI_NAMEDNODES
The parser load all .SUBCKT in memory, even those in files included with the command .INCLUDE until the required LOFIG is loaded. For each .SUBCKT loaded, the parser build the equipotentials with both nodes of resistances on the same net and both nodes of capacitances on differents net unless more information is given. The RCN library is used to handle resistances and capacitances.
As the LOWIRE can contain a resistance and a capacitance, the parser groups a resistance and two capacitances in a single LOWIRE if the following conditions are met :
The resistance is named 'name' and the two capacitances are named 'name1' and 'name2'
The two capacitances must have the same value
The two capacitances must be between the net of the resistance and VSS.
The driver supports this feature.
MBK_SPI_SEPAR
MBK_SPI_MERGE
MBK_SPI_FILE
MBK_SPI_VERBOSE
MBK_SPI_ONE_NODE_NORC
MBK_SPI_NO_AFF_UNK
File name where transistors models are described. Syntax for file is : MODELNAME N|P [FAST] [HVIO] Blank lines are allowed, and line comment begin with a '#'.
Comment used to name the nodes. Default is NET.
Character used to separate a name from a node number on the interface of the .SUBCKT. The parser considers nodes of the same name to be on the same equipotential. Default is '.'.
MBK_SPI_NOMERGE
If this variable is set, the parser does not merge interface nodes of the same name, but different number, on the same equipotential.
If this variable is set, the name of the files opened are displayed on the error output.
If this variable is set, display debug various information on the error output.
If this variable is set, an RCN view is not created for a net containing only one node.
Default behaviour of Spice parser is to display an error message when an unknown element is read in the input file. Setting this variable prevent this display. Usefull when file contain command for Spice simulator.
When this environment variable is set, spice netlist's nodes are named using one of the following convention, if signal name is set or no, or if signal has an RCN view :
"SIGNAL NAME" $MBK_SEPAR "RCN NODE"
"SIGNAL NAME"
SIG "SIGNAL INDEX" $MBK_SEPAR "RCN NODE"
SIG "SIGNAL INDEX"
$MBK_SEPAR is a single character defined by a environment variable with the same name.
This is an example of a file generated by the Spice driver.
* Spice description of gxor * Spice driver version 700 * Date ( dd/mm/yyyy hh:mm:ss ): 29/03/1999 at 17:43:53
* INTERF a b s vdd vdd vdd vdd vss vss vss vss
.INCLUDE mx2_y.spi .INCLUDE ndrvp_y.spi
.subckt gxor 24 42 49 52 53 61 54 63 64 71 72 * NET 1 = implicit * NET 4 = auxsc1 * NET 13 = auxsc3 * NET 26 = a * NET 40 = b * NET 49 = s * NET 52 = vdd * NET 65 = vss xauxsc1 64 65 53 55 33 35 2 8 ndrvp_y xs 66 70 56 60 48 50 11 21 5 9 34 36 38 45 mx2_y xauxsc3 70 71 60 61 41 46 18 22 ndrvp_y R2_1 4 7 6 C2_11 4 63 6.9e-15 C2_12 7 63 6.9e-15 R2_2 3 2 0.15 C2_21 3 63 7.2e-16
[----- CUT -----]
C4_51 69 63 6.525e-15 C4_52 72 63 6.525e-15 R4_6 68 69 0.001 R4_7 68 67 0.001 .ends gxor
Alliance(1) MBK(1) Al(1) RCN(1) MBK_SEPAR(1)
Gregoire AVOT.  Gregoire.AVOT@lip6.fr
This tool is under development at the ASIM department of the LIP6 laboratory. We need your feedback to improve documentation and tools.
GIT-LS-FILES(1)                    Git Manual                    GIT-LS-FILES(1)
git-ls-files - Show information about files in the index and the working tree
git ls-files [-z] [-t] [-v] [-f] (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* (-[c|d|o|i|s|u|k|m])* [--eol] [--deduplicate] [-x <pattern>|--exclude=<pattern>] [-X <file>|--exclude-from=<file>] [--exclude-per-directory=<file>] [--exclude-standard] [--error-unmatch] [--with-tree=<tree-ish>] [--full-name] [--recurse-submodules] [--abbrev[=<n>]] [--] [<file>...]
This merges the file listing in the index with the actual working directory list, and shows different combinations of the two.
One or more of the options below may be used to determine the files shown:
-c, --cached Show cached files in the output (default)
-d, --deleted Show deleted files in the output
-m, --modified Show modified files in the output
-o, --others Show other (i.e. untracked) files in the output
-i, --ignored Show only ignored files in the output. When showing files in the index, print only those matched by an exclude pattern. When showing "other" files, show only those matched by an exclude pattern. Standard ignore rules are not automatically activated, therefore at least one of the --exclude* options is required.
-s, --stage Show staged contents' mode bits, object name and stage number in the output.
--directory If a whole directory is classified as "other", show just its name (with a trailing slash) and not its whole contents.
--no-empty-directory Do not list empty directories. Has no effect without --directory.
-u, --unmerged Show unmerged files in the output (forces --stage)
-k, --killed Show files on the filesystem that need to be removed due to file/directory conflicts for checkout-index to succeed.
-z \0 line termination on output and do not quote filenames. See OUTPUT below for more information.
--deduplicate When only filenames are shown, suppress duplicates that may come from having multiple stages during a merge, or giving --deleted and --modified option at the same time. When any of the -t, --unmerged, or --stage option is in use, this option has no effect.
-x <pattern>, --exclude=<pattern> Skip untracked files matching pattern. Note that pattern is a shell wildcard pattern. See EXCLUDE PATTERNS below for more information.
-X <file>, --exclude-from=<file> Read exclude patterns from <file>; 1 per line.
--exclude-per-directory=<file> Read additional exclude patterns that apply only to the directory and its subdirectories in <file>.
--exclude-standard Add the standard Git exclusions: .git/info/exclude, .gitignore in each directory, and the userâ€™s global exclusion file.
--error-unmatch If any <file> does not appear in the index, treat this as an error (return 1).
--with-tree=<tree-ish> When using --error-unmatch to expand the user supplied <file> (i.e. path pattern) arguments to paths, pretend that paths which were removed in the index since the named <tree-ish> are still present. Using this option with -s or -u options does not make any sense.
-t This feature is semi-deprecated. For scripting purpose, git-status(1) --porcelain and git-diff-files(1) --name-status are almost always superior alternatives, and users should look at git-status(1) --short or git-diff(1) --name-status for more user-friendly alternatives.
This option identifies the file status with the following tags (followed by a space) at the start of each line:
H cached
S skip-worktree
M unmerged
R removed/deleted
C modified/changed
K to be killed
? other
-v Similar to -t, but use lowercase letters for files that are marked as assume unchanged (see git-update-index(1)).
-f Similar to -t, but use lowercase letters for files that are marked as fsmonitor valid (see git-update-index(1)).
--recurse-submodules Recursively calls ls-files on each active submodule in the repository. Currently there is only support for the --cached mode.
--debug After each line that describes a file, add more data about its cache entry. This is intended to show as much information as possible for manual inspection; the exact format may change at any time.
--eol Show <eolinfo> and <eolattr> of files. <eolinfo> is the file content identification used by Git when the "text" attribute is "auto" (or not set and core.autocrlf is not false). <eolinfo> is either "-text", "none", "lf", "crlf", "mixed" or "".
"" means the file is not a regular file, it is not in the index or not accessible in the working tree.
<eolattr> is the attribute that is used when checking out or committing, it is either "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf". Since Git 2.10 "text=auto eol=lf" and "text=auto eol=crlf" are supported.
Both the <eolinfo> in the index ("i/<eolinfo>") and in the working tree ("w/<eolinfo>") are shown for regular files, followed by the ("attr/<eolattr>").
<file> Files to show. If no files are given all files which match the other specified criteria are shown.
git ls-files just outputs the filenames unless --stage is specified in which case it outputs:
[<tag> ]<mode> <object> <stage> <file>
git ls-files --eol will show i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file>
git ls-files --unmerged and git ls-files --stage can be used to examine detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA-1 pair, the index records up to three such pairs; one from tree O in stage 1, A in stage 2, and B in stage 3. This information can be used by the user (or the porcelain) to see what should eventually be recorded at the path. (see git-read-tree(1) for more information on state)
git ls-files can use a list of "exclude patterns" when traversing the directory tree and finding files to show when the flags --others or --ignored are specified. gitignore(5) specifies the format of exclude patterns.
These exclude patterns come from these places, in order:
1. The command-line flag --exclude=<pattern> specifies a single pattern. Patterns are ordered in the same order they appear in the command line.
2. The command-line flag --exclude-from=<file> specifies a file containing a list of patterns. Patterns are ordered in the same order they appear in the file.
3. The command-line flag --exclude-per-directory=<name> specifies a name of the file in each directory git ls-files examines, normally .gitignore. Files in deeper directories take precedence. Patterns are ordered in the same order they appear in the files.
A pattern specified on the command line with --exclude or read from the file specified with --exclude-from is relative to the top of the directory tree. A pattern read from a file specified by --exclude-per-directory is relative to the directory that the pattern file appears in.
git-read-tree(1), gitignore(5)
reptyr(1)                    General Commands Manual                   reptyr(1)
reptyr - Reparent a running program to a new terminal
reptyr PID
reptyr -l|-L [COMMAND [ARGS]]
reptyr is a utility for taking an existing running program and attaching it to a new terminal. Started a long-running process over ssh, but have to leave and don't want to interrupt it? Just start a screen, use reptyr to grab it, and then kill the ssh session and head on home.
reptyr works by attaching to the target program using ptrace(2), redirecting relevant file descriptors, and changing the program's controlling terminal (See tty(4)) It is this last detail that makes reptyr work much better than alternatives such as retty(1).
After attaching a program, the program will appear to be either backgrounded or suspended to the shell it was launched from (depending on the shell). For maximal safety you can run
bg; disown
in the old shell to remove the association with the program, but reptyr will attempt to ensure that the target program remains running even if you close the shell without doing so.
Use an alternate mode of attaching, "TTY-stealing". In this mode, reptyr will not ptrace(2) the target process, but will attempt to discover the terminal emulator for that process' pty, and steal the master end of the pty. This mode is more reliable and flexible in many circumstances (for instance, it can attach all processes on a tty, rather than just a single process). However, as a downside, children of sshd(8) cannot be attached via -T unless reptyr is run as root. See ⟨https://blog.nelhage.com/2014/08/ new-reptyr-feature-tty-stealing/⟩ for more information about tty- stealing.
-l, -L [COMMAND [ARGS]]
Instead of attaching to a new process, create a new pty pair, proxy the master end to the current terminal, and then print the name of the slave pty. This can be passed to e.g.  gdb´s set inferior-tty option.
If an optional COMMAND and ARGS are passed in conjunction with -l, that command will be executed as a child of reptyr with the REPTYR_PTY environment variable set to the name of the slave pty. If -L is used instead of -l, then fds 0-2 of the child will also be redirected to point to the slave, and the child will be run in a fresh session with the slave as its controlling terminal.
By default, reptyr will move any file descriptors in the target that were connected to the target's controlling terminal to point to the new terminal. The -s option will cause reptyr to unconditionally attach file descriptors 0, 1, and 2 in the target, even if the target has no controlling terminal or they are not connected to a terminal.
Print the version of reptyr and exit.
Print a usage message and exit.
Print verbose debug output while running.
reptyr depends on the ptrace(2) system call to attach to the remote program. On Ubuntu Maverick and higher, this ability is disabled by default for security reasons. You can enable it temporarily by doing
# echo 0 > /proc/sys/kernel/yama/ptrace_scope
as root, or permanently by editing the file /etc/sysctl.d/10-ptrace.conf, which also contains more information about this setting.
When attaching to some curses programs, they will not redraw the screen right away, and a ^L or similar will be needed to force a redraw.
Similarly, after attaching to certain programs, the old terminal will be left in an odd state, and a clear or even reset may be required before the old terminal is usable again.
Attaching to rtorrent (and probably some other apps) doesn't work right (rtorrent stops accepting input) (The problem is that rtorrent is using epoll to poll stdin, and we don't update the internal reference that the epoll fd has to the old tty).
Attaching to a process with children doesn't work right. This should be possible to fix -- I just need to ptrace each child individually and do the same games to it.
Attaching a less(1) process doesn't work if you have a .lessfilter file, as less leaves around a zombie child in this case. This could be worked around.
Bugs should be reported to the author (see below) or via the issue tracker on GitHub.
reptyr was written by Nelson Elhage <nelhage@nelhage.com>.
⟨https://github.com/nelhage/reptyr⟩
neercs(1), screen(1)
PUPPET(8)                         Puppet manual                        PUPPET(8)
Usage: puppet subcommand [options] action [options]
Available subcommands: