Switching /bin/sh to dash without dash essential

Bernd Zeimetz · External Since: Jul 17, 2006 Posts: 228

Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>
>> Are you saying that your objection to engineering a solution where
>> dash doesn't need to be essential is that it's not worth the effort?
>> I *think* that was the point of your message but am not entirely sure.
>
> Yes, that's definitely my position. From what I can see, engineering a
> solution where dash doesn't need to be essential isn't worth *any* effort,
> because IMHO, so far the arguments for being able to remove dash from the
> system appear entirely contrived.
>

+1 from me. Making things more complicated when there is no need to do so is a
waste of time.

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Giacomo Catenazzi · External Since: Apr 07, 2004 Posts: 30

Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>
>> Are you saying that your objection to engineering a solution where
>> dash doesn't need to be essential is that it's not worth the effort?
>> I *think* that was the point of your message but am not entirely sure.
>
> Yes, that's definitely my position. From what I can see, engineering a
> solution where dash doesn't need to be essential isn't worth *any* effort,
> because IMHO, so far the arguments for being able to remove dash from the
> system appear entirely contrived.

I'm not so sure on the long run:
- maybe a truly posix-like tiny shell will emerge.
- We need to solve in next 5 to 10 years the "echo -n" problem. IIRC
there is a join group POSIX-LSB to solve this and other Linux
"incompatibility" problem.
- what make special dash? I was using when it was named "ash". In
the future maybe it will change the name, removing the Debian "d".
Maybe a super cool tiny and very fast shell will emerge and supercede
dash. What will we do? Need to support an essential third shell
implementation?

So want to leave such door open. Just provide the interface (a POSIX
like shell), not a name of an implementation.

PS: I really want to have dash as default shell.

ciao
cate

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Sam Hartman · External Since: Nov 26, 2004 Posts: 138

>>>>> "Steve" == Steve Langasek <vorlon.TakeThisOut@debian.org> writes:

Steve> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.

>> Are you saying that your objection to engineering a solution
>> where dash doesn't need to be essential is that it's not worth
>> the effort? I *think* that was the point of your message but
>> am not entirely sure.

Steve> Yes, that's definitely my position.

OK, I'm fine with that. I jumped into this mess because several
people asserted that we were making dash essential because it was
technically required. As best I can tell that is false. It seems
like there was a lot of not listening going on, and a lot of throwing
around assertions about what is and is not possible without actually
any attention to the accuracy of those assertions. That makes me
grumpy and so I got involved.

I'm happy with the answer of "making dash essential is easier than not doing so and we have not seen a compelling reason to do something else."

Steve> From what I can see,
Steve> engineering a solution where dash doesn't need to be
Steve> essential isn't worth *any* effort, because IMHO, so far
Steve> the arguments for being able to remove dash from the system
Steve> appear entirely contrived.

I think you're being unfair here. There are arguments about technical
cleanlyness and design esthetics that seem reasonable. I don't see
that these arguments appear contrived. I'm happy to agree with you
though that these arguments don't justify the work.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Clint Adams · External Since: Nov 11, 2004 Posts: 1346

On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote:
> Why?

Because:

On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote:
> If the goal is to make *bash* removable, then I can understand why that
> would be helpful to some people since it's the heavier shell by far. None
> of what you're talking about in this subthread actually advances that goal,
> however. The blocker for removing bash is that today, packages invoking
> /bin/bash are not required by Policy to depend on it. And if they did, we
> might find that there are Priority: required packages using it, which
> there's no policy against, making the exercise more or less pointless.
>
> Oh yeah - libpam0g is one, and libpam0g is transitively essential.

Those packages can be fixed if we want a nice, lean core system.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Steve Langasek · External Since: Dec 13, 2004 Posts: 2140

On Fri, Jul 24, 2009 at 01:09:59PM +0000, Clint Adams wrote:
> On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote:
> > Why?

> Because:

> On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote:
> > If the goal is to make *bash* removable, then I can understand why that
> > would be helpful to some people since it's the heavier shell by far. None
> > of what you're talking about in this subthread actually advances that goal,
> > however. The blocker for removing bash is that today, packages invoking
> > /bin/bash are not required by Policy to depend on it. And if they did, we
> > might find that there are Priority: required packages using it, which
> > there's no policy against, making the exercise more or less pointless.

> > Oh yeah - libpam0g is one, and libpam0g is transitively essential.

> Those packages can be fixed if we want a nice, lean core system.

Patches will be considered.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek DeleteThis @ubuntu.com vorlon DeleteThis @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Clint Adams · External Since: Nov 11, 2004 Posts: 1346

On Fri, Jul 24, 2009 at 03:43:47PM +0200, Steve Langasek wrote:
> Patches will be considered.

The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.

--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.000000000 -0500
+++ debian/libpam0g.postinst 2009-07-24 09:00:38.000000000 -0500
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh

# postinst based heavily on the postinst of libssl0.9.8, courtesy of
# Christoph Martin.
@@ -73,7 +73,7 @@

for service in $check; do
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
- idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
+ idl="/etc/init.d/${service}"
if [ -n "$idl" ] && [ -x $idl ]; then
services="$service $services"
else

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Bjørn_Mork · External Since: Nov 17, 2004 Posts: 5

Clint Adams <schizo.RemoveThis@debian.org> writes:

> - idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
> + idl="/etc/init.d/${service}"
> if [ -n "$idl" ] && [ -x $idl ]; then

You might as well remove the -n test if you do this. There's not much
chance of hitting it anymore...

Bjørn

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Manoj Srivastava · External Since: Dec 07, 2004 Posts: 761

On Fri, Jul 24 2009, Steve Langasek wrote:

> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>
>> Are you saying that your objection to engineering a solution where
>> dash doesn't need to be essential is that it's not worth the effort?
>> I *think* that was the point of your message but am not entirely sure.
>
> Yes, that's definitely my position. From what I can see, engineering a
> solution where dash doesn't need to be essential isn't worth *any* effort,
> because IMHO, so far the arguments for being able to remove dash from the
> system appear entirely contrived.

I think you are not going far enough. Why should I have dash on
the system when my default shell is posh? or (gasp) zsh?

I think one of the objections here is that we ought to have a
more generic approach that allows shells other than dash/bash to be the
default shell, and that the vendor not make the choice.

manoj
--
"We learn from history that we learn nothing from history." George
Bernard Shaw
Manoj Srivastava <srivasta.RemoveThis@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Manoj Srivastava · External Since: Dec 07, 2004 Posts: 761

On Fri, Jul 24 2009, Steve Langasek wrote:

> On Thu, Jul 23, 2009 at 04:10:54PM -0500, Manoj Srivastava wrote:
>> > We want everyone to use dash by default.
>
>> Who is we? Why is the sysadmin not the one making the decision?
>> Why is the Vendor making this decision for the user?
>
> Because there's no reason for an end user to care about which shell /bin/sh
> points to. If they care, it's because they're expecting to use it for

This seems like a failure in imagination. I am an end user, and
I certainly have reasons to care. At my last job, there were production
machines that would have cared

> something beyond what Policy guarantees it to do; that's not something
> we should encourage, they should invoke the shell directly if they
> want to use other features.

Whether or not we want to encourage behaviour that does not
depend on a practice we have followed for 16 years is really
besides the point: There is an isntalled base of user scripts out there
_now_ since we have had /bin/sh pointing to bash, like forever.

For new installations, this matters slightly less, though
changing the default for a new install would make the machine behave
differently from existing Debian machines in the environment, which is
suboptimal from the user's perspective.

>> > If someone does not want to use the default, they are free to do so,
>> > but the default system shell is supposed to always be on the system.
>
>> Why? Is there a technical reason, or because you say so?
>
>> Frankly, if a user is happy with bash, they need bash anyway
>> cause they have users that use it as an interactive shell, adding dash
>> is pure bloat. They might not care for the 4 seconds it saves them on
>> boot, since they rarely boot.
>
> "Pure bloat"?
>
> $ dpkg -I d/dash/dash_0.5.5.1-2.1_i386.deb |grep Size
> Installed-Size: 216
> $

It is still bloat. Not much of a bloat, you might argue, but
bloat it is.

You think Debian can decide when bloat is too much, or not, but
I think Debian would have a better quality of implementation were we to
let the end user decide when bloat is too much, if we can.

> On whose behalf are you splitting these hairs, exactly?

For the most important user in the world, of course: Judy, who
runs debian on her XO.

>
>> I think we can engineer a system where Debian suggests various
>> shells as the default shell, and the user selects one. And only the
>> selected default shell is one that can't be removed from the system.
>
> I think we can engineer lots of things we don't need, this being just
> one of them.

Frankly, I think that moving /bin/sh is another thing we don't
need, but thankfully the project does not run on personal opinion, nor
do we have a dictator for life making us do things one way.

> If the goal is to make *bash* removable, then I can understand why
> that would be helpful to some people since it's the heavier shell by
> far.

Right.

> None of what you're talking about in this subthread actually
> advances that goal, however. The blocker for removing bash is that

Frankly, I think you are overlooking a whole lot of things.

The frst thing you need to do is to not just make bash
removable, you need to determine of this particular user _wants_ it
too. You can't just have a limited set of scenarios (people want lean
/bin/sh) and not (people want all machines in their environment
behaving closer to each other).

> today, packages invoking /bin/bash are not required by Policy to
> depend on it. And if they did, we might find that there are Priority:
> required packages using it, which there's no policy against, making
> the exercise more or less pointless.
>
> Oh yeah - libpam0g is one, and libpam0g is transitively essential.

Again the tunnel vision on packages -- there are users with
installed bases too, which every one seems to just forget.

The idea I am espousing is that we need to come up with not just
replace bash with dash, we need to ask the user if they want to change
the default shell, and whether the new default shell should be dash.

manoj
--
Given its constituency, the only thing I expect to be "open" about [the
Open Software Foundation] is its mouth. -- John Gilmore
Manoj Srivastava <srivasta.RemoveThis@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Manoj Srivastava · External Since: Dec 07, 2004 Posts: 761

On Fri, Jul 24 2009, Steve Langasek wrote:

> On Thu, Jul 23, 2009 at 04:04:03PM -0500, Manoj Srivastava wrote:
>
>> >> If the answer is that we really do want it everywhere independent of
>> >> what /bin/sh is, that's fine. However, that's not obvious to me.
>
>> > As long as /bin/sh refuses extensions to posix I agree with you, but
>> > bashism has been a cuss word for years before 2004.
>
>> Source? Policy does not even ban bashims for maintainer scripts.
>
> Policy 10.4 says:
>
> If a shell script requires non-SUSv3 features from the shell
> interpreter other than those listed above, the appropriate shell must
> be specified in the first line of the script (e.g., `#!/bin/bash') and
> the package must depend on the package providing the shell (unless the
> shell package is marked "Essential", as in the case of `bash').

That is not a ban, is it?

> So bashisms are allowed in maintainer scripts only if they invoke /bin/bash
> as the interpreter.

Sounds like a recipe to allow using bash scripts.

> Or do you mean something else by "ban", here?

So, saying that people should use dpkg-shlibs, by invoking it
just so, is banning dpkg-shlibs? My head spins.

manoj
--
"Most people would rather die than think; in fact, they do so."
-Bertrand Russell
Manoj Srivastava <srivasta.DeleteThis@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Steve Langasek · External Since: Dec 13, 2004 Posts: 2140

On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:

> I think you are not going far enough. Why should I have dash on
> the system when my default shell is posh? or (gasp) zsh?

Why would you set your default shell to posh? It's only marginally smaller
than dash, and my understanding is that it's slower. It's more minimal from
a policy perspective, but I don't see that this is relevant for a live
Debian system.

What's the advantage of having it be zsh? Is zsh faster than dash? Or is
the only savings the elimination of the 84k dash binary from /bin?

> I think one of the objections here is that we ought to have a
> more generic approach that allows shells other than dash/bash to be the
> default shell, and that the vendor not make the choice.

And I think it has yet to be demonstrated that it's actually useful to
support all these other possible values of /bin/sh. Without a concrete
reason why these configurations should be supported, generalizing the
implementation is needless overhead.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek.TakeThisOut@ubuntu.com vorlon.TakeThisOut@debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Gabor Gombas · External Since: Mar 22, 2005 Posts: 154

Hi,

On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:

> I think you are not going far enough. Why should I have dash on
> the system when my default shell is posh? or (gasp) zsh?

posh (or "strict POSIX" in general) is simply not practical, and zsh is
even more bloated than bash. But this was discussed to death...

> I think one of the objections here is that we ought to have a
> more generic approach that allows shells other than dash/bash to be the
> default shell, and that the vendor not make the choice.

And a possible response to such an objection that the bash->dash
transition is difficult enough. Do this specific transition first, and
revisit the generalization only after the lessons from the bash->dash
transition have been learned.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Russ Allbery · External Since: Nov 17, 2005 Posts: 897

Steve Langasek <vorlon.DeleteThis@debian.org> writes:

> What's the advantage of having it be zsh? Is zsh faster than dash? Or
> is the only savings the elimination of the 84k dash binary from /bin?

zsh has also historically been fairly buggy in corner cases as /bin/sh and
requires explicit commands to make it Bourne-compatible. Autoconf has had
to add a bunch of workarounds for zsh as sh that I'm sure most of our
shell scripts don't have.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Manoj Srivastava · External Since: Dec 07, 2004 Posts: 761

On Fri, Jul 24 2009, Steve Langasek wrote:

> On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
>
>> I think you are not going far enough. Why should I have dash on
>> the system when my default shell is posh? or (gasp) zsh?
>
> Why would you set your default shell to posh? It's only marginally smaller
> than dash, and my understanding is that it's slower. It's more minimal from
> a policy perspective, but I don't see that this is relevant for a live
> Debian system.
>
> What's the advantage of having it be zsh? Is zsh faster than dash? Or is
> the only savings the elimination of the 84k dash binary from /bin?

It allows all the #!/bin/sh scripts that us zsh-isms to run.

>> I think one of the objections here is that we ought to have a
>> more generic approach that allows shells other than dash/bash to be the
>> default shell, and that the vendor not make the choice.
>
> And I think it has yet to be demonstrated that it's actually useful to
> support all these other possible values of /bin/sh. Without a concrete
> reason why these configurations should be supported, generalizing the
> implementation is needless overhead.

Demonstrated to whom? You see, viability of alternatives has to
be demonstrated to the decision maker. My contention is that the Vendor
ought not to be the decision maker here, that the quality of
implementation of the OS improves if the system owner or custodian has
the ability to make that determination.

In which case, proving which shell is better is taken out of the
equation, and what we have to do is support the custodian choice.

manoj
--
The whole earth is in jail and we're plotting this incredible
jailbreak. Wavy Gravy
Manoj Srivastava <srivasta DeleteThis @debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Giacomo Catenazzi · External Since: Apr 07, 2004 Posts: 30

Gabor Gombas wrote:
> Hi,
>
> On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
>
>> I think you are not going far enough. Why should I have dash on
>> the system when my default shell is posh? or (gasp) zsh?
>
> posh (or "strict POSIX" in general) is simply not practical, and zsh is
> even more bloated than bash. But this was discussed to death...
>
>> I think one of the objections here is that we ought to have a
>> more generic approach that allows shells other than dash/bash to be the
>> default shell, and that the vendor not make the choice.
>
> And a possible response to such an objection that the bash->dash
> transition is difficult enough. Do this specific transition first, and
> revisit the generalization only after the lessons from the bash->dash
> transition have been learned.

When a program will gain the essential flag, it will be forever.
So yet will need to support one shell bash. tomorrow two
shells (bash and dash). In future could we support three
shells? Note: also when upstream will stop supporting
the program (e.g. new POSIX version, etc).

The discussion is about "essential" (check the subject),
not really what shell will be the default on tomorrow
and future debian systems.

ciao
cate

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Steve Langasek <vorlon.DeleteThis@debian.org> writes:

> On Fri, Jul 24, 2009 at 12:31:09PM +0200, Goswin von Brederlow wrote:
>> >> Are you saying that your objection to engineering a solution where
>> >> dash doesn't need to be essential is that it's not worth the effort?
>> >> I *think* that was the point of your message but am not entirely sure.
>
>> > Yes, that's definitely my position. From what I can see, engineering a
>> > solution where dash doesn't need to be essential isn't worth *any* effort,
>> > because IMHO, so far the arguments for being able to remove dash from the
>> > system appear entirely contrived.
>
>> What about Manojs argument of having user scripts that (falsely) use
>> bashism and #!/bin/sh or user accounts with /bin/sh as login shell?
>
>> The proposed solution would allow the admin to choose what shell is
>> /bin/sh and even more so would keep bash as /bin/sh on existing
>> systems unless as different /bin/sh is specificaly configured.
>
> Permitting the user to choose where /bin/sh points is orthogonal to whether
> dash is Essential. There's already support for user configuration of the
> /bin/sh link, and my understanding is that the proposal actually on the
> table doesn't change that.

Where is that support? The dpkg-divert in sid dash is not suitable on
a larger scale. It is a verry limited solution.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Gabor Gombas <gombasg.RemoveThis@sztaki.hu> writes:

> Hi,
>
> On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
>
>> I think you are not going far enough. Why should I have dash on
>> the system when my default shell is posh? or (gasp) zsh?
>
> posh (or "strict POSIX" in general) is simply not practical, and zsh is
> even more bloated than bash. But this was discussed to death...
>
>> I think one of the objections here is that we ought to have a
>> more generic approach that allows shells other than dash/bash to be the
>> default shell, and that the vendor not make the choice.
>
> And a possible response to such an objection that the bash->dash
> transition is difficult enough. Do this specific transition first, and
> revisit the generalization only after the lessons from the bash->dash
> transition have been learned.
>
> Gabor

Why would you think the one transition would be helpfull in the second
or that there would be less breakage in the second if we do the first
one first? I would rather say you are doubling the problems and
breakages as the two are completly different mechanisms.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Manoj Srivastava <srivasta.RemoveThis@debian.org> writes:

> On Fri, Jul 24 2009, Steve Langasek wrote:
>> If the goal is to make *bash* removable, then I can understand why
>> that would be helpful to some people since it's the heavier shell by
>> far.
>
> Right.
>
>> None of what you're talking about in this subthread actually
>> advances that goal, however. The blocker for removing bash is that
>
> Frankly, I think you are overlooking a whole lot of things.
>
> The frst thing you need to do is to not just make bash
> removable, you need to determine of this particular user _wants_ it
> too. You can't just have a limited set of scenarios (people want lean
> /bin/sh) and not (people want all machines in their environment
> behaving closer to each other).

I actualy would like to remove bash. Dash seems to be better as
/bin/sh from what people say. And as interactive shell I use zsh. So
why waste the space with an bloated bash?

But that should be a choice. Not forced upon the user. As Manoj has
said now a few times, many things will break for users even if all of
Debian is dash fixed. By making /bin/sh choosable everybody wins.

>> today, packages invoking /bin/bash are not required by Policy to
>> depend on it. And if they did, we might find that there are Priority:
>> required packages using it, which there's no policy against, making
>> the exercise more or less pointless.
>>
>> Oh yeah - libpam0g is one, and libpam0g is transitively essential.
>
> Again the tunnel vision on packages -- there are users with
> installed bases too, which every one seems to just forget.
>
> The idea I am espousing is that we need to come up with not just
> replace bash with dash, we need to ask the user if they want to change
> the default shell, and whether the new default shell should be dash.
>
> manoj

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Vincent Lefevre · External Since: Nov 09, 2004 Posts: 419

On 2009-07-24 15:49:15 +0000, brian m. carlson wrote:
> On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote:
> > zsh has also historically been fairly buggy in corner cases as
> > /bin/sh and requires explicit commands to make it
> > Bourne-compatible. Autoconf has had to add a bunch of workarounds
> > for zsh as sh that I'm sure most of our shell scripts don't have.
>
> Actually, if it's invoked as /bin/sh, it is supposed to be
> Bourne-compatible.

I suppose that (both of) you mean POSIX-compatible (as there are
differences between the traditional Bourne shell and POSIX shells).

> That's my experience with the current version:
>
> lakeview ok % emulate; /bin/sh -c emulate
> zsh
> sh
>
> I don't know what other versions do. I'm working on finding bugs with
> zsh as /bin/sh; see #510358. If anyone knows about a good /bin/sh
> (POSIX, XSI, or Debian) testsuite, please let me know off-list.

I've also reported a number of zsh POSIX-compatibility bugs. There
are still differences between shells concerning "set -e" [*], and
AFAIK, POSIX hasn't been made clear yet. I wonder how this is dealt
with in the switch from bash to dash for /bin/sh.

[*] See http://www.in-ulm.de/~mascheck/various/set-e/

--
Vincent Lefèvre <vincent.TakeThisOut@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Peter Samuelson · External Since: Mar 29, 2005 Posts: 52

> Steve Langasek <vorlon.RemoveThis@debian.org> writes:
> > What's the advantage of having it be zsh? Is zsh faster than dash? Or is
> > the only savings the elimination of the 84k dash binary from /bin?

[Goswin von Brederlow]
> Plus the libaries dash depends on (if they differ from posh)

NEEDED libc.so.6

Oh well, guess we have a little less FUD now.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org