#764172 dash: consider providing a DASH_VERSION variable

Package:
dash
Source:
dash
Description:
POSIX-compliant shell
Submitter:
Mike Miller
Date:
2025-01-13 09:18:02 UTC
Severity:
wishlist
Tags:
#764172#5
Date:
2014-10-06 02:50:55 UTC
From:
To:
Dear Maintainer,

On a Debian system, the only way to determine the version of the dash
shell is to ask dpkg. The program itself has no way to report its
version.

It would be nice if dash provided a DASH_VERSION readonly variable. All
other shells I have installed and tested provide a way to query their
version (and to indicate that it is a particular shell, which may also
be of interest to the user):

  $ bash -c 'echo $BASH_VERSION'
  4.3.25(1)-release
  $ mksh -c 'echo $KSH_VERSION'
  @(#)MIRBSD KSH R50 2014/09/03
  $ posh -c 'echo $POSH_VERSION'
  0.12.3
  $ zsh -c 'echo $ZSH_VERSION'
  5.0.6

The following patch works for me to define DASH_VERSION as a readonly
parameter.
From: Mike Miller <mtmiller@debian.org>
Date: Sun, 5 Oct 2014 22:19:11 -0400
Subject: [PATCH] [VAR] Define DASH_VERSION as a readonly variable

Signed-off-by: Mike Miller <mtmiller@debian.org>
---
 src/var.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/var.c b/src/var.c
index fa24854..c0c560e 100644
--- a/src/var.c
+++ b/src/var.c
@@ -84,6 +84,8 @@ const char defifs[] = " \t\n";
 int lineno;
 char linenovar[sizeof("LINENO=")+sizeof(int)*CHAR_BIT/3+1] = "LINENO=";

+const char versionvar[] = "DASH_VERSION=" PACKAGE_VERSION;
+
 /* Some macros in var.h depend on the order, add new variables to the end. */
 struct var varinit[] = {
 #if ATTY
@@ -108,6 +110,7 @@ struct var varinit[] = {
 	{ 0,	VSTRFIXED|VTEXTFIXED|VUNSET,	"TERM\0",	0 },
 	{ 0,	VSTRFIXED|VTEXTFIXED|VUNSET,	"HISTSIZE\0",	sethistsize },
 #endif
+	{ 0,	VSTRFIXED|VTEXTFIXED|VREADONLY,	versionvar,	0 },
 };

 STATIC struct var *vartab[VTABSIZE];
#764172#10
Date:
2025-01-12 18:41:54 UTC
From:
To:
We (the developers of Midnight Commander) would also find DASH_VERSION to be a useful inclusion. Thanks!
#764172#15
Date:
2025-01-12 19:29:41 UTC
From:
To:
Hello,

Why do you find it useful? What would be the purpose of it? Dash is supposed to be POSIX-compatible, so there isn’t a need for feature detection as with bash or zsh, and I don’t think the version of dash itself is a useful indicator of particular features being available or not.

I am definitely not going to add this in a Debian-specific patch.
If you’re interested in having this feature, please talk to the upstream. I’m not going to do that, since I disagree with this addition for the reasons I outlined above.
#764172#22
Date:
2025-01-12 19:45:44 UTC
From:
To:
We use these variables in our shell detection code to disambiguate between different shells with the same name. In this case, we want to differentiate Dash from Busybox ASH. If ash is symlinked to dash we can use that, but if not, we could check for DASH_VERSION variable. The reason why we want to disambiguate the two is this “supposed” word in your sentence about POSIX compatibility ;-)

Well, no big deal... Busybox has added BB_ASH_VERSION some years ago, so whatever is called ash and doesn’t advertise BB_ASH_VERSION must be Dash… or an old version of Busybox ASH - thus in a few years the problem will definitively resolve itself.

Also, I thought that you are somehow in touch with upstream and can forward Debian stuff to them - or maybe it’s even being developed under the auspices of Debian now (as in D for Debian?). I tried to reach them awhile ago asking for HISTCONTROL implementation via some Australian mailing list, which was supposedly the right point of contact. Unfortunately, all I’ve got was a resounding silence, so I don’t know if the project is even maintained at all. So I’ve got an impression that maybe Debian tracker is the right way to talk to upstream, which it obviously doesn’t seem to be.

Anyways, good to have this bug taken care of in one way or another. Thanks!

All the best,
Yury
#764172#27
Date:
2025-01-12 19:57:14 UTC
From:
To:
Hello,

The website of the upstream is <http://gondor.apana.org.au/~herbert/dash/>, the mailing list lives at vger: <https://lore.kernel.org/dash/>.
#764172#32
Date:
2025-01-12 20:18:41 UTC
From:
To:
Dash does not support escape sequences like \u, \w, \h in the prompt, while Busybox ASH does support them, so we need to be able to tell one from another.

Oh, I see - so I did use the right list after all, which seems to be alive - it’s just that apparently upstream doesn’t care about HISTCONTROL. Thanks for the clarification, I wasn’t around for *that* long.

All the best,
Yury
#764172#37
Date:
2025-01-12 20:59:54 UTC
From:
To:
Hello,

At least in Debian, dash is primarily a shell for scripts, not for interactive use. (That’s also why we don’t enable libedit.)
So some escape sequences not being available in the prompt are not of a huge concern for us.
I think the same can be said about HISTCONTROL.
#764172#42
Date:
2025-01-13 09:14:48 UTC
From:
To:
I’m not trying to tell you that Debian is doing anything wrong, but rather explaining why we need these features. Apparently, a number of Debian users think it’s a good idea to use dash as a login shell. Generally, we try to support all subshells at least to some minimal degree. Then they discover that our internal shell communication clobbers their history, and the prompt is not displayed correctly. The prompt issue can be resolved if we can tell Dash apart from Busybox ASH, but we can’t do anything about the history thing unless Dash implements something that would allow certain commands to be left out of the history file… So our answer for now is to suggest using another shell and fixing the prompt by telling ash-es apart from each other.

All the best,
Yury