On 28.05.2010, at 21:24, stefano franchi wrote: > > > On Fri, May 28, 2010 at 5:33 AM, Daniel Lohmann > <daniel.lohm...@informatik.uni-erlangen.de> wrote: > > On 28.05.2010, at 00:30, Tim Wescott wrote: > > > Assuming you are compiling with pdftex as backend (which is most probably the > case, as all more or less recent LaTeX-Distributions use it by default -- > even when compiling to dvi), you can use the \pdffilemoddate{<filename>} > built-in command to retrieve the "last modified" date of <filename>. > > LyXically and applied for the own source file this comes down to the > following two lines, which should be inserted into your document's preamble: > > \def\parsedate #1:20#2#3#4#5#6#7#8\empty{20#2#3/#4#5/#6#7} > \date{\expandafter\parsedate\pdffilemoddate{\jobname.tex}\empty} > > (You can alter the display format, e.g., to use full stops instead of hyphens > as separators, by modifying the \empty{} part of the first line. > > > Nice trick. But wouldn't the final result be identical to the print date, > since pdftex checks the modification date of a tex file created on the fly by > lyx at print time? Or there is something more involved I don't understand?
Stefano, you are right, of course! We need the path to the LyX-File, not to the generated .tex file: \date{\expandafter\parsedate\pdffilemoddate{/Users/lohmann/test.lyx}\empty} However, I would prefer not to hard-code the absolute path to the LyX file. Fortunately, LyX defines \in...@path in the preamble as the file path to the LyX-file directory: \def\in...@path{{/Users/lohmann//}} However, the following does /not/ work: \date{\expandafter\parsedate\pdffilemoddate{\in...@path\jobname.lyx}\empty} Apparently, the problem is the double curly braces that LyX uses in the definition of \in...@path and that somehow influence the TeX-internal scanning; with the following definition it /would/ work: \def\in...@path{/Users/lohmann//} Does anybody know, how to expand \in...@path in a way that the double curly braces do not cause these troubles? Daniel