Are there good reasons not to exploit '#!/bin/

Question

Mostly for my amusement, I created a makefile in my $HOME/bin directory called rebuild.mk, and made it executable, and the first lines of the file read:

#!/bin/make -f
#
# Comments on what the makefile is for

...

all: ${SCRIPTS} ${LINKS} ...

...

I can now type:

rebuild.mk

and this causes make to execute.

What are the reasons for not exploiting this on a permanent basis, other than this:

• The makefile is tied to a single directory, so it really isn't appropriate in my main bin directory.

Has anyone ever seen the trick exploited before?

---

Collecting some comments, and providing a bit more background information.

1. Norman Ramsey reports that this technique is used in Debian; that is interesting to know. Thank you.
2. I agree that typing 'make' is more idiomatic.
3. However, the scenario (previously unstated) is that my $HOME/bin directory already has a cross-platform main makefile in it that is the primary maintenance tool for the 500+ commands in the directory.
4. However, on one particular machine (only), I wanted to add a makefile for building a special set of tools. So, those tools get a special makefile, which I called rebuild.mk for this question (it has another name on my machine).
5. I do get to save typing 'make -f rebuild.mk' by using 'rebuild.mk' instead.
6. Fixing the position of the make utility is problematic across platforms.
7. The #!/usr/bin/env make -f technique is likely to work, though I believe the official rules of engagement are that the line must be less than 32 characters and may only have one argument to the command.
8. @dF comments that the technique might prevent you passing arguments to make. That is not a problem on my Solaris machine, at any rate. The three different versions of 'make' I tested (Sun, GNU, mine) all got the extra command line arguments that I type, including options ('-u' on my home-brew version) and targets 'someprogram' and macros CC='cc' WFLAGS=-v (to use a different compiler and cancel the GCC warning flags which the Sun compiler does not understand).

I would not advocate this as a general technique.

As stated, it was mostly for my amusement. I may keep it for this particular job; it is most unlikely that I'd use it in distributed work. And if I did, I'd supply and apply a 'fixin' script to fix the pathname of the interpreter; indeed, I did that already on my machine. That script is a relic from the first edition of the Camel book ('Programming Perl' by Larry Wall).

Answer 1

I've seen this trick used before in the debian/rules file that is part of every Debian package.

Answer 2

We can look at this another way: is it a good idea to design a language whose interpreter looks for a fixed filename if you don't give it one? What if python looked for Pythonfile in the absence of a script name? ;)

You don't need such a mechanism in order to have a convention based around a known name. Example: Autoconf's ./configure script.

Answer 3

"make" is shorter than "./Makefile", so I don't think you're buying anything.

Answer 4

The reason I would not do this is that typing "make" is more idiomatic to building Makefile based projects. Imagine if every project you built you had to search for the differently named makefile someone created instead of just typing "make && make install".

Answer 5

You could use a shell alias for this too.

Answer 6

One problem with this for generally distributable Makefiles is that the location of make is not always consistent across platforms. Also, some systems might require an alternate name like gmake.

Of course one can always run the appropriate command manually, but this sort of defeats the whole purpose of making the Makefile executable.