[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling of SHELL by GNU make: not POSIX compliant

From: David Boyce
Subject: Re: Handling of SHELL by GNU make: not POSIX compliant
Date: Thu, 26 Sep 2002 14:05:35 -0400

At 02:08 PM 9/25/2002 -0400, address@hidden wrote:
The POSIX 1003.1-2001 "Shell and Utilities, Issue 6" spec (page 614,
lines 23699-23704) says:

  If SHELL is defined in the makefile or is
  specified on the command line, it shall replace the original value of
  the SHELL macro, *but shall not affect the SHELL environment variable*.

I'm not a member of this list or a GNU make contributor, I'm just the one who reported the bug. But FWIW and IMHO, the case for fixing this is pretty clear. Start with the fact that there's no wiggle room in the standards; POSIX and SUS are both perfectly clear. I'm aware that there are occasional times when GNU will say "Look, POSIX is just stupid on such-and-such and we're going to deliberately ignore it". But in this case POSIX isn't stupid, or at least no one's come up with a reason why the nonstandard behavior is better, and to date GNU make has been able to claim 100% POSIX conformance.

Add to this the fact that any backward-compatibility problems can easily be solved by prepending the 'export' directive to SHELL overrides, and as I see it the case for a fix overwhelms any case against.

The compromise (wimpy) solution might be to fix it only in the presence of .POSIX, but that's really ghetto-izing the fix since most users don't even know about .POSIX let alone use it. Unless someone comes up with a reason to turn a real fix into a pro forma fix, I wouldn't recommend going this way.

(David suggests that if you _explicitly_ export SHELL in your makefile, then it would use that value in the environment).

Just to clarify, I don't make any suggestion regarding _use_ of SHELL from the environment, as the current behavior is not broken. The sentence above should read "... then it would _place_ that value in the environment". Of course it's not much of a suggestion anyway, as this is just the standard behavior of the export directive.

David Boyce

reply via email to

[Prev in Thread] Current Thread [Next in Thread]