On Saturday, October 20, 2012, Fields, Christopher J wrote:

> On Oct 4, 2012, at 3:11 PM, Peter Cock 
> <p.j.a.c...@googlemail.com<javascript:;>>
> wrote:
> > On Thu, Oct 4, 2012 at 8:56 PM, Shane Sturrock 
> > <sh...@biomatters.com<javascript:;>>
> wrote:
> >> I've just been setting up our internal galaxy server and following
> >> the instructions to get the NCBI BLAST+ tool working but I kept
> >> getting stuck with it passing -db "" in rather than the actual
> >> database name.  It turns out, because I had copied the
> >> 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.
> >
> >> 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.
> >
> > Regards,
> >
> > Peter
> I agree with Peter.  The same argument could be made for any horizontal
> whitespace (my editor for instance converts tabs to spaces), but the simple
> fact is you easily run into convoluted logic dealing with all of the edge
> cases when the easiest fix is to simply conform to the standard and use
> tabs.
> chris
Another idea would be for Galaxy to issue a clear error if a loc file has
an inconsistent  number of fields/tabs per line.

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