>> 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?
I have found the xstring package, which provides a \StrRemoveBraces command
that helps here:
\usepackage{xstring}
\strremovebraces{\in...@path\jobname.lyx}[\lyxfilepath]
\def\parsedate #1:20#2#3#4#5#6#7#8\empty{20#2#3/#4#5/#6#7}
\date{\expandafter\parsedate\pdffilemoddate{\lyxfilepath}\empty}
Attached is a .lyx-file that demonstrate this.
Nevertheless, I would prefer a solution that does not employ xstring.
Daniel
moddate.lyx
Description: Binary data
