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

To address the problem of make not always being in the same place (on my system for example it's in /usr/bin), you could use

#!/usr/bin/env make -f

if you're on a UNIX-like system.

Another problem is that by using the Makefile this way you cannot override variables, by doing, for example make CFLAGS=....