Switching /bin/sh to dash without dash essential

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

Folks, there was a longish discussion on IRC starting about an hour
ago about dash and bash.

I agree we want to move the default /bin/sh to /bin/dash.
However I'm failing to understand why we want dash to be essential.
If I'm not using dash as my /bin/sh why do I need it?

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.

So, a proposal for doing a switch with dash not essential.

1) all /bin/sh shells know about each other.
2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed.
3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh
4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells.

Variations:

1) You could have a registration mechanism. My assumption is the set is small enough static is good

2) I assume that package operations cannot take place between calling the prerm script and actually removing the package. If that is false, you could make sure that you are changing the link to a configured shell

I really don't mind if we go forward with the current proposal.
However, I think I and a lot of other people would appreciate clarity,
so far not expressed, about why dash needs to be essential.

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

Luk Claes · External Since: May 04, 2005 Posts: 654

Sam Hartman wrote:
>
> Folks, there was a longish discussion on IRC starting about an hour
> ago about dash and bash.
>
> I agree we want to move the default /bin/sh to /bin/dash.
> However I'm failing to understand why we want dash to be essential.
> If I'm not using dash as my /bin/sh why do I need it?
>
> 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.

We want everyone to use dash by default. 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.

> So, a proposal for doing a switch with dash not essential.
>
> 1) all /bin/sh shells know about each other.

Not going to happen AFAICS. bash does not know about any for instance.

> 2) The prerm script for a /bin/sh shell finds another /bin/sh shell and updates the symlink if the current /bin/sh link is the one being removed.

Might be possible, but currently needs a lot of work and I don't see
anyone interested to do that.

> 3) The postinst for a /bin/sh shell can update the link if it decides that the installed shell would make a better /bin/sh

'it' decides Smile

> 4) There is a package `the-shell ' that is essential and pre-depends on one of the /bin/sh shells.

This seems ugly, I would rather go for a virtual package in that case
similar to awk.

> I really don't mind if we go forward with the current proposal.
> However, I think I and a lot of other people would appreciate clarity,
> so far not expressed, about why dash needs to be essential.

You do not want to give the possibility to remove /bin/sh from the
system. Currently this is done by making the default system shell essential.

Cheers

Luk

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

Siggy Brentrup <debian DeleteThis @psycho.i21k.de> writes:

> On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote:
>
>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing Smile

The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 years are not enough to accomplish the move.
>
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>
> So you are complaining about a small package (installed size 224)
> becoming essential while forcing the embedded ppl to work around a
> monster (installed size 1236); numbers taken from my Ubuntu laptop
> where both are essential, I hope only for a limited period of time.
> Although preferring CLI over GUI I don't use both of them, I prefer
> zsh for my daily work but my #!/bin/sh scripts are always posixly
> correct.

No, complaining about replacing shackles with handcuffs.

>> 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.
>
>> So, a proposal for doing a switch with dash not essential.
>
>> 1) all /bin/sh shells know about each other.

1b) All /bin/sh shells must behave as if they where essential. They
must work while being unconfigured and so on.

>> 2) The prerm script for a /bin/sh shell finds another /bin/sh shell
>> and updates the symlink if the current /bin/sh link is the one being
>> removed.
>
>> 3) The postinst for a /bin/sh shell can update the link if it
>> decides that the installed shell would make a better /bin/sh
>
>> 4) There is a package `the-shell ' that is essential and pre-depends
>> on one of the /bin/sh shells.
>
> Maybe "posixly-correct-shell" would be a better name.
>
> Summing up you suggest making a virtual package - however it's called
> - essential. While I think I grok your intentions, I doubt dpkg
> will follow, please read carefully:
>
> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

And what exactly do you mean? Nothing in there about virtual packages.

>> Variations:
>
>> 1) You could have a registration mechanism. My assumption is the
>> set is small enough static is good
>
>> 2) I assume that package operations cannot take place between
>> calling the prerm script and actually removing the package. If that
>> is false, you could make sure that you are changing the link to a
>> configured shell

It is false afaik. You can deconfigure any number of packages before
starting to remove any of them.

>> I really don't mind if we go forward with the current proposal.
>> However, I think I and a lot of other people would appreciate clarity,
>> so far not expressed, about why dash needs to be essential.
>
> See debian-policy cited above.
>
> looking-forward-for-posixly-correct-/bin/sh-ly yours
> Siggy

Say you have only shell-1 installed to provide /bin/sh. The big
question is if apt/aptitude/synaptic/.../dpkg will ever deconfigure or
even uninstall shell-1 before it unpacks shell-2.

Can the following sequence happens?

deconfigure the-shell
deconfigure shell-1
remove shell-1
unpack shell-2
configure shell-2
configure the-shell

If this sequence ever happens then the system is without /bin/sh for a
time. Not a good idea.

I think the above is unlikely but can possibly happen and nothing in
Depends or Pre-Depends can prevent it. But the prerm script could
(should) fail if it can not find another /bin/sh provider to at least
don't make the system unusable.

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

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

>>>>> "Luk" == Luk Claes <luk.TakeThisOut@debian.org> writes:
Luk> We want everyone to use dash by default. If someone does not
Luk> want to use the default, they are free to do so, but the
Luk> default system shell is supposed to always be on the system.
Why?
I agree something should always provide /bin/sh.
I do not understand why the default system shell should be on the system always.

The only argument you've given that I understand is that no one wants
to do the work necessary to guarantee that /bin/sh is always present
and that the default system shell is not essential.
If that's the answer, that's a perfectly fine answer, but *say that*, don't just make assertions.

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

>>>>> "Siggy" == Siggy Brentrup <debian RemoveThis @psycho.i21k.de> writes:
8
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why we want dash to be
>> essential. If I'm not using dash as my /bin/sh why do I need
>> it?

Siggy> So you are complaining about a small package (installed
Siggy> size 224) becoming essential while forcing the embedded ppl
Siggy> to work around a monster (installed size 1236); numbers
Siggy> taken from my Ubuntu laptop where both are essential, I
Siggy> hope only for a limited period of time.
Hmm.
I don't get any complaint about /bin/dash being the default system shell from my mail.
Nor do you see me complaining about having /bin/sh scripts be posixly correct.

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

Siggy> As long as /bin/sh refuses extensions to posix I agree with
Siggy> you, but bashism has been a cuss word for years before
Siggy> 2004.

I don't understand how this has anything to do with anything I said.

Siggy> Maybe "posixly-correct-shell" would be a better name.

Siggy> Summing up you suggest making a virtual package -

No. I suggest a package with no files but with pre-depends and the
essential flag. I don't think a virtual package would work correctly
at a technical level, although I'd be happy to be shown to be wrong.

Siggy> however
Siggy> it's called - essential. While I think I grok your
Siggy> intentions, I doubt dpkg will follow, please read
Siggy> carefully:

Siggy> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

Read that long ago and read that word for word just now.
Can you help me understand what I'm missing?
I don't see how what I'm proposing would violate that.

>> I really don't mind if we go forward with the current proposal.
>> However, I think I and a lot of other people would appreciate
>> clarity, so far not expressed, about why dash needs to be
>> essential.

Siggy> See debian-policy cited above.

Again, please help me understand how what I propose would violate policy.

--
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 Thu, Jul 23 2009, Siggy Brentrup wrote:

> On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote:
>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing Smile

The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 years are not enough to accomplish the move.

I think because few proponents actually think through the impact
on end user machines. There are more constituencies to Debian than just
embedded users, and people write shell scritps on their own, and use
it as cron jobs, helper functions (I use a couple to handle mailto:
URI's in mozilla to fire up gnus). The impact on these systems bigger,
since there are more of them, and embedded systems end users, who can
definitely switch the link themselves.

>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>
> So you are complaining about a small package (installed size 224)
> becoming essential while forcing the embedded ppl to work around a
> monster (installed size 1236); numbers taken from my Ubuntu laptop
> where both are essential, I hope only for a limited period of time.
> Although preferring CLI over GUI I don't use both of them, I prefer
> zsh for my daily work but my #!/bin/sh scripts are always posixly
> correct.

There is a traedeoff between an embedded system, and machines
where user tools and cron jobs may break which
>
>> 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.

manoj
--
How can you be in two places at once when you're not anywhere at all?
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 Thu, Jul 23 2009, Luk Claes wrote:

> Sam Hartman wrote:
>>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>>
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>>
>> 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.
>
> 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?

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

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 kinda like the mawk/gawk solution, which has
worked. Admittedly, /bin/sh is rather more critical to get right, but I
think we have the ability to craft a solution to do so.

manoj
--
filibuster, n.: Throwing your wait around.
Manoj Srivastava <srivasta.TakeThisOut@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.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

Manoj Srivastava wrote:
> 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.

Debian Installer could in theory support this by having a default shell
(varying per-architecture even). It could also prompt the user for which
shell to use in expert mode.

The main challenge for installations would be that the default shell is
installed by debootstrap, so that would need to be extended with a
parameter to select a shell.

Problem is package priorities: can you have (pseudo) package that is
priority required which is provided by packages that are all priority
optional (which the shells would have to be to avoid them being installed
automatically by debootstrap or the standard task)?
And that would also mean that no packages of prio standard or higher can
be allowed to depend on a specific shell (as policy would make that shell
package get the same priority).

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.
Debootstrap would still need a sane default in case no shell is set
through a parameter or if the selected shell is not available for some
reason.

For switching the default shell on an installed system, something (a prerm
script shared between shell packages?) would need to check for the shell
being removed whether there are users who have it as their default shell
and what the default shell for new users is, and fail if the shell is
still in use. I also feel that this is a case where showing a debconf
dialog warning about possible consequences is appropriate.

Plenty of challenges...

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

Philipp Kern · External Since: Jun 22, 2009 Posts: 8

On 2009-07-23, Manoj Srivastava <srivasta.TakeThisOut@debian.org> wrote:
>> 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.

Surely not, it just tells you to use bash in the shebang.

"""
You may wish to restrict your script to SUSv3 features plus the above set when
possible so that it may use /bin/sh as its interpreter. If your script works
with dash (originally called ash), it probably complies with the above
requirements, but if you are in doubt, use /bin/bash.
"""

Kind regards,
Philipp Kern

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

Philipp Kern · External Since: Jun 22, 2009 Posts: 8

On 2009-07-23, Frans Pop <elendil RemoveThis @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.

Kind regards,
Philipp Kern

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

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

> Manoj Srivastava wrote:
>> 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.
>
> Debian Installer could in theory support this by having a default shell
> (varying per-architecture even). It could also prompt the user for which
> shell to use in expert mode.

Default to dash (as that seems to be prefered, or why do we have that
conversation at all?). In expert mode create a list of anything
providing posix-sh and let the user pick one.

> The main challenge for installations would be that the default shell is
> installed by debootstrap, so that would need to be extended with a
> parameter to select a shell.

Actualy the installation would be automatic through an essential
"the-shell" package that (pre-)depends on default-posix-sh |
posix-sh. Essential so it can not be removed so that its dependency
keeps at least one /bin/sh installed.

The only really new and tricky thing would be that (c)debootstrap
would need to create the /bin/sh link after unpacking. Packages can
not contain that link and maintainer scripts aren't run in debootstrap
at first. Or it needs to run the maintainer scripts of at least one
posix-sh first and that script must not use /bin/sh (but can use
/bin/itself).

> Problem is package priorities: can you have (pseudo) package that is
> priority required which is provided by packages that are all priority
> optional (which the shells would have to be to avoid them being installed
> automatically by debootstrap or the standard task)?

Isn't that exactly the mawk/gawk situation?
Essential/Required/Standard packages need awk but there is still a
choice which of the two to use. Only now we have exactly one package
(the-shell) that depends on posix-sh.

> And that would also mean that no packages of prio standard or higher can
> be allowed to depend on a specific shell (as policy would make that shell
> package get the same priority).

I think that is too strong. bash should still be standard I think. The
goal was to make it not essential so it can be removed on embedded
systems, right? On such systems you would have to have anything
(installed) depend on bash but that is their problem. It would be nice
to have nothing standard or higher depend on a specific shell but I
would not start with making that a MUST.

> 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.
> Debootstrap would still need a sane default in case no shell is set
> through a parameter or if the selected shell is not available for some
> reason.

Only one posix-sh MUST be included. Just like kernels. Everything else
will be solved by dependencies. If a shell is selected then the
the-shell package willhave its depends fullfilled already, otherwise
one will be picked to fullfill it.

I don't think including every shell on the install medium is such high
priority. After all the design here is so that one can later change
the shell too. The shells should probably be on dvd1 but having only
the major candidates on the netinst image is perfectly fine.

> For switching the default shell on an installed system, something (a prerm
> script shared between shell packages?) would need to check for the shell
> being removed whether there are users who have it as their default shell
> and what the default shell for new users is, and fail if the shell is
> still in use. I also feel that this is a case where showing a debconf
> dialog warning about possible consequences is appropriate.

That is somewhat unrelated to the issue. You can already install any
!bash shell, make it the default for some user and then purge
it. Nothing to do with the shell being /bin/sh.

> Plenty of challenges...
>
> Cheers,
> FJP

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

Ben Finney · External Since: May 12, 2005 Posts: 51

Goswin von Brederlow <goswin-v-b DeleteThis @web.de> writes:

> Frans Pop <elendil DeleteThis @planet.nl> writes:
>
> > Manoj Srivastava wrote:
> >> 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.
> >
> > Debian Installer could in theory support this by having a default
> > shell (varying per-architecture even). It could also prompt the user
> > for which shell to use in expert mode.
>
> Default to dash (as that seems to be prefered, or why do we have that
> conversation at all?).

You seem to be suggesting that having 'dash' as the default interactive
login shell is preferred. I don't think that's true.

If I understand correctly, the proposal is very much *not* about making
'dash' the default interactive login shell for the installed system, but
instead about making 'dash' the default implementation of '/bin/sh'.

--
\ "If you see an animal and you can't tell if it's a skunk or a |
`\ cat, here's a good saying to help: 'Black and white, stinks all |
_o__) right. Tabby-colored, likes a fella.'" —Jack Handey |
Ben Finney

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

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

That's scarcely more than the size *increase* in util-linux (an essential
package) between lenny and squeeze:

$ dpkg -I u/util-linux/util-linux_2.13.1.1-1_i386.deb |grep Size
Installed-Size: 1624
$ dpkg -I u/util-linux/util-linux_2.15.1~rc1-1_i386.deb |grep Size
Installed-Size: 1736
$

And in an embedded context with /usr/share/doc removed, the only impact is
/bin/dash, which weighs in at a mere 84k.

On whose behalf are you splitting these hairs, exactly?

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

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.

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

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

Ben Finney <ben+debian@benfinney.id.au> writes:

> Goswin von Brederlow <goswin-v-b.RemoveThis@web.de> writes:
>
>> Frans Pop <elendil.RemoveThis@planet.nl> writes:
>>
>> > Manoj Srivastava wrote:
>> >> 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.
>> >
>> > Debian Installer could in theory support this by having a default
>> > shell (varying per-architecture even). It could also prompt the user
>> > for which shell to use in expert mode.
>>
>> Default to dash (as that seems to be prefered, or why do we have that
>> conversation at all?).
>
> You seem to be suggesting that having ‘dash’ as the default interactive
> login shell is preferred. I don't think that's true.
>
> If I understand correctly, the proposal is very much *not* about making
> ‘dash’ the default interactive login shell for the installed system, but
> instead about making ‘dash’ the default implementation of ‘/bin/sh’.

We are only talking about /bin/sh here. Everything else is a different
matter and unrelated. And /bin/sh has nothing to do with the default
interactive login shell (on new systems).

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

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

Siggy Brentrup wrote:

>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing Smile

The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 years are not enough to accomplish the move.

So how many of the bashism bugs did you fix?

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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