Make & .cshrc
Guy Harris
guy at gorodish.Sun.COM
Tue Sep 20 13:18:40 AEST 1988
> This is not necessay, because SysV make also imports all environment
> variables as make variables.
Which is part of the problemn in the first place....
> Thus one can write :-
>
> make SHELL=/bin/sh ...
> or SHELL=/bin/sh make
>
> for one-off makes, and 'alias Make=<one of the above>' for other occasions.
> The -e flag to make (environment values override local settings) can also be
> useful.
Again, not in this case; the whole problem is that the environment variable has
an undesired value!
Obliging users to have an alias for "make", or to type either of the two
aforementioned constructs, is not all that much better than obliging them to
change their Makefiles. The whole point is that things that used to work don't
work any more, and the only argument for breaking things that appears to have
been offered is that users can use Korn shell constructs in their Makefiles.
Big deal.
> If I were to do this, why should I use the Korn shell at all?
Because it has improved interactive features.
> Why should we ever change and enhance anything?
Because there are some cases where the enhancements are either 1) sufficiently
widely available that you can get away with blowing off systems that don't have
them or 2) sufficiently useful that you can justify blowing off systems that
don't have them. Since the Korn shell is not part of any AT&T or Berkeley UNIX
distribution, I have reason to believe that it is not widely enough available
to justify 1), and I haven't run across any cases where its features are so
useful that I can justify 2).
> ... but a better solution would be for make to look for the environment
> variable 'MAKESHELL', and default to 'SHELL' (or /bin/sh if you insist)
> if that did not exist. In fact the latter solution should satisfy both of
> us, should it not?
As long as it defaults to "/bin/sh", yes. Unfortunately, AT&T didn't implement
it that way.
More information about the Comp.unix.wizards
mailing list