up to version 0.9 *.sequence.txt(.gz) was accepted as input format

[GoogleCodeExporter]

up to version 0.9 *.sequence.txt(.gz) was accepted as input format, maybe we 
could reenable this behaviour

best regards
ben

98 <                elif ext in ['.fastq']: 
98 >                 elif ext in ['.fastq','fq','.sequence.txt']: 

Original issue reported on code.google.com by benjamin...@gmail.com on 26 Jul 2011 at 3:43

[GoogleCodeExporter]

Hi, thanks for the suggestion. However, are you sure this used to work in older 
cutadapt versions? Please also tell me how this format should look like. Is it 
a FASTA file with a different extension? Or does it simply contain one sequence 
per line?

Original comment by marcel.m...@tu-dortmund.de on 26 Jul 2011 at 4:48

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi,

It is a fastq format created by the illumina tools, they traditionally use 
s_1_sequence.txt.gz,.. an extra _1 or _2 if paired reads, dont ask me why. I 
patched our version I can't start renaming files. I also think it a bad habit, 
requiring .fastq, it makes your tool also incompatible with galaxy, where all 
files are dat files.

Well one can always create a symbolic link run cutadapt and remove the link, 
hey its a feature.

Liebe Grüße
ben

Original comment by benjamin...@gmail.com on 26 Jul 2011 at 7:43

[GoogleCodeExporter]

Hi Ben,

that "bad habit" you describe was fixed in version 0.9.4: With the --format 
parameter you can explicitly set the input format, overriding any automatic 
detection.

I have also just added "_sequence.txt" (with or without a trailing .gz) as an 
automatically recognized file name extension for FASTQ files. I hope that fixes 
this issue.

Original comment by marcel.m...@tu-dortmund.de on 26 Jul 2011 at 9:08

[GoogleCodeExporter]

I'm closing this issue since I assume it's fixed.

Original comment by marcel.m...@tu-dortmund.de on 28 Jul 2011 at 12:31

• Changed state: Fixed