On Fri, Jun 21, 2002 at 06:05:39PM -0400, Clint Adams wrote:
> > sake. I understand the alleged benefits of ash (small, loads faster on a
> > slow/small memory machine). Why would I, Debian user, benefit from being
> > able to run pdksh as /bin/sh? (Remembering that standards compliance, in
> > and of itself, does not give me a sexual thrill.)
> I answered this explicitly already. It gives you a smaller,
> faster-loading shell and it supports brace expansions, which are the
> number one bug filed against #!/bin/sh scripts.
As far as I can tell there are two possibilities here:
(a) "it" is pdksh or posh, and it already works at least as well
as ash on the various #!/bin/sh scripts in Debian, or
(b) "it" is pdksh or posh or similar, and it doesn't yet work as
well as ash on the various #!/bin/sh scripts in Debian, due to
various POSIX extensions that we use and it doesn't support
In (a)'s case, this means that we can just say "Actually, as it
turns out, we don't merely support ash and bash as /bin/sh at
present, actually we lucked out and we already support ash, bash
and pdksh!" and have no more problems continuing to support pdksh as
we're going to have continuing to support ash. If this is the case,
then there's *still* no value in minimising /bin/sh: we can get the
smaller-faster-loading-more-reliable-shell that you're talking about
without having to fix all your various bugs. Whichever shell you're
talking obviously already supports kill -9, type and command, and whatever
other useful features that we currently use and you want us to stop using.
If this is supposedly the case, it'd be helpful to know which shell this
is, and if it does actually work as well as you're hypothesising.
> So, if someone needs to run a low-memory machine in production, [...]
In (b)'s case, on the other hand, you _can't_ run whatever shell you're
talking about on a production, because it _doesn't_ work as well as ash,
and this entire line of argument's erroneous.
> Is this not an answer?
Well, no, it really isn't. If some shell already works better with than
some other supported shell in practice, then it's supported de facto --
continuing to support it doesn't require signficant changes to current
practice, by definition. As such, it doesn't make sense to use that as
an argument about why we should change current practice.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpzOyqFhlOij.pgp
Description: PGP signature