Switching /bin/sh to dash without dash essential

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

Peter Samuelson <peter.TakeThisOut@p12n.org> writes:

>> Steve Langasek <vorlon.TakeThisOut@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.

And what if my posh is compiled against uclibc? You never know.
For embedded systems that is not too far fetched.

MfG
Goswin

--
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

[not replying off-list because that seems counterproductive and arrogant]

On Fri, Jul 24, 2009 at 03:49:15PM +0000, brian m. carlson wrote:
> Actually, if it's invoked as /bin/sh, it is supposed to be
> Bourne-compatible. That's my experience with the current version:

Not much effort is put into strict POSIX compliance, though people
certainly do complain about it[1].

> 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'd certainly welcome improvements to the posh testsuite to that end.
Run the harness with category 'debian' or 'posix' depending on which
"standard" you're going for.

[1] http://www.zsh.org/mla/workers/2009/msg00881.html

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

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

On Fri, Jul 24, 2009 at 06:31:59PM +0200, Goswin von Brederlow wrote:

> 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.

Making the shell selectable means more code than hardcoding a single
string. More code means more bugs. Since a bug in this case can result
in an unbootable system, doing things one step at a time so you only
have to look for bugs in one component at a time makes perfect sense
IMHO.

Gabor

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

--
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 10:38:51AM -0500, Manoj Srivastava wrote:
> 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.

They can already be run under #!/bin/zsh. Why would we want to tie our
hands even further as a distribution by putting ourselves in the position of
having end users deploying /bin/sh scripts that require zsh, *in addition*
to the end users who already deploy /bin/sh scripts that require bash?

> > 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.

I propose to turn /usr/bin/make into an alternative so that Debian is not
robbing users of the ability to decide they want it to point to pmake.

--
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.RemoveThis@ubuntu.com vorlon.RemoveThis@debian.org

--
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 09:15:43PM +0200, Goswin von Brederlow wrote:
> And what if my posh is compiled against uclibc? You never know.
> For embedded systems that is not too far fetched.

The embedded system developers could just as easily build dash against
uclibc instead of posh.

Stop being difficult.

--
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

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

Clint Adams wrote:
> [not replying off-list because that seems counterproductive and arrogant]
>
> On Fri, Jul 24, 2009 at 03:49:15PM +0000, brian m. carlson wrote:
>> Actually, if it's invoked as /bin/sh, it is supposed to be
>> Bourne-compatible. That's my experience with the current version:
>
> Not much effort is put into strict POSIX compliance, though people
> certainly do complain about it[1].
>
>> 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'd certainly welcome improvements to the posh testsuite to that end.
> Run the harness with category 'debian' or 'posix' depending on which
> "standard" you're going for.

BTW Linux is not POSIX. Linux (LSB) has few incompatible rules.
Check the join working document austin (POSIX) and LSB:

http://www.opengroup.org/platform/single_unix_specification/doc.tpl?CA...R=index

Personal opinion: it seems that linux will do some changes to be more
posix compatible, but for most of incompatibilities (IMHO) POSIX will
change toward linux.

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

Andreas Metzler · External Since: Nov 08, 2004 Posts: 392

Clint Adams <schizo.RemoveThis@debian.org> wrote:
[...]
> 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

Hello,

FWIW the $(...) construct is not a bashism.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--
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-25 09:53:06 +0200, Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 10:38:51AM -0500, Manoj Srivastava wrote:
> > On Fri, Jul 24 2009, Steve Langasek wrote:
> > > 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.
>
> They can already be run under #!/bin/zsh. Why would we want to tie
> our hands even further as a distribution by putting ourselves in the
> position of having end users deploying /bin/sh scripts that require
> zsh, *in addition* to the end users who already deploy /bin/sh
> scripts that require bash?

I don't know what Manoj had in mind exactly, but he hasn't said that
zsh would be required. Think about something like that:

#!/bin/sh
if test -n "$ZSH_VERSION"; then
foo="$HOME:t"
else
foo="..." <- slower version for generic POSIX shells
fi

--
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

Raphael Geissert · External Since: Mar 11, 2009 Posts: 8

Goswin von Brederlow wrote:
> 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.
>

Who said anything about not offering the user to choose what /bin/sh points
to?
Nobody.

Cheers,
Raphael Geissert

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

Bernd Eckenfels · External Since: May 21, 2009 Posts: 5

In article <2qrqj6-973.ln1.TakeThisOut@argenau.downhill.at.eu.org> you wrote:
>> if [ -n "$idl" ] && [ -x $idl ]; then

This misses quotes.

Greetings
Bernd

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

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

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

> On Fri, Jul 24, 2009 at 06:31:59PM +0200, Goswin von Brederlow wrote:
>
>> 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.
>
> Making the shell selectable means more code than hardcoding a single
> string. More code means more bugs. Since a bug in this case can result
> in an unbootable system, doing things one step at a time so you only
> have to look for bugs in one component at a time makes perfect sense
> IMHO.
>
> Gabor

But having the string hardcoded to /bin/bash or to /bin/dash makes
absolutely no difference later when it comes to making it selectable.
You get exactly the same bugs then and you also get the bugs now for
changing the hardcoded string.

It is not doing things a step at a time. It is taking one step to the
right and then taking a step forward. Steping to the right first
doesn't move you forward at all.

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

Raphael Geissert <atomo64+debian@gmail.com> writes:

> Goswin von Brederlow wrote:
>> 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.
>>
>
> Who said anything about not offering the user to choose what /bin/sh points
> to?
> Nobody.
>
> Cheers,
> Raphael Geissert

Then where is that choice? How will it be done?

The proposal has shown one way of doing it.

The existing dash package uses dpkg-divert, which is unsuitable on a
larger scale (larger than the one dash package). And to have bash
removable dash has to force itself as /bin/sh. So there goes even that
little choice.

What alternative do you speak off where the user will have a choice of
what is /bin/sh?

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

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

[Bernd Eckenfels]
> >> if [ -n "$idl" ] && [ -x $idl ]; then
>
> This misses quotes.

So, how many unsafe characters do _you_ see in the following service
names?

apache2-common at bayonne cherokee courier-authdaemon cron cups
dante-server diald dovecot-common exim exim4-base fcron
fireflier-server freeradius gdm heartbeat heartbeat-2
hylafax-server iiimf-server inn2 kannel linesrv linesrv-mysql
lsh-server muddleftpd netatalk nuauth partimage-server perdition
pgpool popa3d postgresql-7.4 postgresql-8.1 postgresql-8.2 proftpd
pure-ftpd pure-ftpd-ldap pure-ftpd-mysql pure-ftpd-postgresql
racoon samba sasl2-bin sfs-server solid-pop3d squid squid3 tac-plus
vsftpd wu-ftpd wzdftpd xrdp yardradius yaws
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

--
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

Philipp Kern <trash.DeleteThis@philkern.de> writes:

> On 2009-07-25, Goswin von Brederlow <goswin-v-b.DeleteThis@web.de> wrote:
>> The existing dash package uses dpkg-divert, which is unsuitable on a
>> larger scale (larger than the one dash package). And to have bash
>> removable dash has to force itself as /bin/sh. So there goes even that
>> little choice.
>>
>> What alternative do you speak off where the user will have a choice of
>> what is /bin/sh?
>
> I don't see us supporting anything else than dash and bash for /bin/sh
> for squeeze. So the current solution is acceptable. You can try to
> prove me wrong, of course. But someone would need to collect the
> falling out pieces when /bin/sh is switched to something they want
> to see supported (and commit to that).

But can you see that some other option would be possible in the
future? That someone might want to try something else as /bin/sh and
start fixing the bugs that causes?

I do feel that that is a possibility and we should not go from being
locked into bash being essential and /bin/sh to being locked into dash
being essential and /bin/sh. That is what it is all about.

> zsh is certainly not suitable for /bin/sh, sorry.
>
> Kind regards,
> Philipp Kern
>
> PS: I do use zsh as user shell, though and would like to thank for his
> work on that. Wink

Never said it would. Doubt it will be in the near future. Far more
likely would be posh or busybox. But you never know.

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

Frans Pop · External Since: May 04, 2006 Posts: 460

Philipp Kern wrote:
> On 2009-07-23, Frans Pop <elendil.DeleteThis@planet.nl> wrote:
>> In addition all shells supported as defaults would need to be included
>> on CD images. And the selected shell would of course have to be set as
>> the default for new users.
>
> Strike the "of course". If I want my users to have zsh as a default
> that's different from the question where I want to point my /bin/sh to.

You're correct of course. If we want to go this way there should be two
questions: one for the system shell to use and one for the default user
shell, each with per-arch defaults.

From the discussion there seem to be three groups:
- embedded: want to have only a single, lightweight shell installed for
both system and users;
- generic: want a fast system shell, but a more powerful shell for users;
- conservative: don't want to run any risk with script incompatibilities
and thus want to have the same, powerful shell for system and users.

It seems to me all three are valid.

--
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

Frans Pop <elendil.DeleteThis@planet.nl> writes:

> Philipp Kern wrote:
>> On 2009-07-23, Frans Pop <elendil.DeleteThis@planet.nl> wrote:
>>> In addition all shells supported as defaults would need to be included
>>> on CD images. And the selected shell would of course have to be set as
>>> the default for new users.
>>
>> Strike the "of course". If I want my users to have zsh as a default
>> that's different from the question where I want to point my /bin/sh to.
>
> You're correct of course. If we want to go this way there should be two
> questions: one for the system shell to use and one for the default user
> shell, each with per-arch defaults.
>
> From the discussion there seem to be three groups:
> - embedded: want to have only a single, lightweight shell installed for
> both system and users;
> - generic: want a fast system shell, but a more powerful shell for users;
> - conservative: don't want to run any risk with script incompatibilities
> and thus want to have the same, powerful shell for system and users.
>
> It seems to me all three are valid.

Hear hear. That sums it up nicely.

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

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

On Sun, Jul 26 2009, Frans Pop wrote:

> You're correct of course. If we want to go this way there should be two
> questions: one for the system shell to use and one for the default user
> shell, each with per-arch defaults.
>
> From the discussion there seem to be three groups:
> - embedded: want to have only a single, lightweight shell installed for
> both system and users;
> - generic: want a fast system shell, but a more powerful shell for users;
> - conservative: don't want to run any risk with script incompatibilities
> and thus want to have the same, powerful shell for system and users.
>
> It seems to me all three are valid.

+1.

Though I would say that there are other reasons than risk
aversion for the last preference, for example having a heterogeneous
development environment where the other Linux boxes all use bash as
bin/sh

manoj
--
Better to be nouveau than never to have been riche at all.
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 Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote:
> You're correct of course. If we want to go this way there should be two
> questions: one for the system shell to use and one for the default user
> shell, each with per-arch defaults.

Do you really think that the latter warrants a question? Admins can set
their own policies by wrapping adduser; derivers can set their own policies
by modifying the adduser package.

> From the discussion there seem to be three groups:
> - embedded: want to have only a single, lightweight shell installed for
> both system and users;
> - generic: want a fast system shell, but a more powerful shell for users;
> - conservative: don't want to run any risk with script incompatibilities
> and thus want to have the same, powerful shell for system and users.

> It seems to me all three are valid.

Has anyone actually said in this thread that "I'm developing an embedded
system and I want the user shell to be dash"? dash is a terrible user
shell, after all.

Otherwise, yes, these are all valid cases, but I don't think that's really
been a point of contention here; the only contention has been:

- which configuration is the default?
- do we need to generalize beyond dash and bash to meet these use cases?

--
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

Frans Pop · External Since: May 04, 2006 Posts: 460

Steve Langasek wrote:
> On Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote:
>> You're correct of course. If we want to go this way there should be two
>> questions: one for the system shell to use and one for the default user
>> shell, each with per-arch defaults.
>
> Do you really think that the latter warrants a question? Admins can set
> their own policies by wrapping adduser; derivers can set their own
> policies by modifying the adduser package.

I'm not sure. I merely wanted to explore the options. But it does seem to
me that the ability to select the system and user shell at installation
time could be a nice feature for advanced users.

I think that quite a few sites may want to stick with the "single shell to
avoid the risk of incompatibilities" option that Manoj put forward. So
selecting the system shell makes a lot of sense to me.

I'm less sure whether the option of selecting the user shell is really
needed as well, but if you do one then supporting the other as well is
probably not all that much more work.

>> From the discussion there seem to be three groups:
>> - embedded: want to have only a single, lightweight shell installed for
>> both system and users;
>> - generic: want a fast system shell, but a more powerful shell for
>> users;
>> - conservative: don't want to run any risk with script
>> incompatibilities and thus want to have the same, powerful shell for
>> system and users.
>
>> It seems to me all three are valid.
>
> Has anyone actually said in this thread that "I'm developing an embedded
> system and I want the user shell to be dash"? dash is a terrible user
> shell, after all.

No, they have said "I'm developing an embedded system and I only want dash
installed". Whether that means the system has no users (or at least shell
using ones) at all, or they'll use dash for the (probably limited) tasks,
or they want to use some other shell as user shell I don't know.
But in all three cases they want the option of not installing bash as user
shell, which could be facilitated by a question.

> Otherwise, yes, these are all valid cases, but I don't think that's
> really been a point of contention here; the only contention has been:
>
> - which configuration is the default?
> - do we need to generalize beyond dash and bash to meet these use cases?

That is indeed the discussion. My thoughts regarding D-I and debootstrap
are IMO an extention of the first question: how flexible do we want the
default to be.

Cheers,
FJP

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