Re: [preliminary patch] moving XFig files
On Tue, Nov 02, 2004 at 10:28:33AM +, Andreas Vox wrote: Which, by the way, is now conceptually very easy. Just write a postscript parser and away you go... Shouldn't be as hard as parsing LaTeX, don't you think so? :-) Not at all. Ghostscript can do it just fine and provides enough hooks for anything. Andre'
Re: [preliminary patch] moving XFig files
On Tue, Nov 02, 2004 at 10:28:33AM +, Andreas Vox wrote: > < Which, by the way, is now conceptually very easy. Just write a > < postscript parser and away you go... > > Shouldn't be as hard as parsing LaTeX, don't you think so? :-) Not at all. Ghostscript can do it just fine and provides enough hooks for anything. Andre'
Re: [preliminary patch] moving XFig files
Georg Baum wrote: BTW, am I correct that LyX does not support EPS files which reference other files ... yet ;-) ? Yes. But this is something that only very few programs support. Do you want to create a .eps mover? Which, by the way, is now conceptually very easy. Just write a postscript parser and away you go... ;-) -- Angus
Re: [preliminary patch] moving XFig files
Angus Leeming [EMAIL PROTECTED] writes: Georg Baum wrote: BTW, am I correct that LyX does not support EPS files which reference other files ... yet ? Yes. But this is something that only very few programs support. Do you want to create a .eps mover? Which, by the way, is now conceptually very easy. Just write a postscript parser and away you go... Shouldn't be as hard as parsing LaTeX, don't you think so? :-) Anyway, one could just write a DSC parser to identify all needed resources. And no, Georg, I'm not planning to do it ... yet :-) Still, if we should encounter problems related to EPS files including other files, the DSC parsing approach should be quite easy to implement. Ciao /Andreas
Re: [preliminary patch] moving XFig files
Am Dienstag, 2. November 2004 11:28 schrieb Andreas Vox: Angus Leeming [EMAIL PROTECTED] writes: Which, by the way, is now conceptually very easy. Just write a postscript parser and away you go... Shouldn't be as hard as parsing LaTeX, don't you think so? :-) I am not so sure ;-) Postscript has its own pitfalls (probably most of them stem from broken .ps creators). Anyway, one could just write a DSC parser to identify all needed resources. That's what I had in mind (because I have an application for that). And no, Georg, I'm not planning to do it ... yet :-) What a pity! Still, if we should encounter problems related to EPS files including other files, the DSC parsing approach should be quite easy to implement. Agreed. Georg
Re: [preliminary patch] moving XFig files
Georg Baum wrote: > >> BTW, am I correct that LyX does not support EPS files which >> reference other files ... yet ;-) ? > > Yes. But this is something that only very few programs support. Do > you want to create a .eps mover? Which, by the way, is now conceptually very easy. Just write a postscript parser and away you go... ;-) -- Angus
Re: [preliminary patch] moving XFig files
Angus Leeming <[EMAIL PROTECTED]> writes: < Georg Baum wrote: < < > < >> BTW, am I correct that LyX does not support EPS files which < >> reference other files ... yet ? < > < > Yes. But this is something that only very few programs support. Do < > you want to create a .eps mover? < < Which, by the way, is now conceptually very easy. Just write a < postscript parser and away you go... Shouldn't be as hard as parsing LaTeX, don't you think so? :-) Anyway, one could just write a DSC parser to identify all needed resources. And no, Georg, I'm not planning to do it ... yet :-) Still, if we should encounter problems related to EPS files including other files, the DSC parsing approach should be quite easy to implement. Ciao /Andreas
Re: [preliminary patch] moving XFig files
Am Dienstag, 2. November 2004 11:28 schrieb Andreas Vox: > Angus Leeming <[EMAIL PROTECTED]> writes: > < Which, by the way, is now conceptually very easy. Just write a > < postscript parser and away you go... > > Shouldn't be as hard as parsing LaTeX, don't you think so? :-) I am not so sure ;-) Postscript has its own pitfalls (probably most of them stem from broken .ps creators). > Anyway, one could just write a DSC parser to identify all needed resources. That's what I had in mind (because I have an application for that). > And no, Georg, I'm not planning to do it ... yet :-) What a pity! > Still, if we should encounter problems related to EPS files including other > files, the DSC parsing approach should be quite easy to implement. Agreed. Georg
Re: [preliminary patch] moving XFig files
On Sat, Oct 30, 2004 at 01:48:47PM +, Andreas Vox wrote: Unfortunately it also resolves all contained file references relative to the directory of the symlink, not relative to the original file. So there's no real advantage to copying, Okay, then I'm confused and don't understand what it is you're doing. I was under the impression that the files in question weren't generated, but were pre-existing EPS files. I was also under the impression that you were moving everything to a temp-directory so that the resulting DVI files would contain only relative paths, not absolute ones. You can ignore my comments. BTW: While Windoze doesn't have native symlinks, it does have shortcuts. Additionally, with the Cygwin libraries, you can have symlinks under Windoze. They work only with the Cygwin programs, but that's a non-issue since (I assume) we need Cygwin for the Win-version of LyX. -- John Weiss
Re: [preliminary patch] moving XFig files
John Weiss wrote: BTW: While Windoze doesn't have native symlinks, it does have shortcuts. Additionally, with the Cygwin libraries, you can have symlinks under Windoze. They work only with the Cygwin programs, but that's a non-issue since (I assume) we need Cygwin for the Win-version of LyX. Nope. Ruurd Reitsma provides a native Win32 binary here: http://www.home.zonnet.nl/rareitsma/lyx/ We don't support it officially, but we do try and incorporate his changes into the LyX sources. As the (GPL-ed) gtk frontend matures, expect to see official support too. -- Angus
Re: [preliminary patch] moving XFig files
John Weiss [EMAIL PROTECTED] writes: Okay, then I'm confused and don't understand what it is you're doing. I was under the impression that the files in question weren't generated, but were pre-existing EPS files. I was also under the impression that you were moving everything to a temp-directory so that the resulting DVI files would contain only relative paths, not absolute ones. If I understand correctly, it' s not the problem with EPS files themselves but with XFig files which reference EPS files, and TeX files which reference EPS files which are either pre-existing or generated from XFig, and about the resulting DVI files which have the same paths as the TeX files. Of course it would be ok to make symlinks to files which _don't_ reference any other files, although I'm not sure if that will be a big advantage since the temp dir will be deleted later anyway. The mess comes from the fact that with the external insets LyX is so open for different file formats that it is difficult to keep track which files are needed exactly for a given document. BTW, am I correct that LyX does _not_ support EPS files which reference other files ... yet ;-) ? You can ignore my comments. All or just the one about symlinks? ;-) Anyhow, this is such a confusing topic that it's probably ok to discuss it with some redundancy. That will help to clarify this for us who didn't implement it :-) BTW: While Windoze doesn't have native symlinks, it does have shortcuts. You aren't serious, are you? We could as well exploit the specialities of Apple aliases, NFS automounts or Linux userfs - I'm sure we could find a good use for any of those. Brrr, shudder ... Additionally, with the Cygwin libraries, you can have symlinks under Windoze. They work only with the Cygwin programs, but that's a non-issue since (I assume) we need Cygwin for the Win-version of LyX. Someone else answered that ... :-) Ciao /Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: If I understand correctly, it' s not the problem with EPS files themselves but with XFig files which reference EPS files, and TeX files which reference EPS files which are either pre-existing or generated from XFig, and about the resulting DVI files which have the same paths as the TeX files. Of course it would be ok to make symlinks to files which _don't_ And without copying and unique names there are problems with files dir1/fig1.eps and dir2/fig2.eps and some more problems which aare covered in the old discussions reference any other files, although I'm not sure if that will be a big advantage since the temp dir will be deleted later anyway. There might be an advantage if you are tight on disk space and have _a lot_ of _huge_ graphics included, but the code is simpler without that special casing. The mess comes from the fact that with the external insets LyX is so open for different file formats that it is difficult to keep track which files are needed exactly for a given document. BTW, am I correct that LyX does _not_ support EPS files which reference other files ... yet ;-) ? Yes. But this is something that only very few programs support. Do you want to create a .eps mover? Georg
Re: [preliminary patch] moving XFig files
On Sat, Oct 30, 2004 at 01:48:47PM +, Andreas Vox wrote: > Unfortunately it also resolves all contained file references > relative to the directory of the symlink, not relative to the > original file. So there's no real advantage to copying, Okay, then I'm confused and don't understand what it is you're doing. I was under the impression that the files in question weren't generated, but were pre-existing EPS files. I was also under the impression that you were "moving" everything to a temp-directory so that the resulting DVI files would contain only relative paths, not absolute ones. You can ignore my comments. BTW: While Windoze doesn't have native symlinks, it does have shortcuts. Additionally, with the Cygwin libraries, you can have symlinks under Windoze. They work only with the Cygwin programs, but that's a non-issue since (I assume) we need Cygwin for the Win-version of LyX. -- John Weiss
Re: [preliminary patch] moving XFig files
John Weiss wrote: > BTW: While Windoze doesn't have native symlinks, it does have > shortcuts. Additionally, with the Cygwin libraries, you can have > symlinks under Windoze. They work only with the Cygwin programs, but > that's a non-issue since (I assume) we need Cygwin for the Win-version > of LyX. Nope. Ruurd Reitsma provides a native Win32 binary here: http://www.home.zonnet.nl/rareitsma/lyx/ We don't support it officially, but we do try and incorporate his changes into the LyX sources. As the (GPL-ed) gtk frontend matures, expect to see official support too. -- Angus
Re: [preliminary patch] moving XFig files
John Weiss <[EMAIL PROTECTED]> writes: > Okay, then I'm confused and don't understand what it is you're doing. > I was under the impression that the files in question weren't > generated, but were pre-existing EPS files. I was also under the > impression that you were "moving" everything to a temp-directory so > that the resulting DVI files would contain only relative paths, not > absolute ones. If I understand correctly, it' s not the problem with EPS files themselves but with XFig files which reference EPS files, and TeX files which reference EPS files which are either pre-existing or generated from XFig, and about the resulting DVI files which have the same paths as the TeX files. Of course it would be ok to make symlinks to files which _don't_ reference any other files, although I'm not sure if that will be a big advantage since the temp dir will be deleted later anyway. The mess comes from the fact that with the external insets LyX is so open for different file formats that it is difficult to keep track which files are needed exactly for a given document. BTW, am I correct that LyX does _not_ support EPS files which reference other files ... yet ;-) ? > You can ignore my comments. All or just the one about symlinks? ;-) Anyhow, this is such a confusing topic that it's probably ok to discuss it with some redundancy. That will help to clarify this for us who didn't implement it :-) > BTW: While Windoze doesn't have native symlinks, it does have > shortcuts. You aren't serious, are you? We could as well exploit the specialities of Apple aliases, NFS automounts or Linux userfs - I'm sure we could find a good use for any of those. Brrr, shudder ... > Additionally, with the Cygwin libraries, you can have > symlinks under Windoze. They work only with the Cygwin programs, but > that's a non-issue since (I assume) we need Cygwin for the Win-version > of LyX. Someone else answered that ... :-) Ciao /Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: > If I understand correctly, it' s not the problem with EPS files themselves > but with XFig files which reference EPS files, and TeX files which > reference EPS files which are either pre-existing or generated from XFig, > and about the resulting DVI files which have the same paths as the TeX > files. Of course it would be ok to make symlinks to files which _don't_ And without copying and unique names there are problems with files dir1/fig1.eps and dir2/fig2.eps and some more problems which aare covered in the old discussions > reference any other files, although I'm not sure if that will be a big > advantage since the temp dir will be deleted later anyway. There might be an advantage if you are tight on disk space and have _a lot_ of _huge_ graphics included, but the code is simpler without that special casing. > The mess comes from the fact that with the external insets LyX is so open > for different file formats that it is difficult to keep track which files > are needed exactly for a given document. > BTW, am I correct that LyX does _not_ support EPS files which reference > other files ... yet ;-) ? Yes. But this is something that only very few programs support. Do you want to create a .eps mover? Georg
Re: [preliminary patch] moving XFig files
John Weiss wrote: On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote: The attached patch enables us to move XFig files to the temp directory and continue to generate DVI files, etc that show any included picture files. Question: Why move the files? Will LaTeX not respect symlinks? (Moving ... as in copying ... a file to a work directory just strikes me as wasteful and prone to synchronization errors (have to check which is newer, the true copy or the working copy). Is there some problem with using a symlink?) LyX works on Windoze machines now too... The primary advantage of copying everything to the temp directory is that your real, working directory is not polluted with the crud from the conversion process. The scheme we have in place now is *really* robust. Georg has worked wonders with all this. As an example, DVI files (which contain references to eps files) are now truly relocatable. That's almost impossible to achieve when the eps files have to be generated on the fly from some other format. -- Angus
Re: [preliminary patch] moving XFig files
John Weiss [EMAIL PROTECTED] writes: On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote: The attached patch enables us to move XFig files to the temp directory and continue to generate DVI files, etc that show any included picture files. Question: Why move the files? Will LaTeX not respect symlinks? Sure, and it puts all the aux files into the directory where the symlink is. Unfortunately it also resolves all contained file references relative to the directory of the symlink, not relative to the original file. So there's no real advantage to copying, in fact if you have to change the contained file references you really should make these changes on a copy. That's exactly the kind of mess which Georg and Angus were trying to solve with their scheme, and it looks as if we are finally there. (is there any emoticon for pressing both thumbs? ;-) ) Ciao /Andreas
Re: [preliminary patch] moving XFig files
Am Freitag, 29. Oktober 2004 19:49 schrieb Angus Leeming: It looks very clever. Didn't realise I'd helped write tex_copy.py. I used lyxpreview2bitmap.py as a base, and this really helped! I see why the $$l stuff is necessary, but... Well done anyway, for working it all out. You clearly have more patience than I. I do not like it very much either, because everybody knows what copy(x, y) means, while (copy(x, y, z) is not so clear, but it is documented and works. Georg
Re: [preliminary patch] moving XFig files
John Weiss wrote: > On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote: >> The attached patch enables us to move XFig files to the temp directory >> and continue to generate DVI files, etc that show any included picture >> files. > > Question: > > Why move the files? Will LaTeX not respect symlinks? > > (Moving ... as in copying ... a file to a work directory just strikes > me as wasteful and prone to synchronization errors (have to check > which is newer, the true copy or the working copy). Is there some > problem with using a symlink?) LyX works on Windoze machines now too... The primary advantage of copying everything to the temp directory is that your real, working directory is not polluted with the crud from the conversion process. The scheme we have in place now is *really* robust. Georg has worked wonders with all this. As an example, DVI files (which contain references to eps files) are now truly relocatable. That's almost impossible to achieve when the eps files have to be generated on the fly from some other format. -- Angus
Re: [preliminary patch] moving XFig files
John Weiss <[EMAIL PROTECTED]> writes: > > On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote: > > The attached patch enables us to move XFig files to the temp directory and > > continue to generate DVI files, etc that show any included picture files. > > Question: > > Why move the files? Will LaTeX not respect symlinks? Sure, and it puts all the aux files into the directory where the symlink is. Unfortunately it also resolves all contained file references relative to the directory of the symlink, not relative to the original file. So there's no real advantage to copying, in fact if you have to change the contained file references you really should make these changes on a copy. That's exactly the kind of mess which Georg and Angus were trying to solve with their scheme, and it looks as if we are finally there. (is there any emoticon for pressing both thumbs? ;-) ) Ciao /Andreas
Re: [preliminary patch] moving XFig files
Am Freitag, 29. Oktober 2004 19:49 schrieb Angus Leeming: > It looks very clever. Didn't realise I'd helped write tex_copy.py. I used lyxpreview2bitmap.py as a base, and this really helped! > I see why the $$l stuff is necessary, but... Well done anyway, for working > it all out. You clearly have more patience than I. I do not like it very much either, because everybody knows what copy(x, y) means, while (copy(x, y, z) is not so clear, but it is documented and works. Georg
Re: [preliminary patch] moving XFig files
Georg Baum wrote:
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not completely fixed. Consider the
following situation:
master.lyx includes sub/child.lyx
sub/child.lyx includes sub/pic.fig (external material, relative file name)
sub/pic.fig
You will get the following files for a latex export:
master.tex
sub/child.tex
sub/pic.pstex_t
sub/pic.eps
sub/child.tex contains \input{sub/pic.pstex_t}
sub/pic.pstex_t contains \includegraphics{pic} - BANG! It should be
\includegraphics{sub/pic}.
This can be fixed if the external inset runs the conversion in the temp
dir, too, and a copier is used to copy the resulting .pstex_t file. The
attached patch builds on top of the mover patch and implements that. I
did create copy and rename functions with a third argument. This argument
is the latex name of the file, that means it is either absolute or
relative to the master document.
Here comes an updated patch. It is basically the same plus Changelogs and
documentation. Does anybody have objections?
It is really necessary to document the new external template fetaures in
Customization.lyx now. I started to do this, but it is not finished yet.
GeorgIndex: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.644
diff -u -p -r1.644 ChangeLog
--- lib/ChangeLog 28 Oct 2004 14:56:08 - 1.644
+++ lib/ChangeLog 29 Oct 2004 15:51:28 -
@@ -1,3 +1,10 @@
+2004-10-29 Georg Baum [EMAIL PROTECTED]
+
+ * configure.m4: add copier for pstex_t and pdftex_t files
+ * external_templates: (Template XFig): correct referenced files
+ * scripts/tex_copy.py: new
+ * Makefile.am: add scripts/tex_copy.py
+
2004-10-28 José Matos [EMAIL PROTECTED]
* Makefile.am: add entry to layouts/db_stdcounters.inc
Index: lib/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/Makefile.am,v
retrieving revision 1.64
diff -u -p -r1.64 Makefile.am
--- lib/Makefile.am 28 Oct 2004 14:56:08 - 1.64
+++ lib/Makefile.am 29 Oct 2004 15:58:59 -
@@ -860,7 +861,8 @@ dist_scripts_SCRIPTS = \
scripts/fig2pstex.sh \
scripts/listerrors \
scripts/legacy_lyxpreview2ppm.py \
- scripts/lyxpreview2bitmap.py
+ scripts/lyxpreview2bitmap.py \
+ scripts/tex_copy.py
templatesdir = $(pkgdatadir)/templates
dist_templates_DATA = \
Index: lib/configure.m4
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/configure.m4,v
retrieving revision 1.83
diff -u -p -r1.83 configure.m4
--- lib/configure.m4 26 Oct 2004 18:39:08 - 1.83
+++ lib/configure.m4 29 Oct 2004 16:03:56 -
@@ -587,8 +587,6 @@ cat $outfile EOF
\\converter ps fax$fax_command
\\converter ps pdf$ps_to_pdf_command
\\converter word latex $word_to_latex_command
-
-\\copierfigsh \$\$s/fig_copy.sh \$\$i \$\$o
EOF
### the graphic converter part with the predefined ones
@@ -637,6 +635,10 @@ EOF
fi
cat $outfile EOF
+
+\\copierfigsh \$\$s/fig_copy.sh \$\$i \$\$o
+\\copierpstex python \$\$s/tex_copy.py \$\$i \$\$o \$\$l
+\\copierpdftex python \$\$s/tex_copy.py \$\$i \$\$o \$\$l
$rc_entries
\\font_encoding $chk_fontenc
Index: lib/external_templates
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/external_templates,v
retrieving revision 1.27
diff -u -p -r1.27 external_templates
--- lib/external_templates 1 Jun 2004 13:39:31 - 1.27
+++ lib/external_templates 29 Oct 2004 15:51:28 -
@@ -121,9 +121,9 @@ Template XFig
Requirement graphicx
# Preamble WarnNotFound
# Preamble InputOrWarn
- ReferencedFile latex $$AbsPath$$Basename.pstex_t
- ReferencedFile latex $$AbsPath$$Basename.pstex
- ReferencedFile dvi $$AbsPath$$Basename.pstex
+ ReferencedFile latex $$AbsOrRelPathMaster$$Basename.pstex_t
+ ReferencedFile latex $$AbsPath$$Basename.eps
+ ReferencedFile dvi $$AbsPath$$Basename.eps
FormatEnd
Format PDFLaTeX
TransformCommand Rotate RotationLatexCommand
@@ -134,8 +134,8 @@ Template XFig
Requirement graphicx
# Preamble WarnNotFound
# Preamble InputOrWarn
- ReferencedFile latex $$AbsPath$$Basename.pdftex_t
- ReferencedFile latex $$AbsPath$$Basename.pdftex
+ ReferencedFile latex $$AbsOrRelPathMaster$$Basename.pdftex_t
+ ReferencedFile latex $$AbsPath$$Basename.pdf
FormatEnd
Format Ascii
Product $$Contents(\$$AbsPath$$Basename.asc\)
Index: lib/scripts/tex_copy.py
===
RCS file: lib/scripts/tex_copy.py
diff -N lib/scripts/tex_copy.py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/scripts/tex_copy.py 29 Oct 2004 15:56:07 -
@@ -0,0 +1,69 @@
+#! /usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+
+# file
Re: [preliminary patch] moving XFig files
Georg Baum wrote: Here comes an updated patch. It is basically the same plus Changelogs and documentation. Does anybody have objections? It is really necessary to document the new external template fetaures in Customization.lyx now. I started to do this, but it is not finished yet. It looks very clever. Didn't realise I'd helped write tex_copy.py. I see why the $$l stuff is necessary, but... Well done anyway, for working it all out. You clearly have more patience than I. -- Angus
Re: [preliminary patch] moving XFig files
On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote: The attached patch enables us to move XFig files to the temp directory and continue to generate DVI files, etc that show any included picture files. Question: Why move the files? Will LaTeX not respect symlinks? (Moving ... as in copying ... a file to a work directory just strikes me as wasteful and prone to synchronization errors (have to check which is newer, the true copy or the working copy). Is there some problem with using a symlink?) -- John Weiss
Re: [preliminary patch] moving XFig files
Georg Baum wrote:
> I did, and I could not break it, but I found another reason to use this
> mover stuff: Bug 605 is still not completely fixed. Consider the
> following situation:
>
> master.lyx includes sub/child.lyx
> sub/child.lyx includes sub/pic.fig (external material, relative file name)
> sub/pic.fig
>
> You will get the following files for a latex export:
>
> master.tex
> sub/child.tex
> sub/pic.pstex_t
> sub/pic.eps
>
> sub/child.tex contains "\input{sub/pic.pstex_t}"
> sub/pic.pstex_t contains "\includegraphics{pic}" -> BANG! It should be
> "\includegraphics{sub/pic}".
>
> This can be fixed if the external inset runs the conversion in the temp
> dir, too, and a copier is used to copy the resulting .pstex_t file. The
> attached patch builds on top of the mover patch and implements that. I
> did create copy and rename functions with a third argument. This argument
> is the "latex name" of the file, that means it is either absolute or
> relative to the master document.
Here comes an updated patch. It is basically the same plus Changelogs and
documentation. Does anybody have objections?
It is really necessary to document the new external template fetaures in
Customization.lyx now. I started to do this, but it is not finished yet.
GeorgIndex: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.644
diff -u -p -r1.644 ChangeLog
--- lib/ChangeLog 28 Oct 2004 14:56:08 - 1.644
+++ lib/ChangeLog 29 Oct 2004 15:51:28 -
@@ -1,3 +1,10 @@
+2004-10-29 Georg Baum <[EMAIL PROTECTED]>
+
+ * configure.m4: add copier for pstex_t and pdftex_t files
+ * external_templates: (Template XFig): correct referenced files
+ * scripts/tex_copy.py: new
+ * Makefile.am: add scripts/tex_copy.py
+
2004-10-28 José Matos <[EMAIL PROTECTED]>
* Makefile.am: add entry to layouts/db_stdcounters.inc
Index: lib/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/Makefile.am,v
retrieving revision 1.64
diff -u -p -r1.64 Makefile.am
--- lib/Makefile.am 28 Oct 2004 14:56:08 - 1.64
+++ lib/Makefile.am 29 Oct 2004 15:58:59 -
@@ -860,7 +861,8 @@ dist_scripts_SCRIPTS = \
scripts/fig2pstex.sh \
scripts/listerrors \
scripts/legacy_lyxpreview2ppm.py \
- scripts/lyxpreview2bitmap.py
+ scripts/lyxpreview2bitmap.py \
+ scripts/tex_copy.py
templatesdir = $(pkgdatadir)/templates
dist_templates_DATA = \
Index: lib/configure.m4
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/configure.m4,v
retrieving revision 1.83
diff -u -p -r1.83 configure.m4
--- lib/configure.m4 26 Oct 2004 18:39:08 - 1.83
+++ lib/configure.m4 29 Oct 2004 16:03:56 -
@@ -587,8 +587,6 @@ cat >$outfile <>$outfile <
+
+# This script will copy a file to .
+# is no exact copy of , but any occurence of
+# where is without directory and extension parts is
+# replaced by without extension.
+
+
+import os, string, sys
+
+from lyxpreview_tools import error
+
+
+def usage(prog_name):
+return "Usage: %s " % prog_name
+
+
+def main(argv):
+# Parse and manipulate the command line arguments.
+if len(argv) != 4:
+error(usage(argv[0]))
+
+# input file
+abs_from_file = argv[1]
+if not os.path.isabs(abs_from_file):
+error("%s is no absolute file name.\n%s"\
+ % abs_from_file, usage(argv[0]))
+from_dir, rel_from_file = os.path.split(abs_from_file)
+from_base, from_ext = os.path.splitext(rel_from_file)
+
+# output file
+abs_to_file = argv[2]
+if not os.path.isabs(abs_to_file):
+error("%s is no absolute file name.\n%s"\
+ % abs_to_file, usage(argv[0]))
+to_dir, rel_to_file = os.path.split(abs_to_file)
+to_base, to_ext = os.path.splitext(rel_to_file)
+
+# latex file name
+latex_file = argv[3]
+latex_base, latex_ext = os.path.splitext(latex_file)
+
+# Read the input file and write the output file
+from_file = open(abs_from_file, 'rb')
+to_file = open(abs_to_file, 'wb')
+lines = from_file.readlines()
+for line in lines:
+to_file.write(line.replace(from_base, latex_base))
+from_file.close()
+to_file.close()
+
+return 0
+
+
+if __name__ == "__main__":
+main(sys.argv)
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2011
diff -u -p -r1.2011 ChangeLog
--- src/ChangeLog 29 Oct 2004 15:47:52 - 1.2011
+++ src/ChangeLog 29 Oct 2004 15:51:33 -
@@ -1,3 +1,10 @@
+2004-10-29 Georg Baum <[EMAIL PROTECTED]>
+
+ * exporter.C (copyFile): use the mover instead of support::copy()
+ * exporter.C (Export): pass format and latex name to copyFile()
+ * exporter.h (addExternalFile): document
+ * mover.[Ch] (do_copy, do_rename): new methods
Re: [preliminary patch] moving XFig files
Georg Baum wrote: > Here comes an updated patch. It is basically the same plus Changelogs and > documentation. Does anybody have objections? > > It is really necessary to document the new external template fetaures in > Customization.lyx now. I started to do this, but it is not finished yet. It looks very clever. Didn't realise I'd helped write tex_copy.py. I see why the $$l stuff is necessary, but... Well done anyway, for working it all out. You clearly have more patience than I. -- Angus
Re: [preliminary patch] moving XFig files
On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote: > The attached patch enables us to move XFig files to the temp directory and > continue to generate DVI files, etc that show any included picture files. Question: Why move the files? Will LaTeX not respect symlinks? (Moving ... as in copying ... a file to a work directory just strikes me as wasteful and prone to synchronization errors (have to check which is newer, the true copy or the working copy). Is there some problem with using a symlink?) -- John Weiss
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: If you care about overwriting files you could test for existence of $2. This is not necessary here. Either $2 is in a temp dir, was previously created by the very same script and needs to be updated. Or it is not in the temp dir, and the caller of the script checked for its existence before and, if it existed, asked the user for confirmation before overwriting it. Well, this is at least the theory, but if it is not true, it needs to be fixed in lyx and not in the script. Georg
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: > If you care about overwriting files you could test for > existence of $2. This is not necessary here. Either $2 is in a temp dir, was previously created by the very same script and needs to be updated. Or it is not in the temp dir, and the caller of the script checked for its existence before and, if it existed, asked the user for confirmation before overwriting it. Well, this is at least the theory, but if it is not true, it needs to be fixed in lyx and not in the script. Georg
Re: [preliminary patch] moving XFig files
Alfredo Braunstein wrote: Andreas Vox wrote: Alfredo Braunstein [EMAIL PROTECTED] writes: what about [ `dirname $1` -ef `dirname $2` ] ? No idea about portability and such. Works on MacOSX (bash). forgot to mention, bash too ;-) Apparently the default on MacOSX is pwd -L rather than pwd -P as stated in the manpage, so the original script would not work on Mac. Angus, note also that this solution identifies symlinked directories, while yours doesn't. (I suppose that you want them identified?) I guess. Thanks, both, for the pointers. -- Angus
Re: [preliminary patch] moving XFig files
Georg Baum wrote:
Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
I won't apply this until I've finished the stuff above, but it now works
as-is. Perhaps someone else would like to test it out?
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not completely fixed. Consider the
following situation:
master.lyx includes sub/child.lyx
sub/child.lyx includes sub/pic.fig (external material, relative file
name) sub/pic.fig
You will get the following files for a latex export:
master.tex
sub/child.tex
sub/pic.pstex_t
sub/pic.eps
sub/child.tex contains \input{sub/pic.pstex_t}
sub/pic.pstex_t contains \includegraphics{pic} - BANG! It should be
\includegraphics{sub/pic}.
This can be fixed if the external inset runs the conversion in the temp
dir, too, and a copier is used to copy the resulting .pstex_t file. The
attached patch builds on top of the mover patch and implements that. I
did create copy and rename functions with a third argument. This argument
is the latex name of the file, that means it is either absolute or
relative to the master document.
BTW, getExtFromContents() is inconsistent: It returns format names, not
extensions for formats that it knows, and it returns file extensions for
formats that it does not know. I have a fix for this, but I wait with
this until the mover stuff is finished.
Sounds interesting.
Incidentaly, is there a more elegant (shell script) way to ascertain
whether two directories are the same than:
I would prefer python and use
os.path.normpath(FROM_DIR) == os.path.normpath(TO_DIR)
, but I guess this is not the answer you want to hear ;-)
Actually, I don't mind at all. I'll continue to play with the shell script
for a little because I can reduce it (if the files are in different
directories) to a single invocation of sed. However, if it turns out the
PWD stuff is a PITA, then I'll think about using python.
--
Angus
Re: [preliminary patch] moving XFig files
Alfredo Braunstein wrote: Incidentaly, is there a more elegant (shell script) way to ascertain whether two directories are the same than: # If the to and the from files are in the same directory, # then we're done. PRESENT_DIR=`pwd` cd `dirname $1` FROM_DIR=`pwd` cd `dirname $2` TO_DIR=`pwd` cd $PRESENT_DIR test $FROM_DIR = $TO_DIR exit 0 what about [ `dirname $1` -ef `dirname $2` ] ? test -e FOO is a bash extension. Also, dirname does nothing more than strip everything after the final '/' character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to be in different directories. -- Angus
Re: [preliminary patch] moving XFig files
Angus Leeming [EMAIL PROTECTED] writes: what about [ `dirname $1` -ef `dirname $2` ] ? test -e FOO is a bash extension. Also, dirname does nothing more than strip everything after the final '/' character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to be in different directories. Correct for dirname, but -ef as well as cd+pwd will use the true directory. Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and BSD test, so I think it should be available on most platforms. Cheers /Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: Angus Leeming [EMAIL PROTECTED] writes: what about [ `dirname $1` -ef `dirname $2` ] ? test -e FOO is a bash extension. Also, dirname does nothing more than strip everything after the final '/' character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to be in different directories. Correct for dirname, but -ef as well as cd+pwd will use the true directory. Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and BSD test, so I think it should be available on most platforms. Hi Andreas, yes, on Solaris it's available for ksh - but not for sh. (The standard shell for scripting and used by make.) So it's not true to say it's available for all (or most) platforms. With kind regards, Stephan
Re: [preliminary patch] moving XFig files
Stephan Witt wrote:
Andreas Vox wrote:
Angus Leeming [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
test -e FOO is a bash extension.
Also, dirname does nothing more than strip everything after the final
'/' character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to
be in different directories.
Correct for dirname, but -ef as well as cd+pwd will use the true
directory.
Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and
BSD test, so I think it should be available on most platforms.
Hi Andreas,
yes, on Solaris it's available for ksh - but not for sh.
(The standard shell for scripting and used by make.)
So it's not true to say it's available for all (or most) platforms.
I think we're getting a little too involved with generics here, given that
this script is to be used to move .fig files into the temp directory only.
I think that the test below should do the job and should be portable.
PRESENT_DIR=$PWD
cd `dirname $1` || exit $?
FROM_DIR=$PWD
cd `dirname $2` || exit $?
TO_DIR=$PWD
cd $PRESENT_DIR
test $FROM_DIR = $TO_DIR {
# The to and from files are in the same directory.
cp $1 $2
exit $?
}
--
Angus
Re: [preliminary patch] moving XFig files
Angus Leeming [EMAIL PROTECTED] writes:
I think we're getting a little too involved with generics here, given that
this script is to be used to move .fig files into the temp directory only.
I think that the test below should do the job and should be portable.
PRESENT_DIR=$PWD
cd `dirname $1` || exit $?
FROM_DIR=$PWD
cd $PRESENT_DIR
Otherwise relative paths for $2 are relative to $1.
cd `dirname $2` || exit $?
TO_DIR=$PWD
cd $PRESENT_DIR
test $FROM_DIR = $TO_DIR {
# The to and from files are in the same directory.
cp $1 $2
exit $?
}
Doesn't resolve symlinks on Mac :-(
Cheers
/Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote:
I think we're getting a little too involved with generics here, given
that this script is to be used to move .fig files into the temp
directory only. I think that the test below should do the job and
should be portable.
PRESENT_DIR=$PWD
cd `dirname $1` || exit $?
FROM_DIR=$PWD
cd $PRESENT_DIR
Otherwise relative paths for $2 are relative to $1.
Thanks.
cd `dirname $2` || exit $?
TO_DIR=$PWD
cd $PRESENT_DIR
test $FROM_DIR = $TO_DIR {
# The to and from files are in the same directory.
cp $1 $2
exit $?
}
Doesn't resolve symlinks on Mac :-(
and I repeat: this script is to be used to move .fig files into the temp
directory only. The worst case is that the directories are flagged as
different and so 'sed' is used rather than 'cp'. Explain to me why that is
a problem in real life rather than in some hypothetical situation.
Why am I being a PITA? Because 'pwd -[PL]' is a bash shell built-in, not a
POSIX command that comes with each and every *nix box. Examples that don't
implement '-L': FreeBSD, Tru64 Unix.
--
Angus
Re: [preliminary patch] moving XFig files
Angus Leeming [EMAIL PROTECTED] writes: Andreas Vox wrote: Doesn't resolve symlinks on Mac and I repeat: this script is to be used to move .fig files into the temp directory only. The worst case is that the directories are flagged as different and so 'sed' is used rather than 'cp'. Explain to me why that is a problem in real life rather than in some hypothetical situation. Sorry, I didn't want to upset you. Also I didn't realize it was about the choice between sed and cp, I didn't read the patch. I thought it was about not accidently overwriting some files. I think in this case your script is just fine. Why am I being a PITA? Because 'pwd -[PL]' is a bash shell built-in, not a POSIX command that comes with each and every *nix box. Examples that don't implement '-L': FreeBSD, Tru64 Unix. Nor SunOS, but it ignores these arguments. I'm sure you are better informed about POSIX standards than me :-) All I can do is test some script on MacOSX to see if it works or check a manpage, for other Unices others have more experience. Settled then? Cheers Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: Doesn't resolve symlinks on Mac and I repeat: this script is to be used to move .fig files into the temp directory only. The worst case is that the directories are flagged as different and so 'sed' is used rather than 'cp'. Explain to me why that is a problem in real life rather than in some hypothetical situation. Sorry, I didn't want to upset you. I wasn't upset. Also I didn't realize it was about the choice between sed and cp, I didn't read the patch. I thought it was about not accidently overwriting some files. Ach! Should I test for that? Hmmm. As it stands the script will overwrite an existing $2 if 'sed' is used and will not if 'cp' is used. I guess I'll change that to 'cp' -f $1 $2 Why am I being a PITA? Because 'pwd -[PL]' is a bash shell built-in, not a POSIX command that comes with each and every *nix box. Examples that don't implement '-L': FreeBSD, Tru64 Unix. Nor SunOS, but it ignores these arguments. I'm sure you are better informed about POSIX standards than me :-) I'm only as informed as google enables me to be. All I can do is test some script on MacOSX to see if it works or check a manpage, for other Unices others have more experience. Settled then? Sure. Thanks for all the feedback. -- Angus
Re: [preliminary patch] moving XFig files
Angus Leeming wrote: Doesn't resolve symlinks on Mac and I repeat: this script is to be used to move .fig files into the temp directory only. The worst case is that the directories are flagged as different and so 'sed' is used rather than 'cp'. Explain to me why that is a problem in real life rather than in some hypothetical situation. Sorry, I didn't want to upset you. I wasn't upset. Also I didn't realize it was about the choice between sed and cp, I didn't read the patch. I thought it was about not accidently overwriting some files. Ach! Should I test for that? Hmmm. As it stands the script will overwrite an existing $2 if 'sed' is used and will not if 'cp' is used. I guess I'll change that to 'cp' -f $1 $2 Can you pick any other holes in the attached script? -- Angus fig_copy.sh Description: application/shellscript
Re: [preliminary patch] moving XFig files
Angus Leeming [EMAIL PROTECTED] writes: ... I thought it was about not accidently overwriting some files. Ach! Should I test for that? Hmmm. As it stands the script will overwrite an existing $2 if 'sed' is used and will not if 'cp' is used. I guess I'll change that to 'cp' -f $1 $2 Can you pick any other holes in the attached script? If you care about overwriting files you could test for existence of $2. If you are afraid about security risks you should ask someone else; I only vaguely remember there's some exploit with symlinks and temp files. But then we also would have to fix any possible buffer overflows ... and all those system calls ... Need it for 1.4.0?? Maybe we better delay fixing security issues to 1.5.0 ;-) Otherwise the script looks fine to me (but don't take me as an authority for scripts, I'm definitely not! :-) ) /Andreas
Re: [preliminary patch] moving XFig files
Alfredo Braunstein wrote: > Andreas Vox wrote: > >> Alfredo Braunstein <[EMAIL PROTECTED]> writes: >> >>> what about [ `dirname "$1"` -ef `dirname "$2"` ] ? >>> >>> No idea about portability and such. >> >> Works on MacOSX (bash). > > forgot to mention, bash too ;-) > >> Apparently the default on MacOSX is "pwd -L" rather than "pwd -P" as >> stated in the manpage, so the original script would not work on Mac. > > Angus, note also that this solution identifies symlinked directories, > while yours doesn't. (I suppose that you want them identified?) I guess. Thanks, both, for the pointers. -- Angus
Re: [preliminary patch] moving XFig files
Georg Baum wrote:
> Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
>> I won't apply this until I've finished the stuff above, but it now works
>> as-is. Perhaps someone else would like to test it out?
>
> I did, and I could not break it, but I found another reason to use this
> mover stuff: Bug 605 is still not completely fixed. Consider the
> following situation:
>
> master.lyx includes sub/child.lyx
> sub/child.lyx includes sub/pic.fig (external material, relative file
> name) sub/pic.fig
>
> You will get the following files for a latex export:
>
> master.tex
> sub/child.tex
> sub/pic.pstex_t
> sub/pic.eps
>
> sub/child.tex contains "\input{sub/pic.pstex_t}"
> sub/pic.pstex_t contains "\includegraphics{pic}" -> BANG! It should be
> "\includegraphics{sub/pic}".
>
> This can be fixed if the external inset runs the conversion in the temp
> dir, too, and a copier is used to copy the resulting .pstex_t file. The
> attached patch builds on top of the mover patch and implements that. I
> did create copy and rename functions with a third argument. This argument
> is the "latex name" of the file, that means it is either absolute or
> relative to the master document.
> BTW, getExtFromContents() is inconsistent: It returns format names, not
> extensions for formats that it knows, and it returns file extensions for
> formats that it does not know. I have a fix for this, but I wait with
> this until the mover stuff is finished.
Sounds interesting.
>> Incidentaly, is there a more elegant (shell script) way to ascertain
>> whether two directories are the same than:
>
> I would prefer python and use
> os.path.normpath(FROM_DIR) == os.path.normpath(TO_DIR)
> , but I guess this is not the answer you want to hear ;-)
Actually, I don't mind at all. I'll continue to play with the shell script
for a little because I can reduce it (if the files are in different
directories) to a single invocation of sed. However, if it turns out the
PWD stuff is a PITA, then I'll think about using python.
--
Angus
Re: [preliminary patch] moving XFig files
Alfredo Braunstein wrote: >> Incidentaly, is there a more elegant (shell script) way to ascertain >> whether two directories are the same than: >> >> # If the "to" and the "from" files are in the same directory, >> # then we're done. >> PRESENT_DIR=`pwd` >> cd `dirname "$1"` >> FROM_DIR=`pwd` >> >> cd `dirname "$2"` >> TO_DIR=`pwd` >> >> cd $PRESENT_DIR >> test "$FROM_DIR" = "$TO_DIR" && exit 0 > > what about [ `dirname "$1"` -ef `dirname "$2"` ] ? "test -e FOO" is a bash extension. Also, "dirname" does nothing more than strip everything after the final '/' character. "/foo/bar/../baz.cpp" and "/foo/baz.cpp" will appear to be in different directories. -- Angus
Re: [preliminary patch] moving XFig files
Angus Leeming <[EMAIL PROTECTED]> writes: > > what about [ `dirname "$1"` -ef `dirname "$2"` ] ? > > "test -e FOO" is a bash extension. > Also, "dirname" does nothing more than strip everything after the final '/' > character. "/foo/bar/../baz.cpp" and "/foo/baz.cpp" will appear to be in > different directories. Correct for dirname, but -ef as well as cd+pwd will use the true directory. Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and BSD test, so I think it should be available on most platforms. Cheers /Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: Angus Leeming <[EMAIL PROTECTED]> writes: what about [ `dirname "$1"` -ef `dirname "$2"` ] ? "test -e FOO" is a bash extension. Also, "dirname" does nothing more than strip everything after the final '/' character. "/foo/bar/../baz.cpp" and "/foo/baz.cpp" will appear to be in different directories. Correct for dirname, but -ef as well as cd+pwd will use the true directory. Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and BSD test, so I think it should be available on most platforms. Hi Andreas, yes, on Solaris it's available for ksh - but not for sh. (The standard shell for scripting and used by make.) So it's not true to say it's available for all (or most) platforms. With kind regards, Stephan
Re: [preliminary patch] moving XFig files
Stephan Witt wrote:
> Andreas Vox wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>>
what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
>>>
>>>"test -e FOO" is a bash extension.
>>>Also, "dirname" does nothing more than strip everything after the final
>>>'/' character. "/foo/bar/../baz.cpp" and "/foo/baz.cpp" will appear to
>>>be in different directories.
>>
>>
>> Correct for dirname, but -ef as well as cd+pwd will use the true
>> directory.
>>
>> Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and
>> BSD test, so I think it should be available on most platforms.
>
> Hi Andreas,
>
> yes, on Solaris it's available for ksh - but not for sh.
> (The standard shell for scripting and used by make.)
> So it's not true to say it's available for all (or most) platforms.
I think we're getting a little too involved with generics here, given that
this script is to be used to move .fig files into the temp directory only.
I think that the test below should do the job and should be portable.
PRESENT_DIR=$PWD
cd `dirname "$1"` || exit $?
FROM_DIR=$PWD
cd `dirname "$2"` || exit $?
TO_DIR=$PWD
cd "$PRESENT_DIR"
test "$FROM_DIR" = "$TO_DIR" && {
# The "to" and "from" files are in the same directory.
cp "$1" "$2"
exit $?
}
--
Angus
Re: [preliminary patch] moving XFig files
Angus Leeming <[EMAIL PROTECTED]> writes:
< I think we're getting a little too involved with generics here, given that
< this script is to be used to move .fig files into the temp directory only.
< I think that the test below should do the job and should be portable.
<
< PRESENT_DIR=$PWD
<
< cd `dirname "$1"` || exit $?
< FROM_DIR=$PWD
<
cd "$PRESENT_DIR"
Otherwise relative paths for $2 are relative to $1.
< cd `dirname "$2"` || exit $?
< TO_DIR=$PWD
<
< cd "$PRESENT_DIR"
<
< test "$FROM_DIR" = "$TO_DIR" && {
< # The "to" and "from" files are in the same directory.
< cp "$1" "$2"
< exit $?
< }
Doesn't resolve symlinks on Mac :-(
Cheers
/Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote:
> < I think we're getting a little too involved with generics here, given
> that < this script is to be used to move .fig files into the temp
> directory only. < I think that the test below should do the job and
> should be portable. <
> < PRESENT_DIR=$PWD
> <
> < cd `dirname "$1"` || exit $?
> < FROM_DIR=$PWD
> <
>
> cd "$PRESENT_DIR"
>
> Otherwise relative paths for $2 are relative to $1.
Thanks.
> < cd `dirname "$2"` || exit $?
> < TO_DIR=$PWD
> <
> < cd "$PRESENT_DIR"
> <
> < test "$FROM_DIR" = "$TO_DIR" && {
> < # The "to" and "from" files are in the same directory.
> < cp "$1" "$2"
> < exit $?
> < }
>
> Doesn't resolve symlinks on Mac :-(
and I repeat: this script is to be used to move .fig files into the temp
directory only. The worst case is that the directories are flagged as
different and so 'sed' is used rather than 'cp'. Explain to me why that is
a problem in real life rather than in some hypothetical situation.
Why am I being a PITA? Because 'pwd -[PL]' is a bash shell built-in, not a
POSIX command that comes with each and every *nix box. Examples that don't
implement '-L': FreeBSD, Tru64 Unix.
--
Angus
Re: [preliminary patch] moving XFig files
Angus Leeming <[EMAIL PROTECTED]> writes: < Andreas Vox wrote: < > Doesn't resolve symlinks on Mac < < and I repeat: this script is to be used to move .fig files into the temp < directory only. The worst case is that the directories are flagged as < different and so 'sed' is used rather than 'cp'. Explain to me why that is < a problem in real life rather than in some hypothetical situation. Sorry, I didn't want to upset you. Also I didn't realize it was about the choice between sed and cp, I didn't read the patch. I thought it was about not accidently overwriting some files. I think in this case your script is just fine. < Why am I being a PITA? Because 'pwd -[PL]' is a bash shell built-in, not a < POSIX command that comes with each and every *nix box. Examples < that don't implement '-L': FreeBSD, Tru64 Unix. Nor SunOS, but it ignores these arguments. I'm sure you are better informed about POSIX standards than me :-) All I can do is test some script on MacOSX to see if it works or check a manpage, for other Unices others have more experience. Settled then? Cheers Andreas
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: > < > Doesn't resolve symlinks on Mac > < > < and I repeat: this script is to be used to move .fig files into the > temp directory only. The worst case is that the directories are flagged > as different and so 'sed' is used rather than 'cp'. Explain to me why > that is a problem in real life rather than in some hypothetical > situation. > > Sorry, I didn't want to upset you. I wasn't upset. > Also I didn't realize it was about the > choice between sed and cp, I didn't read the patch. I thought it was > about not accidently overwriting some files. Ach! Should I test for that? Hmmm. As it stands the script will overwrite an existing "$2" if 'sed' is used and will not if 'cp' is used. I guess I'll change that to 'cp' -f "$1" "$2" > < Why am I being a PITA? Because 'pwd -[PL]' is a bash shell built-in, > not a < POSIX command that comes with each and every *nix box. Examples > < that don't implement '-L': FreeBSD, Tru64 Unix. > > Nor SunOS, but it ignores these arguments. > > I'm sure you are better informed about POSIX standards than me :-) I'm only as informed as google enables me to be. > All I can do is test some script on MacOSX to see if it works or check a > manpage, for other Unices others have more experience. > > Settled then? Sure. Thanks for all the feedback. -- Angus
Re: [preliminary patch] moving XFig files
Angus Leeming wrote: >> < > Doesn't resolve symlinks on Mac >> < >> < and I repeat: this script is to be used to move .fig files into the >> temp directory only. The worst case is that the directories are flagged >> as different and so 'sed' is used rather than 'cp'. Explain to me why >> that is a problem in real life rather than in some hypothetical >> situation. >> >> Sorry, I didn't want to upset you. > > I wasn't upset. > >> Also I didn't realize it was about the >> choice between sed and cp, I didn't read the patch. I thought it was >> about not accidently overwriting some files. > > Ach! Should I test for that? Hmmm. As it stands the script will overwrite > an existing "$2" if 'sed' is used and will not if 'cp' is used. I guess > I'll change that to > 'cp' -f "$1" "$2" Can you pick any other holes in the attached script? -- Angus fig_copy.sh Description: application/shellscript
Re: [preliminary patch] moving XFig files
Angus Leeming <[EMAIL PROTECTED]> writes: > >> ... I thought it was > >> about not accidently overwriting some files. > > > > Ach! Should I test for that? Hmmm. As it stands the script will overwrite > > an existing "$2" if 'sed' is used and will not if 'cp' is used. I guess > > I'll change that to > > 'cp' -f "$1" "$2" > > Can you pick any other holes in the attached script? If you care about overwriting files you could test for existence of $2. If you are afraid about security risks you should ask someone else; I only vaguely remember there's some exploit with symlinks and temp files. But then we also would have to fix any possible buffer overflows ... and all those system calls ... Need it for 1.4.0?? Maybe we better delay fixing security issues to 1.5.0 ;-) Otherwise the script looks fine to me (but don't take me as an authority for scripts, I'm definitely not! :-) ) /Andreas
Re: [preliminary patch] moving XFig files
Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
I won't apply this until I've finished the stuff above, but it now works
as-is. Perhaps someone else would like to test it out?
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not completely fixed. Consider the
following situation:
master.lyx includes sub/child.lyx
sub/child.lyx includes sub/pic.fig (external material, relative file name)
sub/pic.fig
You will get the following files for a latex export:
master.tex
sub/child.tex
sub/pic.pstex_t
sub/pic.eps
sub/child.tex contains \input{sub/pic.pstex_t}
sub/pic.pstex_t contains \includegraphics{pic} - BANG! It should be
\includegraphics{sub/pic}.
This can be fixed if the external inset runs the conversion in the temp
dir, too, and a copier is used to copy the resulting .pstex_t file. The
attached patch builds on top of the mover patch and implements that. I
did create copy and rename functions with a third argument. This argument
is the latex name of the file, that means it is either absolute or
relative to the master document.
BTW, getExtFromContents() is inconsistent: It returns format names, not
extensions for formats that it knows, and it returns file extensions for
formats that it does not know. I have a fix for this, but I wait with
this until the mover stuff is finished.
Incidentaly, is there a more elegant (shell script) way to ascertain
whether two directories are the same than:
I would prefer python and use
os.path.normpath(FROM_DIR) == os.path.normpath(TO_DIR)
, but I guess this is not the answer you want to hear ;-)
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-mover/lib/configure.m4 lyx-1.4-cvs/lib/configure.m4
--- lyx-1.4-mover/lib/configure.m4 2004-10-23 18:02:38.0 +0200
+++ lyx-1.4-cvs/lib/configure.m4 2004-10-24 21:12:05.0 +0200
@@ -589,6 +589,8 @@ cat $outfile EOF
\\converter word latex $word_to_latex_command
\\copierfigsh \$\$s/fig_copy.sh \$\$i \$\$o
+\\copierpstex python \$\$s/tex_copy.py \$\$i \$\$o \$\$l
+\\copierpdftex python \$\$s/tex_copy.py \$\$i \$\$o \$\$l
EOF
### the graphic converter part with the predefined ones
diff -p -r -U 3 -X excl.tmp lyx-1.4-mover/lib/external_templates lyx-1.4-cvs/lib/external_templates
--- lyx-1.4-mover/lib/external_templates 2004-06-01 15:32:22.0 +0200
+++ lyx-1.4-cvs/lib/external_templates 2004-10-24 20:38:58.0 +0200
@@ -121,9 +121,9 @@ Template XFig
Requirement graphicx
# Preamble WarnNotFound
# Preamble InputOrWarn
- ReferencedFile latex $$AbsPath$$Basename.pstex_t
- ReferencedFile latex $$AbsPath$$Basename.pstex
- ReferencedFile dvi $$AbsPath$$Basename.pstex
+ ReferencedFile latex $$AbsOrRelPathMaster$$Basename.pstex_t
+ ReferencedFile latex $$AbsPath$$Basename.eps
+ ReferencedFile dvi $$AbsPath$$Basename.eps
FormatEnd
Format PDFLaTeX
TransformCommand Rotate RotationLatexCommand
@@ -134,8 +134,8 @@ Template XFig
Requirement graphicx
# Preamble WarnNotFound
# Preamble InputOrWarn
- ReferencedFile latex $$AbsPath$$Basename.pdftex_t
- ReferencedFile latex $$AbsPath$$Basename.pdftex
+ ReferencedFile latex $$AbsOrRelPathMaster$$Basename.pdftex_t
+ ReferencedFile latex $$AbsPath$$Basename.pdf
FormatEnd
Format Ascii
Product $$Contents(\$$AbsPath$$Basename.asc\)
diff -p -r -U 3 -X excl.tmp lyx-1.4-mover/lib/scripts/tex_copy.py lyx-1.4-cvs/lib/scripts/tex_copy.py
--- lyx-1.4-mover/lib/scripts/tex_copy.py 2004-10-23 22:08:12.0 +0200
+++ lyx-1.4-cvs/lib/scripts/tex_copy.py 2004-10-24 09:10:35.0 +0200
@@ -0,0 +1,69 @@
+#! /usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+
+# file tex_copy.py
+# This file is part of LyX, the document processor.
+# Licence details can be found in the file COPYING.
+
+# author Angus Leeming
+# author Georg Baum
+
+# Full author contact details are available in file CREDITS
+
+# Usage:
+# tex_copy.py from file to file latex name
+
+# This script will copy a file from file to to file.
+# to file is no exact copy of from file, but any occurence of basename
+# where basename is from file without directory and extension parts is
+# replaced by latex name without extension.
+
+
+import os, string, sys
+
+from lyxpreview_tools import error
+
+
+def usage(prog_name):
+return Usage: %s from file to file latex name % prog_name
+
+
+def main(argv):
+# Parse and manipulate the command line arguments.
+if len(argv) != 4:
+error(usage(argv[0]))
+
+# input file
+abs_from_file = argv[1]
+if not os.path.isabs(abs_from_file):
+error(%s is no absolute file name.\n%s\
+ % abs_from_file, usage(argv[0]))
+from_dir, rel_from_file = os.path.split(abs_from_file)
+from_base, from_ext = os.path.splitext(rel_from_file)
+
+# output file
+abs_to_file = argv[2]
+if not os.path.isabs(abs_to_file):
+error(%s is no absolute file name.\n%s\
+ %
Re: [preliminary patch] moving XFig files
Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
> I won't apply this until I've finished the stuff above, but it now works
> as-is. Perhaps someone else would like to test it out?
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not completely fixed. Consider the
following situation:
master.lyx includes sub/child.lyx
sub/child.lyx includes sub/pic.fig (external material, relative file name)
sub/pic.fig
You will get the following files for a latex export:
master.tex
sub/child.tex
sub/pic.pstex_t
sub/pic.eps
sub/child.tex contains "\input{sub/pic.pstex_t}"
sub/pic.pstex_t contains "\includegraphics{pic}" -> BANG! It should be
"\includegraphics{sub/pic}".
This can be fixed if the external inset runs the conversion in the temp
dir, too, and a copier is used to copy the resulting .pstex_t file. The
attached patch builds on top of the mover patch and implements that. I
did create copy and rename functions with a third argument. This argument
is the "latex name" of the file, that means it is either absolute or
relative to the master document.
BTW, getExtFromContents() is inconsistent: It returns format names, not
extensions for formats that it knows, and it returns file extensions for
formats that it does not know. I have a fix for this, but I wait with
this until the mover stuff is finished.
> Incidentaly, is there a more elegant (shell script) way to ascertain
> whether two directories are the same than:
I would prefer python and use
os.path.normpath(FROM_DIR) == os.path.normpath(TO_DIR)
, but I guess this is not the answer you want to hear ;-)
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-mover/lib/configure.m4 lyx-1.4-cvs/lib/configure.m4
--- lyx-1.4-mover/lib/configure.m4 2004-10-23 18:02:38.0 +0200
+++ lyx-1.4-cvs/lib/configure.m4 2004-10-24 21:12:05.0 +0200
@@ -589,6 +589,8 @@ cat >$outfile <
+
+# This script will copy a file to .
+# is no exact copy of , but any occurence of
+# where is without directory and extension parts is
+# replaced by without extension.
+
+
+import os, string, sys
+
+from lyxpreview_tools import error
+
+
+def usage(prog_name):
+return "Usage: %s " % prog_name
+
+
+def main(argv):
+# Parse and manipulate the command line arguments.
+if len(argv) != 4:
+error(usage(argv[0]))
+
+# input file
+abs_from_file = argv[1]
+if not os.path.isabs(abs_from_file):
+error("%s is no absolute file name.\n%s"\
+ % abs_from_file, usage(argv[0]))
+from_dir, rel_from_file = os.path.split(abs_from_file)
+from_base, from_ext = os.path.splitext(rel_from_file)
+
+# output file
+abs_to_file = argv[2]
+if not os.path.isabs(abs_to_file):
+error("%s is no absolute file name.\n%s"\
+ % abs_to_file, usage(argv[0]))
+to_dir, rel_to_file = os.path.split(abs_to_file)
+to_base, to_ext = os.path.splitext(rel_to_file)
+
+# latex file name
+latex_file = argv[3]
+latex_base, latex_ext = os.path.splitext(latex_file)
+
+# Read the input file and write the output file
+from_file = open(abs_from_file, 'rb')
+to_file = open(abs_to_file, 'wb')
+lines = from_file.readlines()
+for line in lines:
+to_file.write(line.replace(from_base, latex_base))
+from_file.close()
+to_file.close()
+
+return 0
+
+
+if __name__ == "__main__":
+main(sys.argv)
diff -p -r -U 3 -X excl.tmp lyx-1.4-mover/src/exporter.C lyx-1.4-cvs/src/exporter.C
--- lyx-1.4-mover/src/exporter.C 2004-10-11 14:06:24.0 +0200
+++ lyx-1.4-cvs/src/exporter.C 2004-10-24 17:59:25.0 +0200
@@ -25,6 +25,7 @@
#include "format.h"
#include "gettext.h"
#include "lyxrc.h"
+#include "mover.h"
#include "output_plaintext.h"
#include "outputparams.h"
#include "frontends/Alert.h"
@@ -92,8 +94,9 @@ enum CopyStatus {
*overwriting files anymore.
* - CANCEL if the export should be cancelled
*/
-CopyStatus copyFile(string const & sourceFile, string const & destFile,
- bool force)
+CopyStatus copyFile(string const & format,
+string const & sourceFile, string const & destFile,
+string const & latexFile, bool force)
{
CopyStatus ret = force ? FORCE : SUCCESS;
@@ -117,7 +120,8 @@ CopyStatus copyFile(string const & sourc
}
}
- if (!lyx::support::copy(sourceFile, destFile))
+ Mover const & mover = movers(format);
+ if (!mover.copy(sourceFile, destFile, latexFile))
Alert::error(_("Couldn't copy file"),
bformat(_("Copying %1$s to %2$s failed."),
MakeDisplayPath(sourceFile),
@@ -203,15 +210,18 @@ bool Exporter::Export(Buffer * buffer, s
string const dest = OnlyPath(result_file);
CopyStatus status = SUCCESS;
for (vector::const_iterator it = files.begin();
-it != files.end() && status != CANCEL; ++it)
- status = copyFile(it->sourceName,
+it != files.end() && status != CANCEL; ++it) {
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: Alfredo Braunstein [EMAIL PROTECTED] writes: what about [ `dirname $1` -ef `dirname $2` ] ? No idea about portability and such. Works on MacOSX (bash). forgot to mention, bash too ;-) Apparently the default on MacOSX is pwd -L rather than pwd -P as stated in the manpage, so the original script would not work on Mac. Angus, note also that this solution identifies symlinked directories, while yours doesn't. (I suppose that you want them identified?) Alfredo
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: > Alfredo Braunstein <[EMAIL PROTECTED]> writes: > >> what about [ `dirname "$1"` -ef `dirname "$2"` ] ? >> >> No idea about portability and such. > > Works on MacOSX (bash). forgot to mention, bash too ;-) > Apparently the default on MacOSX is "pwd -L" rather than "pwd -P" as > stated in the manpage, so the original script would not work on Mac. Angus, note also that this solution identifies symlinked directories, while yours doesn't. (I suppose that you want them identified?) Alfredo
[preliminary patch] moving XFig files
The attached patch enables us to move XFig files to the temp directory and continue to generate DVI files, etc that show any included picture files. The next step is to add an ability to iterate over the specialized copier functions and ascertain which ones have been added and which ones have been removed from the system defaults. Oh, and add stuff to the Preferences dialog to enable users to add and remove 'em. I won't apply this until I've finished the stuff above, but it now works as-is. Perhaps someone else would like to test it out? The patch also 'fixes' Jean-Marc's additions of quotes so that execvp doesn't fall over immediately. Certainly, preview is working again, but the 'fix' is clearly less than sophisticated. I'll apply this last bit soon if there's no objection. As ever, all suggestions are welcome ;-) Incidentaly, is there a more elegant (shell script) way to ascertain whether two directories are the same than: # If the to and the from files are in the same directory, # then we're done. PRESENT_DIR=`pwd` cd `dirname $1` FROM_DIR=`pwd` cd `dirname $2` TO_DIR=`pwd` cd $PRESENT_DIR test $FROM_DIR = $TO_DIR exit 0 -- Angus move.diff.gz Description: GNU Zip compressed data
Re: [preliminary patch] moving XFig files
Angus Leeming wrote: The attached patch enables us to move XFig files to the temp directory and continue to generate DVI files, etc that show any included picture files. The next step is to add an ability to iterate over the specialized copier functions and ascertain which ones have been added and which ones have been removed from the system defaults. Oh, and add stuff to the Preferences dialog to enable users to add and remove 'em. I won't apply this until I've finished the stuff above, but it now works as-is. Perhaps someone else would like to test it out? The patch also 'fixes' Jean-Marc's additions of quotes so that execvp doesn't fall over immediately. Certainly, preview is working again, but the 'fix' is clearly less than sophisticated. I'll apply this last bit soon if there's no objection. As ever, all suggestions are welcome ;-) Incidentaly, is there a more elegant (shell script) way to ascertain whether two directories are the same than: # If the to and the from files are in the same directory, # then we're done. PRESENT_DIR=`pwd` cd `dirname $1` FROM_DIR=`pwd` cd `dirname $2` TO_DIR=`pwd` cd $PRESENT_DIR test $FROM_DIR = $TO_DIR exit 0 what about [ `dirname $1` -ef `dirname $2` ] ? No idea about portability and such. HTH, Alfredo
Re: [preliminary patch] moving XFig files
Alfredo Braunstein [EMAIL PROTECTED] writes: what about [ `dirname $1` -ef `dirname $2` ] ? No idea about portability and such. Works on MacOSX (bash). Apparently the default on MacOSX is pwd -L rather than pwd -P as stated in the manpage, so the original script would not work on Mac. /Andreas
[preliminary patch] moving XFig files
The attached patch enables us to move XFig files to the temp directory and continue to generate DVI files, etc that show any included picture files. The next step is to add an ability to iterate over the specialized copier functions and ascertain which ones have been added and which ones have been removed from the system defaults. Oh, and add stuff to the Preferences dialog to enable users to add and remove 'em. I won't apply this until I've finished the stuff above, but it now works as-is. Perhaps someone else would like to test it out? The patch also 'fixes' Jean-Marc's additions of quotes so that execvp doesn't fall over immediately. Certainly, preview is working again, but the 'fix' is clearly less than sophisticated. I'll apply this last bit soon if there's no objection. As ever, all suggestions are welcome ;-) Incidentaly, is there a more elegant (shell script) way to ascertain whether two directories are the same than: # If the "to" and the "from" files are in the same directory, # then we're done. PRESENT_DIR=`pwd` cd `dirname "$1"` FROM_DIR=`pwd` cd `dirname "$2"` TO_DIR=`pwd` cd $PRESENT_DIR test "$FROM_DIR" = "$TO_DIR" && exit 0 -- Angus move.diff.gz Description: GNU Zip compressed data
Re: [preliminary patch] moving XFig files
Angus Leeming wrote: > The attached patch enables us to move XFig files to the temp directory and > continue to generate DVI files, etc that show any included picture files. > > The next step is to add an ability to iterate over the specialized copier > functions and ascertain which ones have been added and which ones have > been removed from the system defaults. Oh, and add stuff to the > Preferences dialog to enable users to add and remove 'em. > > I won't apply this until I've finished the stuff above, but it now works > as-is. Perhaps someone else would like to test it out? > > The patch also 'fixes' Jean-Marc's additions of quotes so that execvp > doesn't fall over immediately. Certainly, preview is working again, but > the 'fix' is clearly less than sophisticated. > > I'll apply this last bit soon if there's no objection. > > As ever, all suggestions are welcome ;-) > > Incidentaly, is there a more elegant (shell script) way to ascertain > whether two directories are the same than: > > # If the "to" and the "from" files are in the same directory, > # then we're done. > PRESENT_DIR=`pwd` > cd `dirname "$1"` > FROM_DIR=`pwd` > > cd `dirname "$2"` > TO_DIR=`pwd` > > cd $PRESENT_DIR > test "$FROM_DIR" = "$TO_DIR" && exit 0 what about [ `dirname "$1"` -ef `dirname "$2"` ] ? No idea about portability and such. HTH, Alfredo
Re: [preliminary patch] moving XFig files
Alfredo Braunstein <[EMAIL PROTECTED]> writes: > what about [ `dirname "$1"` -ef `dirname "$2"` ] ? > > No idea about portability and such. Works on MacOSX (bash). Apparently the default on MacOSX is "pwd -L" rather than "pwd -P" as stated in the manpage, so the original script would not work on Mac. /Andreas
