Hi Peter,

Thanks for the quick reply.

On 5/10/2012, at 9:11 AM, Peter Cock wrote:

On Thu, Oct 4, 2012 at 8:56 PM, Shane Sturrock <shane@biomatters.com> wrote:

examples in the blastdb_p.loc file, I had put two tabs in just
as in the sample doc.  This doesn't work.  It has to be one tab.

You're seeing a double tab in the blastdb_p.loc.sample file?
Which line? I should fix that.

This section:

#Your blastdb_p.loc file should include an entry per line for each "base name"
#you have stored. For example:
#
#nr_05Jun2010 NCBI NR (non redundant) 05 Jun 2010 /data/blastdb/05Jun2010/nr
#nr_15Aug2010 NCBI NR (non redundant) 15 Aug 2010 /data/blastdb/15Aug2010/nr
#...etc...
#
#See also blastdb.loc which is for any nucleotide BLAST database.

There are two tabs between the 2010 and /data

Like an idiot I just copied one of those lines and changed it to match my local database setup and then spent literally hours trying to figure out why blast from the command line worked fine, but I couldn't get it to work with Galaxy.

However, I would say that it would be better for the code
to be fixed so it can handle a variable number of tabs rather
than being so strict.

But that would break valid situations where you might want
an empty field in a table. OK, not likely with the BLAST
databases, but it could apply to other *.loc files in Galaxy.

Fair enough, so I would suggest updating the samples to specify that there must be only one tab between each section and that the sample actually follows this.  The blastdb.loc file example is fine, just the blastdb_p.loc is wrong.

Shane

Regards,

Peter

--
For urgent cases, contact support@biomatters.com

Dr Shane Sturrock
Senior Scientist
Tel: +64 (0) 9 379 5064
76 Anzac Ave
Auckland
New Zealand