Command-line tools for some bibtex database manipulations

Have a look at biber which in the current 1.5 dev version on SourceForge has a new "tool" mode which allows you to use biber's reencoding and source mapping features independently of biblatex. The source mapping features are what you mainly need from your description and this is all documented in the PDF manual. I can provide specific examples if you have specific questions. biber will do everything you mention above apart from the @string expansion which would be possible to add but as you say, it's fairly idiosyncratic.

Of course, you can do this dynamically with biber too - with the changes being applied as the .bib is read but the .bib is not touched. The new tool mode allows you to write the changed .bib to another file without writing a .bbl.

For example, here is how in tool mode to tackle points 2, 3 5 and 6 in your examples. Point 1 is better handled semantically with biblatex and its max/min names options. Create a biber.conf with:

<config>
  <sourcemap>
    <maps datatype="bibtex" map_overwrite="1">
      <map>
        <map_step map_field_set="issn" map_null="1"/>
      </map>
      <map>
        <per_type>ARTICLE</per_type>
        <map_step map_field_set="title" map_null="1"/>
      </map>
      <map>
        <per_type>ARTICLE</per_type>
        <map_step map_field_source="pages" map_final="1"/>
        <map_step map_field_set="archiveprefix" map_null="1"/>
        <map_step map_field_set="eprint" map_null="1"/>
        <map_step map_field_set="primaryclss" map_null="1"/>
      </map>
    </maps>
    <map>
      <map_step map_field_source="doi" map_match="[\\;]" map_final="1"/>
      <map_step map_field_set="doi" map_null="1"/>
    </map>
  </sourcemap>
</config>

Then run biber with

biber --tool file.bib

Which will look in the default locations for your biber.conf and will output a file called file_bibertool.bib.

This is also all possible, as I said, dynamically using the biber.conf as you process the file normally into a .bbl with biber and also the whole mapping functionality is available in biblatex through macros (see \DeclareSourcemap in the biblatex documentation) if you wanted to do this on a per-document basis dynamically.

I have never had a situation in which I must provide a Bibtex file that compiles flawlessly with a journal-supplied BST file. Do you really need to do that?

For conference and journal submissions, one typically just sends a PDF file, not the source code. For the final version, in my experience it's usually enough to provide a Latex source code in which I have already replaced the \bibliography command by the contents of the Bibtex-generated *.bbl file.

Nobody will see how I created the *.bbl file, so I can do anything I want:

• Take the journal-supplied BST file and hack it a bit. It may be much faster to simply remove some buggy parts from the BST file than to tweak your Bibtex database. This makes a lot of sense if you need to deal with the same buggy BST file frequently.

• Just take the final *.bbl file and edit it directly. Particularly useful to handle some one-off special cases.

Another trick that I have used to handle some very exceptional cases is to have two entries in my Bibtex database for the same paper (obviously with different keys, like "foo" and "foo2"). This is useful if you'd like to decide case-by-case which version to use in which paper, independently of other issues such as different BST files.

I do not know any non-programmer tools that can do those things you ask for, so I think you will need a bib scripting toolkit, and pybib is the most commonly used of those. If you are not familiar with python but do know perl, then btOOL may be more suited to you.