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 shane.sturrock@biomatters.com Senior Scientist Tel: +64 (0) 9 379 5064 76 Anzac Ave Auckland New Zealand