On 28.05.2010, at 21:24, stefano franchi wrote:
>
>
> On Fri, May 28, 2010 at 5:33 AM, Daniel Lohmann
> <[email protected]> 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
