From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2aa78de3278c853c61d44511e705f1e7@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme, rio workalike available in plan 9 ports
From: lucio@proxima.alt.za
In-Reply-To: <06bc01c426d3$897c0da0$0fca7d50@SOMA>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Tue, 20 Apr 2004 14:58:52 +0200
Topicbox-Message-UUID: 6258815c-eacd-11e9-9e20-41e7f4b1d025

>> A "SHELL=" assignment in the mkfile could go a long way to guarantee
>> recipe compatibility, surely?
> 
> no, consider SHELL=/bin/cat

Sure, but the assumption is that the user distributing a mkfile
actually would want it to produce the desired result?  If
SHELL=/bin/cat appears in such a mkfile, then it is a joke.

I'm assuming that the various /bin/^(sh csh ksh bash tcsh) are
reasonably portable across platforms that the publisher's intent can
mostly be met.  Not unlike having #!/bin/rc at the beginning of a
script.

The interesting question is whether mk, unlike make, can be shell
agnostic.  If I specify SHELL=/usr/bin/perl and supply perl recipes,
will mk cope more or less invisibly?

++L