Output for multiple Input file with same filename is confusing for different SeqFilter runs

[greatfireball]

Due to only the filename is printed for the output table if SeqFilter was called with a single filename, it is confusing for multiple runs of SeqFilter each with a single input file with identical filenames.

Currently I am comparing different assemblies. To achieve faster output, I am using multiple SeqFilter calls. The assembly output filename is called transcripts.fasta:

mkdir run_a run_b && \
echo -e ">blub\nACGT" >run_a/transcripts.fasta && \
echo -e ">bla\nACGT" >run_b/transcripts.fasta

In case I am using a single SeqFilter call, a unique path is printed:

SeqFilter run_a/transcripts.fasta run_b/transcripts.fasta 2>/dev/null | column -t
#source                  state  reads  bases  max  min  N50  N90
run_a/transcripts.fasta  RAW    1      15     15   15   15   15
run_b/transcripts.fasta  RAW    1      15     15   15   15   15
TOTAL                    RAW    2      30     15   15   15   15

but for two SeqFilter calls, it will result in an ambiguous list:

(SeqFilter run_a/transcripts.fasta 2>/dev/null; \
> SeqFilter run_b/transcripts.fasta 2>/dev/null) | column -t | | sed '2,$s/^#.*$//' | sed '/^$/d'
#source            state  reads  bases  max  min  N50  N90
transcripts.fasta  RAW    1      15     15   15   15   15
transcripts.fasta  RAW    1      15     15   15   15   15

Tested with SeqFilter 2.1.7 and 2.1.9; column and sed commands are not required and will only reformat the output.

The missing TOTAL line is obviously, but unfortunately, it is hard to identify the correct input file.

This might be solved by:

1. printing the whole filename parameter instead of only the file name if specified
2. enable printing of whole filenames via command line switch
3. something different :)

[thackl]

The feature was actually already implemented, but I forgot to document it: --no-smart-labels

[greatfireball]

Thanks @thackl You are the best!

[thackl]

Ah, I also got confused. I already added a minimal documentation for #12
7933dc5. Do you think it needs more? Since it was only a doc fix I didn't think about bumping version, but #7 warrants a bump I guess

[greatfireball]

Agree... See #14 for further discussion :)