samtools view -o argument not parsed properly

[mdshw5]

Using both the binary distribution of 0.1.18 and the 0.1.19+ (4dde8f5) source compiled on Mac OS 10.8.3, I see the following behavior with multiple valid files:

$ samtools view -bS file.sam -o file.bam
[samopen] SAM header is present: 84 sequences.
(prints some binary junk to `stdout`)
[main_samview] random alignment retrieval only works for indexed BAM files.

It seems like samtools view is not parsing the -o argument and instead is treating it as a region. This is only an issue on Mac OS, as 0.1.18 on CentOS5 is fine. Can anyone else confirm this behavior?

[jmarshall]

Your command line takes advantage of GNU extensions to the behaviour of getopt() that allow options and arguments (e.g. filenames) to be intermingled. Mac OS X provides the BSD getopt() which implements only the standard behaviour with all options preceding the arguments.

The easy solution is to write your samtools command portably, with all the options at the start:

samtools view -bS -o file.bam file.sam

The alternative would be to compile samtools yourself using GNU getopt. However this is likely more bother than it's worth, and you would end up with a samtools command that behaves differently (albeit more conveniently!) from the other commands on your OS X machine.

[mdshw5]

Wow! I learn something new and useful every day. Writing the command portably seems like the better option. This issue can be closed.

On Apr 15, 2013, at 9:28 AM, John Marshall notifications@github.com wrote:

Your command line takes advantage of GNU extensions to the behaviour of getopt() that allow options and arguments (e.g. filenames) to be intermingled. Mac OS X provides the BSD getopt() which implements only the standard behaviour with all options preceding the arguments.

The easy solution is to write your samtools command portably, with all the options at the start:

samtools view -bS -o file.bam file.sam
The alternative would be to compile samtools yourself using GNU getopt. However this is likely more bother than it's worth, and you would end up with a samtools command that behaves differently (albeit more conveniently!) from the other commands on your OS X machine.

—
Reply to this email directly or view it on GitHub.

[jmarshall]

Closing this issue. This is Utility Syntax Guideline 9 in the POSIX spec, btw, and is the historical Unix behaviour. It's kind of a shame as the GNU behaviour is very handy when typing things on the command line...