/bin/sh invoked from make doesn't find command with unquoted dash-argument

I have a makefile to build some transducers using Xerox' finite state tools (xfst in this case), which I invoke in my makefile like so (except with a hard tab instead of spaces in the actual makefile, of course):

latin.fst: nouns.fst verbs.fst
    xfst -f build/latin.fst.build

On my laptop (a Mac with OS X 10.6.2) this works just fine, but on my university's Linux machines I get this error:

make: xfst: Command not found
make: *** [nouns.fst] Error 127

After some debugging I've found two ways to fix this problem. The first is to quote the -f argument to xfst: "-f", the other is to say SHELL=/bin/bash at the top of the makefile.

From the second fix (and how make works) it looks like the problem is with how /bin/sh executes the command. Now, /bin/sh is linked to /bin/bash, so it's not because of some kind of weird shell being installed as /bin/sh. Also, 开发者_运维百科invoking /bin/sh and running the commands, or invoking /bin/sh -c "xfst -f build/latin.fst.build" works just dandy.

Make is GNU Make 3.81, bash is GNU bash, version 3.2.25(1)-release.

Does anyone have any idea what's going on here?

This a weird error and I don't know what's causing it, but here's what I'd try:

.PHONY: experiment
experiment:
    @echo make's SHELL variable: $(SHELL)
    @echo the actual shell: $$SHELL
    which xfst

Edit:
Wait a second... the error message says that Make failed while trying to make nouns.fst, not latin.fst. Is that right? (If it is, then this problem just got weirder.)

EDIT:
All right, now I'm clutching at straws. I'd broaden the search, try running other programs that take options, try aliasing "xfst -f", try making a local symbolic link to xfst, try enclosing the whole command in quotes or backticks... and then just admit that I was totally stumped.

Perhaps you modified a bash-specific startup file (.bashrc or .bash_profile) to change your $PATH on the Linux machines to include the directory where xfst is located. In that case, running under /bin/sh would not invoke .bash* so the correct directory would not be on your path.

Any time you move between systems that use different line endings, it's always a good idea to check whether that's a culprit in problems you encounter. As I'm sure you know, Linux and Unix use 0x0a, DOS and Windows use 0x0d 0x0a and Macs use 0x0d. Try looking at the file with hd filename to see what style line endings you have (they may even vary within the file).