On Mon, 21 Mar 2016, Robert Elz wrote:
I sent a message to tech-userlevel a week or so ago, asking about a few
things that I was considering changing in NetBSD's sh (which can't be
categorised really as being bug fixes), but got no response...
For some of them, that's no great surprise, they are fairly minor, and
of little consequence.
But for one, I would really like to hear some opinions, and not just
do whatever I think is best, and then get complaints later...
Most shells (but not all, and the "not" currently includes NetBSD's shell)
have some internal pre-defined variable (that is, can be used in scripts as
$VAR - I am not talking about the C code) which can be used to identify the
shell that is in use.
Bash has BASH and BASH_VERSION (and more) ksh has KSH_VERSIOn, zsh has a
whole
bunch of ZSH_* vars.
I want to do a similar thing for NetBSD's sh. That leads to two
questions.
1) what name should the variable have? (I am currently using NBSD_SHELL,
but there is no particular importance in that name.)
Given the (very) slight preponderence above for xxx_VERSION, why not use
NBSD_VERSION?
2) what value should it have? I am expecting it will be a read-only var.
Hmmm. Start with "1.0" and increment when "appropriate"?
There is not much more to say about Q1, provided the name meets the sh
var name syntax rules, anything goes...
For 2, I would like to include some version identification (and possibly
simply be that version info).
The shell version should/would be separate from system version, right? We can
always use uname(1) for OS version.
Sidebar: perhaps the shell version could be used as a proxy for the
"userland version" to detect userland/kernel mismtaches?
Currently, the NetBSD shell is just "it", it has no name (but sh) and
no version info (other than "the sh in NetBSD 7.0" or "the sh from current
as of 2016-03-21" or something.
When the current round of improvements are done, I'd like to put the NetBSD
shell in pkgsrc/shells so others can get the benefits of what is becoming
quite a good shell I think - and for that (to be easy to maintain anyway)
we also need a version numbering scheme.
What I am thinking for this, is that we create 3 segment version numbers,
N.M.P where "N.M" is the netbsd release the shell started at (so the
NetBSD 7.0 shell would have had N=7 and M=0 had this scheme existed when
it was released. P is to be a patchlevel counter that gets incremented
whenever there are changes made that are significant enough to warrant
calling it a new version - and certainly every time a new vresion is
released to pkgsrc). Just like NetBSD version numbers, M==99 implies
"current" on he way to version N+1. Note that P in the shell version
numbering would have no relationship at all with the third value in
NetBSD version numbers, so NetBSD 7.0.1 7.0.2 ... would all just have a
"7.0.P" shell version number, with whatever value is appropriate for P
(possibly all just 0).
For now, I am using 7.99.1 as my version number - as I am doing all of
this to the NetBSD current (7.99) shell, and 7.99.0 would be the shell
that is there immediately before this version number shceme is implemented
(and all previous versions... there have been many recently.)
for reference, using my current version of NetBSD's sh (not yet available
anywhere but on my laptop) I get ...
$ echo $NBSD_SHELL
7.99.1
$
So, I am seeking opinions, is all of this reasonable, what name should be
used, and what value (and about the version numbering scheme in general?)
kre
ps: whatever is decided for this (other than "forget it") I expect to be
a permanent change, I don't think we should implement and release one thing
only to change it a month or two (or more) later. Once released, that
will
be it, so get your opinions in before that happens.
+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+
!DSPAM:56ef9a8f247644170213937!