BWA MEM different synthax on linux (bash) and macOS (zsh)

Question

[gernophil]

Hey, this might be a dump question, but I have snakemake workflow that I did run multiple times succesfully on and centOS cluster. I always used the sythax: bwa mem resources/genome.fasta path/to/read_1.fastq.gz path/to/read_2.fastq.gz -K 100000000 -Y.

I wanted to do a quick test using my Mac and it turns out that here I need to change the command to bwa mem -K 100000000 -Y resources/genome.fasta path/to/read_1.fastq.gz path/to/read_2.fastq.gz otherwise it won't work.

I know the official usage is bwa mem [options] <idxbase> <in1.fq> [in2.fq], so like in the latter example. I use a fixed version for bwa (0.7.17) installed via conda. So, I am just wondering how is it possible that it runs with the options in the last position on bash (Linux), but not on zsh (macOS).

Just looking for an explanation not a fix :).

[ATpoint]

I cannot tell you the definite answer but the official syntax is indeed bwa mem [options] <idxbase> <in1.fq> [in2.fq] so just always use that and call it a day.

[gernophil]

How boring life would be, if we never asked why :).

[ATpoint]

No, actually there is a ton of important things to work out during a project. Position of arguments is none of it. Just do what everyone does and focus on the important stuff. I am not saying to mock you, it is really a lesson you need to learn early in your career. Nobody will give you credit for solving stuff like this.

[gernophil]

There is nothing to solve here. Just wanna know why the arguments seem to be parsed differently in centOS vs. macOS. And it's not early in my career anymore and up to now it always turned out beneficial to ask such simple questions, because there's always something to learn behind those ;).

[Joe]

Are you using the same version of bwa on both the linux and mac machines?

[gernophil]

Yes, they are defined by the yaml file

[GenoMax]

otherwise it won't work.

Can you be specific as to what does not work? Do you just get an error? I doubt that Heng Li made a mac specific version of bwa code so the options should work identically. Unless conda people built the binary is some specific way that is causing this to happen on Mac.

[gernophil]

Here are some more details:

centOS cluster: bwa=0.7.17 installed via conda.
conda env export gives bwa=0.7.17=he4a0461_11.
Command: bwa mem resources/genome.fasta path/to/read_1.fastq.gz path/to/read_2.fastq.gz -K 100000000 -Y
result: simply starts putting out bwa mem output to stdout (expected)

MacBook pro (Apple Silicon; macOS 14.3.1).
bwa=0.7.17 installed via conda.
conda env export gives bwa=0.7.17=h45fc8d7_11 (slightly different built).
Command: bwa mem resources/genome.fasta path/to/read_1.fastq.gz path/to/read_2.fastq.gz -K 100000000 -Y.
result: giving usage error:

Usage: bwa mem [options] <idxbase> <in1.fq> [in2.fq]

Algorithm options:
... (multiple flags and descriptions)

Note: Please read the man page for detailed description of the command line and options.

It's also weird that I wrote this workflow using my Macbook, so it must have worked earlier. Seem like there has been some change in zsh from one of the macOS updates.

[Joe]

My (total) guess is that zsh is trying to be clever in some way with how it handles positional arguments which is maybe conflicting in weird ways. It does a lot of extra stuff behind the scenes that bash generally doesnt.

[gernophil]

That's my guess too. But it must be something that was changed just recently.

[GenoMax]

Out of curiosity, if you switch to bash on MacOS does the program work? If it does then we can blame this quirk on zsh.

[gernophil]

It still does happen (meaning it still doesn't work). However, I am not sure if this was a "real" bash. I just ran bash (and it looked like a bash), but echo $SHELL still gives /bin/zsh (echo $0 gives bash though, I am not so familiar with switching shells). Also had to make conda available in the bash. conda might still be configured for zsh.