Hi,
Damien Jade Duff writes:
> t_refdb.refdb_citekey='CAWKELL1976,GALLESELAKOFF2005,WILLIAMSSCHNIER1996'
>
> ...which returns no references at all. What you'd want here I suppose is...
>
> WHERE t_refdb.refdb_citekey in
> ('CAWKELL1976','GALLESELAKOFF2005','WILLIAMSSCHNIER1996')
>
> ...I notice that in readris.c add_id_from_aux the comments say this
> subroutine is returning a comma separated list but I think that list is
> just handed straight to the select statement. I really don't envy you
> all that string stuff you've done in C - it looks like a nightmare of &s
> and *s and ->s and **s - well, you get used to it I suppose.
>
You've got close to the problem. As far as I can tell my code is not
prepared to handle multi-head citations in .aux files at all. The code
simply assumes that each \citation{} block contains a single citation
which it adds to said comma-separated list. Instead, it should inspect
each \citation{} and tokenize it as needed. I'll supply a fix as soon
as time permits.
> ...yes, so I don't know if you'd consider that a bug given that you may
> require all users to enter their usernames on the command line (I don't
> see that putting someones' username in the system-wide rc file is
> preferrable though).
The manual is apparently a bit unclear about this point. In no case
you're supposed to enter usernames or passwords into the system-wide
config files. That's the job of the personal config files in your home
directory (~/.refdbibrc in this case). Make it read/writable only for
yourself and all should be fine.
> It did cause me trouble because runbib uses the
> second method by default, piping input from an .aux file through to
> refdbib and because I have in the past just been allowing the refdb
> clients to pick up my username from the environment. It works sometimes.
>
I'll have to check whether there is an error in refdbib which fails to
check for missing usernames/passwords. If they're not specified in
either a config file or on the command line, it should not attempt to
pass them to refdbd, causing the command-line parsing on the server
side to fail. I can't explain why it appears to work "sometimes" in
your case, unless you use a database engine without password
check. I'll investigate this.
regards,
Markus
--
Markus Hoenicka
markus.hoenicka@xxxxxxx
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
|
