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 <sh...@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             
#nr_15Aug2010   NCBI NR (non redundant) 15 Aug 2010             
#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.

> Regards,
> Peter

For urgent cases, contact supp...@biomatters.com

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

Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:


Reply via email to