Re: Bugs in bash (was: Release-critical Bugreport)
- To: email@example.com
- Subject: Re: Bugs in bash (was: Release-critical Bugreport)
- From: Steve Greenland <firstname.lastname@example.org>
- Date: Tue, 1 Jun 1999 13:40:34 -0500
- Message-id: <19990601134034.A2218@molehole>
- Mail-followup-to: email@example.com
- Reply-to: Steve Greenland <firstname.lastname@example.org>
- In-reply-to: <Pine.LNX.email@example.com>; from Joost Kooij on Tue, Jun 01, 1999 at 02:34:02AM +0200
- References: <19990529135212.A19818@molehole> <Pine.LNX.firstname.lastname@example.org>
On 31-May-99, 19:34 (CDT), Joost Kooij <email@example.com> wrote:
> Please accept my affidavit then. I've been running several machines with
> /bin/sh -> /etc/alternatives/sh -> /bin/ash with good results.
> I see no inherent or logical relation between a true multi-user system and
> ill-found assumptions in user scripts that /bin/sh has bash capabilities.
I wasn't clear. What I was implying was that on a Linux system with
lots of shell users, many of them would probably not be aware of the
issue and assumed bash == sh, and there would (I'd expect) be a lot more
"quickie" scripts floating around. On a single-user system, the user is
the admin, and thus more likely to be following deb-devel or otherwise
clued-in. Thus, one might be more likely to run into problems when you
replaced the /bin/sh->bash link with something else.
> IMHO such scripts are simply broken and in al cases fixed equally simply.
Oh yeah, but you might hear a bunch of griping from your users while
you were educating them. I certainly don't have any objection to
"supporting" alternative /bin/sh, and for that matter, wouldn't mind
changing the default: there seem to be some good reasons to do so.
But if we do something like this, we need to be ready for a lot of