Re: [Refdb-users] Strange behaviour of addref called from shell script

[Markus H. <mar...@mh...>]

Jeremy Malcolm writes:
 > #!/bin/bash
 > refdba -c /bin/cat -C deletedb thesis
 > cat Thesis.bib | bib2xml -c corporations.txt | xml2ris | sed -e 
 > '/^AU.*/s/\.//g; s/STD$/ELEC/' > Thesis.ris
 > # Capitalise references, to work around a bug in openjade
 > runsed lyxtox/sedscr_ris Thesis.ris
 > refdba -c /bin/cat -C createdb thesis -E latin1
 > refdbc -c /bin/cat -d thesis -C addref Thesis.ris
 > 

There is indeed nothing unusual here. In fact, I use a (far from
perfect) test harness here which is a shell script like yours. It
creates databases, inserts, updates, picks, unpicks, deletes
references and notes. I have never seen any difference between running
a command from the command line or from within a script.

 > Using updateref doesn't seem to produce the same problem, however I need 
 > to use addref because I will usually have a mixture of new, old and 
 > (possibly) updated references to import.
 > 

This is correct. updateref bypasses the "INSERT" command as it should
touch only existing datasets. This way you don't bump into the
duplicate problem.

 > 0.97 I think.  Running on Mac OS X 10.3.9.
 > 

Oh dear. There have been way too many changes between 0.9.7 and the
latest prerelease.

The only way to bump into this problem is to cause refdbd to stop
inserting data before it updates the citation key of a newly created
dataset. This would create an incomplete dataset with that particular
dummy citation key. This problem also requires lack of transaction
support, as otherwise the rollback (or the missing commit in case of a
crash) would cause MySQL to remove the dataset again. I don't see how
running refdbc from a script could cause this problem, but it seems to
be a fact. Could you please do the following:

- check the MySQL log for additional hints
- create a SQL dump of your thesis database after your script ran
  unsuccessfully. Please include the refdbd log of that particular run
  as I'd like to compare the process IDs involved.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de