Re: ext_copy.py
On 9/08/2017 3:35 a.m., José Abílio Matos wrote:
On Thursday, 25 May 2017 01.31.05 WEST Andrew Parsloe wrote:
(Deep breath.) I think ext_copy.py is only half of a pair of scripts.
The other half is a "dummy exporter", something like
## dummy_export.py
## a minimal script used to 'export' the
## current document and excite the LyX
## copier mechanism into action
import sys
fin = open(sys.argv[1], 'r') # $$i
fout = open(sys.argv[2], 'w') # $$o
fout.write('\n')
fin.close()
fout.close()
This code could simply be:
import shutils, sys
shutil.copy2(sys.argv[1], sys.argv[2])
Thank you for the suggestion José. (I am a rank amateur Pythonist.)
However, testing produced an error until I realised that "import
shutils" should be "import shutil", when it worked perfectly.
To give an example of use: if I want to copy the preview logs back from
the temp directory to the document directory or a subdirectory /LOGS of
it, I define a file format LOG (preview) with extension tmp. The copier is
python -tt $$s/scripts/ext_copy.py -e log -t LOGS $$i $$o
and under converters, from LyX to LOG (preview), enter
python -tt $$s/scripts/dummy_export.py $$i $$o
"Exporting" the current document to LOG (preview) format creates a file
.tmp in the temp directory (containing a single linefeed
character); ext_copy.py then springs into action and copies the preview
logs back to the /LOGS subdirectory of the document directory. Since I
use the LaTeX runs of the preview mechanism to perform various
non-standard tasks, the logs are often of great interest.
Using these two scripts together like this provides a fairly simple
mechanism for a user to rescue or preserve files from the temp
directory. Perhaps LyX developers might include something like
dummy_export.py, the "other half" of ext_copy.py, with LyX so that this
mechanism is available "out of the box"?
Probably this should be added to trac as to not to be forgotten.
Will do.
Andrew
Andrew
Regards,
--
José Abílio
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: ext_copy.py
On Tue, Aug 08, 2017 at 03:33:55PM +0100, José Abílio Matos wrote: > On Tuesday, 4 July 2017 23.03.22 WEST Scott Kostyshak wrote: > > No problem at all. I hope you don't mind my nagging emails (if you > do, > > please say so). > > Not only I do not mind them but I appreciate them. :-) > > I apologize for taking so long, No problem, thanks José! Scott signature.asc Description: PGP signature
Re: ext_copy.py
On Thursday, 25 May 2017 01.31.05 WEST Andrew Parsloe wrote:
> (Deep breath.) I think ext_copy.py is only half of a pair of scripts.
> The other half is a "dummy exporter", something like
>
> ## dummy_export.py
> ## a minimal script used to 'export' the
> ## current document and excite the LyX
> ## copier mechanism into action
>
> import sys
>
> fin = open(sys.argv[1], 'r') # $$i
> fout = open(sys.argv[2], 'w') # $$o
> fout.write('\n')
> fin.close()
> fout.close()
This code could simply be:
import shutils, sys
shutil.copy2(sys.argv[1], sys.argv[2])
> To give an example of use: if I want to copy the preview logs back from
> the temp directory to the document directory or a subdirectory /LOGS of
> it, I define a file format LOG (preview) with extension tmp. The copier is
>
> python -tt $$s/scripts/ext_copy.py -e log -t LOGS $$i $$o
>
> and under converters, from LyX to LOG (preview), enter
>
> python -tt $$s/scripts/dummy_export.py $$i $$o
>
> "Exporting" the current document to LOG (preview) format creates a file
> .tmp in the temp directory (containing a single linefeed
> character); ext_copy.py then springs into action and copies the preview
> logs back to the /LOGS subdirectory of the document directory. Since I
> use the LaTeX runs of the preview mechanism to perform various
> non-standard tasks, the logs are often of great interest.
>
> Using these two scripts together like this provides a fairly simple
> mechanism for a user to rescue or preserve files from the temp
> directory. Perhaps LyX developers might include something like
> dummy_export.py, the "other half" of ext_copy.py, with LyX so that this
> mechanism is available "out of the box"?
Probably this should be added to trac as to not to be forgotten.
> Andrew
Regards,
--
José Abílio
Re: ext_copy.py
On Tuesday, 4 July 2017 23.03.22 WEST Scott Kostyshak wrote: > No problem at all. I hope you don't mind my nagging emails (if you do, > please say so). Not only I do not mind them but I appreciate them. :-) I apologize for taking so long, after reading ~1100 pages (tikz manual) and ~550 pages (pdfplots manual) I enjoyed to read the more than 500 messages from the last month discussions. :-) Regards, -- José Abílio
Re: ext_copy.py
On Monday, 7 August 2017 02.52.12 WEST Scott Kostyshak wrote: > On Tue, Jul 04, 2017 at 06:03:22PM -0400, Scott Kostyshak wrote: > > On Tue, Jul 04, 2017 at 11:33:02AM +0100, José Abílio Matos wrote: > > > On Saturday, 1 July 2017 04.54.15 WEST Scott Kostyshak wrote: > > > > Pinging José. > > > > > > > > Scott > > > > > > I am sorry for the huge latency time but I have been busy with exams & > > > Co. > > > That period is now over. > > > > No problem at all. I hope you don't mind my nagging emails (if you do, > > please say so). > > > > > Is it OK then to apply the patch? > > > > Yes, please. > > José can you please commit? > > Scott Done in 6b092c8400. The only changes regarding the original patch was the documentation update to ensure that the documentation, both the comments and the program usage is correct. Regards, -- José Abílio
Re: ext_copy.py
On Tue, Jul 04, 2017 at 06:03:22PM -0400, Scott Kostyshak wrote: > On Tue, Jul 04, 2017 at 11:33:02AM +0100, José Abílio Matos wrote: > > On Saturday, 1 July 2017 04.54.15 WEST Scott Kostyshak wrote: > > > Pinging José. > > > > > > Scott > > > > I am sorry for the huge latency time but I have been busy with exams & Co. > > That period is now over. > > No problem at all. I hope you don't mind my nagging emails (if you do, > please say so). > > > Is it OK then to apply the patch? > > Yes, please. José can you please commit? Scott signature.asc Description: PGP signature
Re: ext_copy.py
On Tue, Jul 04, 2017 at 11:33:02AM +0100, José Abílio Matos wrote: > On Saturday, 1 July 2017 04.54.15 WEST Scott Kostyshak wrote: > > Pinging José. > > > > Scott > > I am sorry for the huge latency time but I have been busy with exams & Co. > That period is now over. No problem at all. I hope you don't mind my nagging emails (if you do, please say so). > Is it OK then to apply the patch? Yes, please. Thanks, Scott signature.asc Description: PGP signature
Re: ext_copy.py
On Saturday, 1 July 2017 04.54.15 WEST Scott Kostyshak wrote: > Pinging José. > > Scott I am sorry for the huge latency time but I have been busy with exams & Co. That period is now over. Is it OK then to apply the patch? Regards, -- José Abílio
Re: ext_copy.py
On Tue, Jun 06, 2017 at 03:33:47PM -0400, Scott Kostyshak wrote: > On Sun, May 28, 2017 at 01:23:14PM -0400, Scott Kostyshak wrote: > > On Thu, May 25, 2017 at 12:31:05PM +1200, Andrew Parsloe wrote: > > > > > > On 24/05/2017 9:24 p.m., José Abílio Matos wrote: > > > > On Wednesday, 24 May 2017 03.51.55 WEST Scott Kostyshak wrote: > > > > > > > > > Any objection from anyone else? > > > > > > > > > > > > > Scott > > > > > > > > Honestly the use of the plus sign as a special character seems unnatural > > > > to me. :-) > > > > > > > > My suggestion would be to pass an option that specify just that, say -d. > > > > The advantage of this approach it that it does not add new special > > > > characters. > > > > > > > > A patch follows attached. I have not updated the documentation. > > > > Regards, > > > > > > > > José Abílio > > > > > > > Thank you José. I was the person requesting this, and yes, -d is better > > > than > > > using +. > > > > José do you think the patch should go in for 2.3.0? If so go ahead. > > José I just wanted to make sure you saw the above message. Pinging José. Scott signature.asc Description: PGP signature
Re: ext_copy.py
On Sun, May 28, 2017 at 01:23:14PM -0400, Scott Kostyshak wrote: > On Thu, May 25, 2017 at 12:31:05PM +1200, Andrew Parsloe wrote: > > > > On 24/05/2017 9:24 p.m., José Abílio Matos wrote: > > > On Wednesday, 24 May 2017 03.51.55 WEST Scott Kostyshak wrote: > > > > > > > Any objection from anyone else? > > > > > > > > > > Scott > > > > > > Honestly the use of the plus sign as a special character seems unnatural > > > to me. :-) > > > > > > My suggestion would be to pass an option that specify just that, say -d. > > > The advantage of this approach it that it does not add new special > > > characters. > > > > > > A patch follows attached. I have not updated the documentation. > > > Regards, > > > > > > José Abílio > > > > > Thank you José. I was the person requesting this, and yes, -d is better than > > using +. > > José do you think the patch should go in for 2.3.0? If so go ahead. José I just wanted to make sure you saw the above message. Scott signature.asc Description: PGP signature
Re: ext_copy.py
On Thu, May 25, 2017 at 12:31:05PM +1200, Andrew Parsloe wrote: > > On 24/05/2017 9:24 p.m., José Abílio Matos wrote: > > On Wednesday, 24 May 2017 03.51.55 WEST Scott Kostyshak wrote: > > > > > Any objection from anyone else? > > > > > > > Scott > > > > Honestly the use of the plus sign as a special character seems unnatural > > to me. :-) > > > > My suggestion would be to pass an option that specify just that, say -d. > > The advantage of this approach it that it does not add new special > > characters. > > > > A patch follows attached. I have not updated the documentation. > > Regards, > > > > José Abílio > > > Thank you José. I was the person requesting this, and yes, -d is better than > using +. José do you think the patch should go in for 2.3.0? If so go ahead. Scott signature.asc Description: PGP signature
Re: ext_copy.py
On 24/05/2017 9:24 p.m., José Abílio Matos wrote:
On Wednesday, 24 May 2017 03.51.55 WEST Scott Kostyshak wrote:
Any objection from anyone else?
Scott
Honestly the use of the plus sign as a special character seems unnatural
to me. :-)
My suggestion would be to pass an option that specify just that, say -d.
The advantage of this approach it that it does not add new special
characters.
A patch follows attached. I have not updated the documentation.
Regards,
José Abílio
Thank you José. I was the person requesting this, and yes, -d is better
than using +.
(Deep breath.) I think ext_copy.py is only half of a pair of scripts.
The other half is a "dummy exporter", something like
## dummy_export.py
## a minimal script used to 'export' the
## current document and excite the LyX
## copier mechanism into action
import sys
fin = open(sys.argv[1], 'r') # $$i
fout = open(sys.argv[2], 'w') # $$o
fout.write('\n')
fin.close()
fout.close()
To give an example of use: if I want to copy the preview logs back from
the temp directory to the document directory or a subdirectory /LOGS of
it, I define a file format LOG (preview) with extension tmp. The copier is
python -tt $$s/scripts/ext_copy.py -e log -t LOGS $$i $$o
and under converters, from LyX to LOG (preview), enter
python -tt $$s/scripts/dummy_export.py $$i $$o
"Exporting" the current document to LOG (preview) format creates a file
.tmp in the temp directory (containing a single linefeed
character); ext_copy.py then springs into action and copies the preview
logs back to the /LOGS subdirectory of the document directory. Since I
use the LaTeX runs of the preview mechanism to perform various
non-standard tasks, the logs are often of great interest.
Using these two scripts together like this provides a fairly simple
mechanism for a user to rescue or preserve files from the temp
directory. Perhaps LyX developers might include something like
dummy_export.py, the "other half" of ext_copy.py, with LyX so that this
mechanism is available "out of the box"?
Andrew
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: ext_copy.py
On Wednesday, 24 May 2017 03.51.55 WEST Scott Kostyshak wrote:
> Any objection from anyone else?
>
> Scott
Honestly the use of the plus sign as a special character seems unnatural to
me. :-)
My suggestion would be to pass an option that specify just that, say -d. The
advantage of this approach it that it does not add new special characters.
A patch follows attached. I have not updated the documentation.
Regards,
--
José Abílio
diff --git a/lib/scripts/ext_copy.py b/lib/scripts/ext_copy.py
index fb70d7bbba..dae9ae616f 100644
--- a/lib/scripts/ext_copy.py
+++ b/lib/scripts/ext_copy.py
@@ -13,11 +13,11 @@
# This script is to be used as a "copier" script in the sense needed by
# the converter definitions. Given a and , it will copy
-# all files in the directory in which from_file is found that have the
-# extensions given in the -e argument, or all files in that directory if no
+# all files in the directory in which from_file is found that have the
+# extensions given in the -e argument, or all files in that directory if no
# such argument is given. So, for example, we can do:
# python ext_copy.py -e png,html,css /path/from/file.html /path/to/file.html
-# and all html, png, and css files in /path/from/ will be copied to the
+# and all html, png, and css files in /path/from/ will be copied to the
# (possibly new) directory /path/to/file.html.LyXconv/.
# The -t argument determines the extension added, the default being "LyXconv".
# If just . is given, no extension is added.
@@ -32,13 +32,16 @@ def main(argv):
progname = argv[0]
exts = [] #list of extensions for which we're checking
+use_doc_dir = False
targext = "LyXconv" #extension for target directory
-opts, args = getopt.getopt(sys.argv[1:], "e:t:")
+opts, args = getopt.getopt(sys.argv[1:], "de:t:")
for o, v in opts:
if o == "-e":
exts = v.split(',')
if o == "-t":
targext = v
+ if o == "-d":
+use_doc_dir = True
# input directory
if len(args) != 2:
@@ -49,11 +52,14 @@ def main(argv):
from_dir = os.path.dirname(abs_from_file)
# output directory
-to_dir = args[1]
-if targext != '.':
- to_dir += "." + targext
-if not os.path.isabs(to_dir):
- error("%s is not an absolute file name.\n%s" % to_dir, usage(progname))
+if use_doc_dir:
+ to_dir = os.path.dirname(args[1])
+else:
+ to_dir = args[1]
+ if targext != '.':
+to_dir += "." + targext
+ if not os.path.isabs(to_dir):
+error("%s is not an absolute file name.\n%s" % to_dir, usage(progname))
if not copy_all(from_dir, to_dir, exts):
# some kind of failure
Re: ext_copy.py
On Thu, May 04, 2017 at 11:44:05PM -0400, Richard Heck wrote: > On 05/04/2017 07:15 PM, Andrew Parsloe wrote: > > I would like to see the following small change made to the script > > ext_copy.py for 2.3.0: > > > > Currently it contains the lines: > > > > # output directory > > to_dir = args[1] > > if targext != '.': > > to_dir += "." + targext > > > > Change this to > > > > # output directory > > if targext == '+': > > to_dir = os.path.dirname(args[1]) > > else: > > to_dir = args[1] > > if targext != '.': > > to_dir += "." + targext > > > > With the change, by using the option -t + this allows a file to be > > copied back to the document directory at the same level and not > > 'buried' in a subdirectory. Some years ago I asked about this and > > Richard explained the need to use a subdirectory to prevent the > > document directory being swamped by sundry files from html export. But > > there are other use cases. I have one in which a single file is copied > > back. Not to be able to place it directly in the document directory > > seems an arbitrary and unnecessary restriction. With my proposed change > > > > python -tt $$s/scripts/ext_copy.py -e lyxdat -t + $$i $$o > > > > copies .lyxdat back to the home directory of .lyx. > > Without the + option, ext_copy.py behaves as before. (Whether + is an > > appropriate character is moot. The natural one would perhaps be . but > > that is already used.) > > No objection from me. Any objection from anyone else? Scott signature.asc Description: PGP signature
Re: ext_copy.py
On 05/04/2017 07:15 PM, Andrew Parsloe wrote: > I would like to see the following small change made to the script > ext_copy.py for 2.3.0: > > Currently it contains the lines: > > # output directory > to_dir = args[1] > if targext != '.': > to_dir += "." + targext > > Change this to > > # output directory > if targext == '+': > to_dir = os.path.dirname(args[1]) > else: > to_dir = args[1] > if targext != '.': > to_dir += "." + targext > > With the change, by using the option -t + this allows a file to be > copied back to the document directory at the same level and not > 'buried' in a subdirectory. Some years ago I asked about this and > Richard explained the need to use a subdirectory to prevent the > document directory being swamped by sundry files from html export. But > there are other use cases. I have one in which a single file is copied > back. Not to be able to place it directly in the document directory > seems an arbitrary and unnecessary restriction. With my proposed change > > python -tt $$s/scripts/ext_copy.py -e lyxdat -t + $$i $$o > > copies .lyxdat back to the home directory of .lyx. > Without the + option, ext_copy.py behaves as before. (Whether + is an > appropriate character is moot. The natural one would perhaps be . but > that is already used.) No objection from me. Richard
