Cross-platform working

As many people will know, the CTAN team have come up with the idea of having TDS-ready zip files for packages. The idea is that you can just download the zip into your local TeX directory, unzip it and run texhash, with no TeX-based unpacking or document compilation.

That’s all fine when it works, but I’ve recently had a bit of trouble making zips at my end. My favoured tool for doing that has tended to be 7-Zip. However, it was pointed out to me last week that the resulting zip files are not quite right. On Unix systems, the command unzip -xa will convert line endings to the system convention (LF only), even if they come from Windows (LF-CR endings). However, this requires that the zip identifies text files, and 7-Zip marks everything as binary!

I did a bit of hunting around, and found Info-ZIP, where after a bit of hunting about you can find zip and unzip binaries for Windows. These give me Unix-like capabilities on Windows, so I can make the appropriate files, alter line endings on zipping/unzipping and check the results.

That led me to take another look at the batch file I use each time I release something to CTAN: doing it by hand is an unreliable business! I’ve reworked it quite a bit, to generalise everything and also add a few tweaks. For anyone interested, the file is available here. It’s called make, so that you get Unix-like abilities on Windows. The file has to be customised for each package I write, but most of this version is generalised, and can be altered using a few settings.

set AUXFILES=aux cmds dvi glo gls hd idx ilg ind ist log los out tmp toc
set CLEAN=bib bst cls eps gz ins cfg pdf sty tex txt zip
set DOCEXTRA=\AtBeginDocument{\OnlyDescription}
set INDEXFILE=gglo
set PACKAGE=achemso
set TEX=achemso-demo

Anyone at all familiar with batch files will see that this is a block of environmental variables: in this case, these are the settings for my achemso package. Most are pretty obvious settings, but in case anyone wants to use the file for their own purposes:

  • AUXFILES File types to delete after every run: throw away files.
  • CLEAN File types deleted only if make clean is run: useful stuff.
  • DOCEXTRA Inserted when creating documentation, can be anything. I don’t typeset the code for my packages in the release documents, hence the \OnlyDescription setting.
  • INDEXFILE This is always gglo for documents using the ltxdoc class, but is l3doc if using the LaTeX3 class l3doc.
  • PACKAGE Pretty obvious, the bundle name!
  • PDF The names of PDF files to add to the documentation part of a TDS zip. By having this as a setting, special effects (demo documents, for example) are possible.
  • TDSROOT. Almost always as given for a LaTeX package.
  • TEX A list of .tex files to copy into the TDS archive: to avoid any testing files, not all .tex files are copied.
  • TXT The names of text files to copy to the documentation directory
  • UNPACK The file(s) to run to unpack the package. I use .dtx files that are self-extracting, but the traditional method is to have a separate .ins file.

If the batch file proves useful to enough people, I might write some proper documentation and do a bit more generalisation.

With all of that in place, I can hopefully keep Unix-based LaTeX users happy without too much work!

7 thoughts on “Cross-platform working

  1. Yes, but:

    “So far, ctanify has been tested only on Linux.”

    The aim of my batch file is to work without needing too much in the way of “extras”. You need a ZIP program to make zip files at the command line, but that it it here. I should add that the more complex version for doing LaTeX releases does need Perl, but only to run the automated check system, not to do the basics.

  2. Pingback: The Phones Show 83 (HTC Touch Pro 2 vs Nokia N97, Proporta) | Business Telephone System
  3. Joseph, thanks for sharing this. I tried to use your script but it was not flexible enough for my needs. I started to do some (a lot) modifications, but I’m not done with this yet (other things to do atm). I can send you my work-in-progress if you are interested.

    I’m quite intrigued by your self-extracting .dtx sources. Is there some information available on how to prepare them. I’m still trying to get the hang of .dtx format.

    BTW, line conversion with ‘zip -ll …’ damaged my pdf documentation, so I’m not sure if this is such a good idea. It’s probably better to do it for selected files with a dedicated tool (or a text editor).

  4. Hello Tomek,

    Thanks for the comment. As you might guess, flexibility was not priority number one for me. What I’ve posted is a starting point for editing for each case. (As I’ve developed my LaTeX work, I’ve altered how I make my DTX files, so the older ones need different treatment to the newer or updated ones.) Of course, I’d be intrigued to see what you have (I’m well aware of my limitations with batch programming: I’ve got a lot better, but there is still much to learn).

    The DTX structure in the latest stuff is something I’ve taken from what Will Robertson has been doing. I quite like the idea of keeping everything in one file, but having the ability to extract or typeset easily. There is some information on DTX creation in the “dtxgallery” bundle on CTAN. As you might guess, I tend to start with “take an existing file, delete all of the code and rename”!

    On the zip stuff, I can only comment on what I’ve tried. “zip -ll” works with the copy of Info-ZIP I have (downloaded from their site once I’d worked out where it was):

    The same works on my new Mac, and the PDFs seem to survive OK. (The current expl3 and biblatex-chem releases were done this way from the Mac, while notes2bib was released from Windows.)


  5. Thanks for the dtxgallery pointer. I was looking for something like this, actually. I don’t quite get how it all works yet but having some examples should help. It seems that I won’t escape digging into that stuff a bit deeper if I want to use it. I wrote a very small package recently that needs to be documented now, so maybe I will experiment with that before trying to repackage my bigger project.

  6. @Tomek — if you’re not keen on digging into the DTX format, take a look at my sources for asyfig or pstool. They use gmdoc instead and (IMO) are much easier to wrap your head around (albeit with quite a significant drop in flexibility — but who needs to re-arrange and conditionally output discontiguous sources very often?).

Leave a Reply