Re: "dpkg-reconfigure" dash no longer works

[Kushal Kumaran]

On Fri, Jun 09 2023 at 01:38:25 PM, S M <mythr...@hotmail.com> wrote:
> Good day.
>
> I noticed on a newly installed system with Debian 12 that
> dpkg-reconfigure no longer allows to switch the /bin/sh symlink from
> dash to bash. This is apparently intentional as per the following:
>
> https://launchpad.net/debian/+source/dash/0.5.11+git20210903+057cd650a4ed-4
>
> I couldn't find any additional context or rationale. I would like to
> know if this is going to be a permanent change. Debian currently
> disables command line editing in dash builds, so that makes it
> unusable as an interactive shell.
>
> Thank you very much for everything.

>From the comments on
https://salsa.debian.org/debian/dash/-/commit/c322a1c9fc6be11d7eb4439407c0a398aba8bbb7,
this is intentional and permanent. /bin/sh pointing to bash is no
longer supported. Change your login shell to bash, if that's what you
want, using chsh.

--
regards,
kushal

[Greg Wooledge]

On Fri, Jun 09, 2023 at 07:20:29AM -0700, Kushal Kumaran wrote:
> >From the comments on
> https://salsa.debian.org/debian/dash/-/commit/c322a1c9fc6be11d7eb4439407c0a398aba8bbb7,
> this is intentional and permanent. /bin/sh pointing to bash is no
> longer supported.

Huh. Well, that's rather important, isn't it?

The package maintainers seem to have forgotten to TELL us this, at least
in the NEWS.Debian.gz file, which still says only:

unicorn:/usr/share/doc/dash$ zless NEWS.Debian.gz
dash (0.5.5.1-2.1) unstable; urgency=low

* The default system shell (/bin/sh) has been changed to dash for
new installations. When upgrading existing installations, the
system shell will not be changed automatically.
* One can see what the current default system shell on this machine
is by running 'readlink /bin/sh'.
* Change it by running 'dpkg-reconfigure dash'.

-- Luk Claes <l...@debian.org> Wed, 22 Jul 2009 17:23:20 +0200


I've updated the wiki, so at least we have that much warning for users,
not that many people will read it.

[Charles Curley]

On Fri, 9 Jun 2023 13:38:25 +0000
S M <mythr...@hotmail.com> wrote:

> I noticed on a newly installed system with Debian 12 that
> dpkg-reconfigure no longer allows to switch the /bin/sh symlink from
> dash to bash.

You can still change it manually (rm ; ln -s).

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[The Wanderer]

On 2023-06-09 at 12:00, Charles Curley wrote:

> On Fri, 9 Jun 2023 13:38:25 +0000
> S M <mythr...@hotmail.com> wrote:
>
>> I noticed on a newly installed system with Debian 12 that
>> dpkg-reconfigure no longer allows to switch the /bin/sh symlink from
>> dash to bash.
>
> You can still change it manually (rm ; ln -s).

Or just 'ln -sf', to do it in something closer to an atomic fashion.

Except that, since (at least from what I can see on a quick check) the
/bin/sh symlink appears to be shipped explicitly in the dash package,
next time that package gets upgraded the symlink will probably be
overwritten with one pointing back to dash again.

If the system is smart enough to not replace a sysadmin-edited symlink
during package upgrade, then that wouldn't happen - but I'd honestly
expect that it would, since otherwise if a symlink got messed up and
broke things, reinstalling the package it came from wouldn't be
guaranteed to fix those things.

Of course, there's still the question of the *reason* why this change
was made and why using anything but dash for /bin/sh is now considered
no longer supported. I don't have any explanation for that, and until
the maintainers actually give one, neither do the rest of us - but in
the absence of one, it's hard to be sure that pointing the symlink to
/bin/bash won't break something.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[didier gaumet]

Le 09/06/2023 à 15:38, S M a écrit :
> Good day.
>
> I noticed on a newly installed system with Debian 12 that dpkg-reconfigure no longer allows to switch the /bin/sh symlink from dash to bash. This is apparently intentional as per the following:
>
> https://launchpad.net/debian/+source/dash/0.5.11+git20210903+057cd650a4ed-4
>
> I couldn't find any additional context or rationale. I would like to know if this is going to be a permanent change. Debian currently disables command line editing in dash builds, so that makes it unusable as an interactive shell.
>
> Thank you very much for everything.
>

Hello,

This is explained in the wiki:
- dash is the Debian default non-interactive shell for speed and
compliance to standard (setup of /bin/sh)
- bash is the Debian default interactive shell for ease of use (setup of
/etc/adduser.conf)

https://wiki.debian.org/Shell

[Greg Wooledge]

On Fri, Jun 09, 2023 at 08:20:52PM +0200, didier gaumet wrote:
> Le 09/06/2023 à 15:38, S M a écrit :
> > I noticed on a newly installed system with Debian 12 that dpkg-reconfigure no longer allows to switch the /bin/sh symlink from dash to bash. This is apparently intentional as per the following:

> This is explained in the wiki:
> - dash is the Debian default non-interactive shell for speed and compliance
> to standard (setup of /bin/sh)
> - bash is the Debian default interactive shell for ease of use (setup of
> /etc/adduser.conf)

Nothing you wrote here is incorrect, but none of it explains the policy
change that has occurred. I won't even say it's a bad policy change.
It makes at least a little bit of sense...

... but it should not have come as a *surprise* 2 days before the release.

... and it should not be missing from the dash package's NEWS file.

> https://wiki.debian.org/Shell

Another wiki page that I'll need to look at and possibly edit. Thanks.

[songbird]

Greg Wooledge wrote:
...

> Huh. Well, that's rather important, isn't it?
>
> The package maintainers seem to have forgotten to TELL us this, at least
> in the NEWS.Debian.gz file, which still says only:
>
> unicorn:/usr/share/doc/dash$ zless NEWS.Debian.gz
> dash (0.5.5.1-2.1) unstable; urgency=low
>
> * The default system shell (/bin/sh) has been changed to dash for
> new installations. When upgrading existing installations, the
> system shell will not be changed automatically.
> * One can see what the current default system shell on this machine
> is by running 'readlink /bin/sh'.
> * Change it by running 'dpkg-reconfigure dash'.
>
> -- Luk Claes <l...@debian.org> Wed, 22 Jul 2009 17:23:20 +0200

did you notice the date? that's some time ago... which
might be why it wasn't thought of as a change for now.

i vaguely recall this.

> I've updated the wiki, so at least we have that much warning for users,
> not that many people will read it.

songbird

[Greg Wooledge]

On Fri, Jun 09, 2023 at 05:45:04PM -0500, S M wrote:
> Regarding a workaround, I ended up creating a symlink /usr/local/bin/sh
> pointing to bash and chsh to that.

Why? Why not simply chsh to /bin/bash if that's what you want as your
interactive shell?

Are you somehow relying on bash's disabling of certain features when
invoked as "sh", in interactive mode? I don't understand that at all.

[Darac Marjal]

On 10/06/2023 01:32, S M wrote:

> Yes. POSIX-compliance is a feature to me. I'd actually be fine with
> using dash itself but the lack of command line editing and filename
> completion is a deal-breaker to me.
Is command-line editing part of POSIX, then? Are you suggesting that
dash is missing some bit of POSIX compliance? That's possible.

[Greg Wooledge]

There's no point debating any further. S M has a unique desire, which
is not shared by any other person I've ever heard of, and they're going
to do what they want.

[gene heskett]

On 6/9/23 20:33, S M wrote:
> On Fri, Jun 09, 2023 at 08:00:51PM -0400, Greg Wooledge wrote:

> Yes. POSIX-compliance is a feature to me. I'd actually be fine with
> using dash itself but the lack of command line editing and filename
> completion is a deal-breaker to me.
>

> .
+10 (or more)

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[Sven Joachim]

On 2023-06-09 12:06 -0400, The Wanderer wrote:

> On 2023-06-09 at 12:00, Charles Curley wrote:
>
>> On Fri, 9 Jun 2023 13:38:25 +0000
>> S M <mythr...@hotmail.com> wrote:
>>
>>> I noticed on a newly installed system with Debian 12 that
>>> dpkg-reconfigure no longer allows to switch the /bin/sh symlink from
>>> dash to bash.
>>
>> You can still change it manually (rm ; ln -s).
>
> Or just 'ln -sf', to do it in something closer to an atomic fashion.
>
> Except that, since (at least from what I can see on a quick check) the
> /bin/sh symlink appears to be shipped explicitly in the dash package,
> next time that package gets upgraded the symlink will probably be
> overwritten with one pointing back to dash again.
>
> If the system is smart enough to not replace a sysadmin-edited symlink
> during package upgrade, then that wouldn't happen - but I'd honestly
> expect that it would, since otherwise if a symlink got messed up and
> broke things, reinstalling the package it came from wouldn't be
> guaranteed to fix those things.

That is true. However, you can avoid that by diverting the /bin/sh
symlink which tells dpkg to unpack it under a different name. To do so,
you have to first remove the diversion that dash itself sets up. The
following six commands change the /bin/sh symlink permanently to bash
and also take care of the manpage:

# dpkg-divert --remove --no-rename /usr/share/man/man1/sh.1.gz
# dpkg-divert --remove --no-rename /bin/sh
# ln -sf bash.1.gz /usr/share/man/man1/sh.1.gz
# ln -sf bash /bin/sh
# dpkg-divert --add --local --no-rename /usr/share/man/man1/sh.1.gz
# dpkg-divert --add --local --no-rename /bin/sh

The version of dash in experimental no longer diverts the /bin/sh
symlink itself, so in the future the first two steps will not be
necessary. The dash maintainer wanted to include this change in
bookworm, but was turned down by the release team[1].

> Of course, there's still the question of the *reason* why this change
> was made and why using anything but dash for /bin/sh is now considered
> no longer supported. I don't have any explanation for that, and until
> the maintainers actually give one, neither do the rest of us - but in
> the absence of one, it's hard to be sure that pointing the symlink to
> /bin/bash won't break something.

Unfortunately neither the Debian changelog of dash nor the commit
message for this change[2] give an explanation. Removing the debconf
handling certainly simplifies the package, and there are not too many
scripts around that start with "#!/bin/sh" and fail to work with dash -
these are the reasons I can think of.

There is also an open bug against the release notes[3] filed by the dash
maintainer.

Cheers,
Sven

1. https://bugs.debian.org/1035745
2. https://salsa.debian.org/debian/dash/-/commit/c322a1c9fc6be11d7eb4439407c0a398aba8bbb7
3. https://bugs.debian.org/1036907

[Greg Wooledge]

On Sat, Jun 10, 2023 at 09:21:19PM +0200, Sven Joachim wrote:
> Unfortunately neither the Debian changelog of dash nor the commit
> message for this change[2] give an explanation. Removing the debconf
> handling certainly simplifies the package, and there are not too many
> scripts around that start with "#!/bin/sh" and fail to work with dash -
> these are the reasons I can think of.

I have serious doubts about that. I'm sure that *in Debian*, virtually
all scripts have been fixed to use the correct syntax for their shebang.
But outside of Debian? The world's a mess. There's no way to even know
how many broken scripts are out there.

An admin's choice to use /bin/sh -> bash on their system is usually done
to work around broken third-party scripts. (This is what's so confusing
about S M's part of the thread -- their motivation is entirely different.)

At the bare minimum, this change needs to be documented in the official
release notes and the dash NEWS file, which is currently giving incorrect
information to users.

It would also be *nice* to have an explanation, and perhaps some risk
analysis about what may happen if an admin decides to change the symlink
despite the unsupported nature of that change.

I suspect we'll only get the latter from users who are brave enough to
try it, and dedicated enough to document their discoveries.

[Darac Marjal]

On 10/06/2023 16:08, S M wrote:
> On Sat, Jun 10, 2023 at 02:12:14PM +0100, Darac Marjal wrote:
>

>> Is command-line editing part of POSIX, then? Are you suggesting that dash is
>> missing some bit of POSIX compliance? That's possible.

> Command-line editing in vi-mode is defined by POSIX, but it's not mandatory as
> far as I know.
>
OK, this looks like Bug #561663. If I read that bug correctly, the
intention IS that dash should support command-line editing (in your
case, you'd invoke it with -V for vi-style editing. The maintainer
claimed the block was closed, but then they re-opened it two days later.

[Linux-Fan]

Interesting. I am also one of the niche users interested in running dash as
a primary shell with vi-style line editing.

Last time I tried it (must be several years ago already), the vi-style
editing did indeed work when enabled with `set -o vi`. On my current Debian
oldstable (bullseye) workstation it does not work anymore.

Back when the vi-style editing worked it was _almost_ ready for "productive"
use. Unfortunately, POSIX shells do not support bash's `\[` and `\]` in
prompts that can be used to hide color code sequences from being counted
towards the prompt length. This caused there to be a discrepancy between the
observed and computed lengths leading to erratic line editing whenever the
line exteeded the width of the window (happens often for me).

Hence I concluded that while it sounds nice to switch to `sh` as the primary
shell in theory, this does not quite work in practice (for me anyways).

YMMV
Linux-Fan

öö