Re: Identifying the NetBSD shell

2016-03-26 Thread Robert Elz
Date:Mon, 21 Mar 2016 14:42:21 -0400 From:Thor Lancelot Simon Message-ID: <20160321184221.ga17...@panix.com> | I strongly agree. How about just giving it a date rather than a version | number? That seems to be the most popular suggestion, and

Re: Identifying the NetBSD shell

2016-03-22 Thread Christos Zoulas
In article <82ebf125-6f26-400a-8f22-c6836b810...@nimenees.com>, Eric Haszlakiewicz wrote: >On March 21, 2016 11:08:50 PM EDT, Kamil Rytarowski wrote: >>> if a script wants to know if it can safely redirect file >>> descriptors >= 10 (answer for NetBSD right now

Re: Identifying the NetBSD shell

2016-03-22 Thread Robert Elz
| Date:Tue, 22 Mar 2016 14:03:18 +0100 | From:Joerg Sonnenberger | Message-ID: <20160322130318.gb10...@britannica.bec.de> | | | I'm not sure I like *any* kind of implicitly defined environment | | variable for this purpose.

Re: Identifying the NetBSD shell

2016-03-22 Thread Robert Elz
Date:Tue, 22 Mar 2016 13:42:43 + From:Eric Haszlakiewicz Message-ID: <82ebf125-6f26-400a-8f22-c6836b810...@nimenees.com> | I'm pretty surprised that it wouldn't work in NetBSD's shell. It might, or it might make the shell dump core, or do

Re: Identifying the NetBSD shell

2016-03-22 Thread Robert Elz
Date:Tue, 22 Mar 2016 14:03:18 +0100 From:Joerg Sonnenberger Message-ID: <20160322130318.gb10...@britannica.bec.de> | I'm not sure I like *any* kind of implicitly defined environment | variable for this purpose. So why can't it be a

Re: Identifying the NetBSD shell

2016-03-22 Thread Eric Haszlakiewicz
On March 21, 2016 11:08:50 PM EDT, Kamil Rytarowski wrote: >> if a script wants to know if it can safely redirect file >> descriptors >= 10 (answer for NetBSD right now is definitely no) >> that is a little difficult to embed in the script. > >Redirecting fd >= 10 is rather a

Re: Identifying the NetBSD shell

2016-03-22 Thread Joerg Sonnenberger
On Mon, Mar 21, 2016 at 12:13:13PM +0700, Robert Elz wrote: > 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 >

Re: Identifying the NetBSD shell

2016-03-21 Thread Robert Elz
Date:Tue, 22 Mar 2016 04:08:50 +0100 From:Kamil Rytarowski Message-ID: <56f0b742.70...@gmx.com> | Redirecting fd >= 10 is rather a specialized use-case. Is it possible | to detect it dynamically? What we have now is just a bug. It will get fixed.

Re: Identifying the NetBSD shell

2016-03-21 Thread Kamil Rytarowski
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21.03.2016 15:56, Robert Elz wrote: > $ echo $KSH_VERSION @(#)MIRBSD KSH R50 2014/10/07 > > and not MKSH_VERSION My bad, MKSH_VERSION is only in the source-code. > if a script wants to know if it can safely redirect file > descriptors >= 10

Re: Identifying the NetBSD shell

2016-03-21 Thread Rhialto
On Mon 21 Mar 2016 at 14:42:21 -0400, Thor Lancelot Simon wrote: > I strongly agree. How about just giving it a date rather than a version > number? You can still bump the date only when something significant > changes. Then scripts can just numerically require that NBSH > 20160401 > or the

Re: Identifying the NetBSD shell

2016-03-21 Thread Thor Lancelot Simon
On Mon, Mar 21, 2016 at 02:14:05PM -0400, Greg Troxel wrote: > > I find using 7.99.X awkward, as that's a version that means something > for the kernel (and userland more or less), and this is really something > quite different. I strongly agree. How about just giving it a date rather than a

Re: Identifying the NetBSD shell

2016-03-21 Thread matthew sporleder
On Mon, Mar 21, 2016 at 2:14 PM, Greg Troxel wrote: > > Robert Elz writes: > >> 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

Re: Identifying the NetBSD shell

2016-03-21 Thread Greg Troxel
Robert Elz writes: > 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

Re: Identifying the NetBSD shell

2016-03-21 Thread Robert Elz
Date:Mon, 21 Mar 2016 10:28:21 +0100 From:Kamil Rytarowski Message-ID: <56efbeb5.7020...@gmx.com> | mksh(1) defines MKSH_VERSION. That's interesting, they must have changed (relatively recently - as in within the last year or so) - the version I have

Re: Identifying the NetBSD shell

2016-03-21 Thread Kamil Rytarowski
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21.03.2016 06:13, Robert Elz wrote: > Bash has BASH and BASH_VERSION (and more) ksh has KSH_VERSIOn, zsh > has a whole bunch of ZSH_* vars. mksh(1) defines MKSH_VERSION. I suggest to define SH_VERSION with value "NetBSD". Precise version (if

Re: Identifying the NetBSD shell

2016-03-21 Thread Greg 'groggy' Lehey
On Monday, 21 March 2016 at 12:13:13 +0700, 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,

Re: Identifying the NetBSD shell

2016-03-21 Thread Robert Elz
Date:Mon, 21 Mar 2016 18:32:45 +1100 From:"Greg 'groggy' Lehey" Message-ID: <20160321073245.ga66...@eureka.lemis.com> | SH_VERSION. That's "intuitive" for people used to zsh and bash. That would certainly allow the var to be shared amongst shells

Re: Identifying the NetBSD shell

2016-03-21 Thread Robert Elz
Date:Mon, 21 Mar 2016 15:00:18 +0800 (PHT) From:Paul Goyette Message-ID: | > Given the (very) slight preponderence above for xxx_VERSION, why not use | > NBSD_VERSION? | | Er, typo,

Re: Identifying the NetBSD shell

2016-03-21 Thread Paul Goyette
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