tzcoolman/facs — pull request #4 by brainstorm (2014-06-29 21:26:19+00:00)
Title: OSX newlines do not seem to be handled properly by FASTQ parser

Enze, can you check the processing of fastq files such as (look at the newlines indicated with 'a0', (`man ascii`)):

```
00000030 20 20 31 30 31 4d 0a 54 41 54 47 47 47 43 41 47 | 101M.TATGGGCAG|
00000090 41 41 54 54 47 43 54 54 41 47 54 54 0a 2b 0a 47 |AATTGCTTAGTT.+.G|
000000a0 47 47 47 3d 47 46 47 43 47 47 47 47 40 47 41 3d |GGG=GFGCGGGG@GA=|
00000100 45 47 46 41 0a 40 46 72 61 67 5f 32 20 63 68 72 |EGFA.@Frag_2 chr|
00000130 31 33 32 39 37 38 29 20 20 31 30 31 4d 0a 41 54 |132978) 101M.AT|
000001a0 43 54 54 0a 2b 0a 39 44 26 47 45 44 47 46 42 42 |CTT.+.9D&GEDGFBB|
00000200 40 38 2b 43 43 3e 38 40 3c 39 40 0a 40 46 72 61 |@8+CC>8@<9@.@Fra|
00000240 31 30 31 4d 0a 41 43 41 41 41 54 54 43 41 41 41 |101M.ACAAATTCAAA|
```

It seems that the `check_fmt` logic does not treat it properly and always returns 0 reads on OSX :/

```
void read_process (bloom * bl, Queue * info, Queue * tail, F_set * File_head, float sampling_rate, float tole_rate, char mode, char fmt_type)
(...)
if (next_job == NULL)
return;
```

```
char *check_fmt (Queue *info, Queue *tail, char *start_point, char type)
(...)
{ // XXX: Does this account for OSX-style newlines? next_job is always NULL on OSX fastq files.
next_job = strchr (start_point, '\0');
if (next_job[-1] == '\n' && next_job[-2] == '\n')
next_job -= 1;
else if (next_job[-4] == '\r' && next_job[-3] == '\n')
next_job -= 2;
}

```

@guillermo-carrasco