From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <201011051832.14379.dexen.devries@gmail.com> References: <773C7824-C50D-49EE-9CF8-74E91515F2F3@corpus-callosum.com> <201011051807.53647.dexen.devries@gmail.com> <201011051832.14379.dexen.devries@gmail.com> Date: Fri, 5 Nov 2010 10:45:17 -0700 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e644df4a6b2fd5049451d6ad Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 781bf100-ead6-11e9-9d60-3106f5b1d025 --0016e644df4a6b2fd5049451d6ad Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 5, 2010 at 10:32 AM, dexen deVries wrote: > On Friday 05 of November 2010 18:18:44 Nick LaForge wrote: > > > A honest question: what is the rationale for merging functionality of > > > make and shell into one? > > > > Use your imagination.... > > Tried, failed. > To me, make is a tool for generating an acyclic, directed graph of > dependencies between build steps from some explicit and some wildcard > rules > -- and then traversing it in a sensible order. How's that for daily use > shell? > > Why is a shell that can generate acyclic digraphs of dependencies bad? Someone clearly found a use for it at some point or it wouldn't have been done. I guess one could try to use make as an init system for services in a configuration, but I don't see why not having those features in a shell is better than having those features in a shell. I do not currently use mash, however, I wonder if it's suitable for a startup mechanism for services just after booting a kernel, to get stuff started in the right order, without lavish attempts at building up those dependencies in a script that can't make acyclic digraphs of dependencies make sense natively. > > Perhaps something about `doing a reasonable action for every target file > named > on the command line'? > The possibilities are finite! > > -- > dx > > --0016e644df4a6b2fd5049451d6ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 5, 2010 at 10:32 AM, dexen d= eVries <dex= en.devries@gmail.com> wrote:
On Friday 05 of November 2010 18:18:44 Ni= ck LaForge wrote:
> > A honest question: what is the rationale for merging functionalit= y of
> > make and shell into one?
>
> Use your imagination....

Tried, failed.
To me, make is a tool for generating an acyclic, directed graph of
dependencies =A0between build steps from some explicit and some wildcard ru= les
-- and then traversing it in a sensible order. How's that for daily use= shell?


Why is a shell that can generate acycl= ic digraphs of dependencies bad? =A0Someone clearly found a use for it at s= ome point or it wouldn't have been done.

I gue= ss one could try to use make as an init system for services in a configurat= ion, but I don't see why not having those features in a shell is better= than having those features in a shell.

I do not currently use mash, however, I wonder if it= 9;s suitable for a startup mechanism for services just after booting a kern= el, to get stuff started in the right order, without lavish attempts at bui= lding up those dependencies in a script that can't make acyclic digraph= s of dependencies make sense natively.
=A0

Perhaps something about `doing a reasonable action for every target file na= med
on the command line'?

The possibili= ties are finite!
=A0

--
dx


--0016e644df4a6b2fd5049451d6ad--