Re: Identifying the NetBSD shell
Date:Mon, 21 Mar 2016 14:42:21 -0400 From:Thor Lancelot SimonMessage-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 entirely reasonable, so that is now the current plan. My current (private) sources have it set to 20160323 but it will probably be 20160401 when it gets committed (whenever that happens - this does not imply that it will appear next Friday!) And the most popular choice for the variable name to contain that version string seems to be NETBSD_SHELL (based mostly on off-list e-mail I received). Anyone who has objections to either of those should make them known soon... I have sent Christos a bunch more updates to be committed when he finds the time (including a fix for PR bin/50993). The next update I send him is likely to be the one that implements this (if for no other reason so that I don't need to keep deleting this change from the updates!) The next (bug-fix) type patches are likely to take a while to create, the bugs left to fix are getting nastier to handle - so this small change (once there has been sufficient time for opinions) is likely to beat the next real fixes. You may also want to check the original message on tech-userlevel for some discussion of more technical related issues that are likely to happen at the same time (though those you're unlikely to notice unless you explicitly go looking.) That message is ... http://mail-index.netbsd.org/tech-userlevel/2016/03/16/msg009776.html kre
Re: Identifying the NetBSD shell
In article <82ebf125-6f26-400a-8f22-c6836b810...@nimenees.com>, Eric Haszlakiewiczwrote: >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 specialized use-case. Is it possible >>to detect it dynamically? > >It doesn't seem that specialized. I've seen scripts that do that with >e.g. fd 99 as a way to pick some arbitrary high fd number that is >unlikely to be used by other parts of the script. >I'm pretty surprised that it wouldn't work in NetBSD's shell. These horrid hacks that need "high enough" fds should go and we should just support dynamic fd redirection like bash does: $ exec {fd}>&1 $ echo ${fd} 10 $ echo "Some output" >&${fd} christos
Re: Identifying the NetBSD shell
| 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. Oh, and I missed, this is not to be an "environment variable", at least, not in the common usage of that term - that is, the value should only be visible inside the shell (so there, it appears as an environment variable would, if one were to do, for some reason KSH_VERSION=1.2.3 /bin/sh then /bin/sh would see "${KSH_VERSION}" set, and scripts might believe they are running in ksh, with this new var it would be just like that, except without requiring users to set it, and without the value being further exported to chold processes.) The thread I posted on tech-userlevel had more details, including some brief discussion of preventing the new variable being exported from the shell, to aid in avoiding the kind of lunacy mentioned just above, that I omitted from this thread (by all means read the one message on tech-userlevel and reply to that, it has much more content than this thread.) kre
Re: Identifying the NetBSD shell
Date:Tue, 22 Mar 2016 13:42:43 + From:Eric HaszlakiewiczMessage-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 almost anything, (or if your shell is old enough, produce a syntax error as it would have done in original Bourne shells). Posix does not even require fd's up to 9 to be supported, it just suggests that should be done if possible... Scripts using values greater than than 9 without defensive measures, are at the very least, not portable. Still, nothing justifies accessing outside array bounds, so this is going to get fixed in the NetBSD shell. And since this is now public info, I guess it needs to be moved higher up my priority list! kre
Re: Identifying the NetBSD shell
Date:Tue, 22 Mar 2016 14:03:18 +0100 From:Joerg SonnenbergerMessage-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 special set argument | instead, just like most command line tools of GNUish origin support | something like -V? Because that wouldn't work with any other shell in existence, and the whole idea is to implement something that any shell (Bourne shell style, forget csh) can use to determine which shell is running. kre ps: and in the NetBSD shell, -V means "vi editing enabled"...
Re: Identifying the NetBSD shell
On March 21, 2016 11:08:50 PM EDT, Kamil Rytarowskiwrote: >> 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 specialized use-case. Is it possible >to detect it dynamically? It doesn't seem that specialized. I've seen scripts that do that with e.g. fd 99 as a way to pick some arbitrary high fd number that is unlikely to be used by other parts of the script. I'm pretty surprised that it wouldn't work in NetBSD's shell. Eric
Re: Identifying the NetBSD shell
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 > shell that is in use. I'm not sure I like *any* kind of implicitly defined environment variable for this purpose. So why can't it be a special set argument instead, just like most command line tools of GNUish origin support something like -V? Joerg
Re: Identifying the NetBSD shell
Date:Tue, 22 Mar 2016 04:08:50 +0100 From:Kamil RytarowskiMessage-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. The standard sets no upper limit on fd - it says that values up to 9 should be supported (and at that the NetBSD shell does OK, assuming a few caveats that do not usually apply) but allows for anything larger the implementation can support. Good shells allow the user to use anything that would be valid in a dup2() call (as the target). That's what we should aim for. I believe earlier versions of the NetBSD shell used to regard values > 9 as a syntax error. That (while sub-optimal) was OK. The current shell just makes a mess of itself... kre
Re: Identifying the NetBSD shell
-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 (answer for NetBSD right now is definitely no) > that is a little difficult to embed in the script. Redirecting fd >= 10 is rather a specialized use-case. Is it possible to detect it dynamically? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJW8Lc+AAoJEEuzCOmwLnZsm2AP/A8mAJbhH0D416j8eSrpiyuW exzZVz8NDgE5njBeiN4zK/lE3ZTRNWEy8amN/Ji7gdISix2tpmtvq8iVAecxiHQF VQGRD90brRAz4gW2AWpRToVHKqW+xhL2WtDLfCoQ2hfScBfEb3S0ZcUpwweb4AK7 Gfbe68Cidv7Wh99f66AmTKbvyvUHnE3oGTMYsYpFpeDYGlU78sD5QDA0xGk2H5wg f8484BWcBM5DE7o2Ji+KSr/Sh2IzqgeyCDgwQtXRSdo6bzW+JlvQjjaPpO8Gahlz 7s9KuCBL/84BRISv4AJ6zxX2coHU99GvR7tA0Hrz4Nvw8MUjdX97KGxs2/5JIU+3 X2B9HQsbJiA2Z4CKdQuGBZtcFT0SnIVhE1kFWmsjEcDqiM3tu6LvXqveXv5Xcy1a Z19EXOYn4XKc54ycFuIkTYFR9R9q6TN8o65I8dohonc8ianhfTEEpV9OmizY94ej h2/9jZJO37G7ia2pEZjWfZqB8Dx8pZZB007NgstrxedJ3V2ptD6/vqSOB9VMmcgP I6KU2OnG5ZedVkafPA/UVbPR+r7/JLpZz5GPLhxUSc9ZfEn4Gejd7thvNkNwjXT1 l0+K2qjDFJFhcqydYVa0FbLOWILVi0DqGkuX3RsNe/0BeqBBoBcNGA5SzlqOMAH+ RT1VZ9EbmVSw+wc9bCL+ =SsUG -END PGP SIGNATURE-
Re: Identifying the NetBSD shell
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 like. That makes a lot of sense to me. Starting at or near 1.0 would seem to imply that sh is fairly new and didn't have many previous versions, which is untrue. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Identifying the NetBSD shell
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 version number? You can still bump the date only when something significant changes. Then scripts can just numerically require that NBSH > 20160401 or the like. Thor
Re: Identifying the NetBSD shell
On Mon, Mar 21, 2016 at 2:14 PM, Greg Troxelwrote: > > 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 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.) > > 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'd be tempted to call in 1.0.0 arbitrarily, and bump micro on bugfixes > (or just prior to export of a new portable version), minor on feature > additions, and major on significant compat breaks (perhaps never). > That will keep people from inferring things that aren't true. I think the responses here have shown that you should just use your best judgement and stick with it. :)
Re: Identifying the NetBSD shell
Robert Elzwrites: > 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.) 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'd be tempted to call in 1.0.0 arbitrarily, and bump micro on bugfixes (or just prior to export of a new portable version), minor on feature additions, and major on significant compat breaks (perhaps never). That will keep people from inferring things that aren't true. signature.asc Description: PGP signature
Re: Identifying the NetBSD shell
Date:Mon, 21 Mar 2016 10:28:21 +0100 From:Kamil RytarowskiMessage-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 defines KSH_VERSION ... $ echo $KSH_VERSION @(#)MIRBSD KSH R50 2014/10/07 and not MKSH_VERSION But it does suggest that the name of the variable may be more important than its content, as you suggest. | I suggest to define SH_VERSION with value "NetBSD". That might be a little too course, but certainly is a possibility. | Precise version | (if needed) is retrievable with what(1) and ident(1) (or strings(1) | and grep(1) or similar). And that might be a little too precise - fine when what you want to know is whether some specific bug is fixed, but 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. | - From my experience, people mostly detect whether *_VERSION is | available, without parsing their values. I agree. | While there, I would reset ksh(1) to "NetBSD" as the current value | ("@(#)PD KSH v5.2.14 99/07/13.2") has no meaning. That would probably be a good idea. It is certainly kind of dated, and I am sure that ksh(1) has had some changes/fixes in the past 16 years. kre ps: I had an off-list vote for NETBSD_SHELL as the var name.
Re: Identifying the NetBSD shell
-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 needed) is retrievable with what(1) and ident(1) (or strings(1) and grep(1) or similar). - From my experience, people mostly detect whether *_VERSION is available, without parsing their values. While there, I would reset ksh(1) to "NetBSD" as the current value ("@(#)PD KSH v5.2.14 99/07/13.2") has no meaning. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJW776zAAoJEEuzCOmwLnZshmwQALLfMNxvDKbT/Pgl1pieytvx C+d+KfsXmi9fJxG2qaNeKmkRPh7JcAKaYbJts+YnL5bB/nLUOZIIlSI7q7pq+lPO lTWKOF1n9VgvrbdOnfx9cIDJp4oxloBDQYjJJuoeur5Wx8T4MAoaZbeSIGzcEOJE dwT6GzXJrDarWBlbFpgExLiLoCDzCQ4ZzipV4obzU2lw2MMGOIAQeFVNuED0W2qo xsknXpvN5clrvTX/D4b/LA2XewN9UM/gsivY0hEWppsIG9vs9uzCfYVSXeuLLwvm +pOt944mJwWYK0uLFjjG3tQZ4M7O6GI4MFINCGISx+F8nJ/KkSo9oxQZK3IruuKZ mpSPYdVBLrjiDmJfPT+vdBeGyeiGRbFhJmZkA2mNH8TmslttFAwSBY5NvKp/34Si LrMTrEE2BsdDTy1BVpkOb0Mm8fq3Ud+F9MfVkLy3bRZxnxNqUVcWgTD6goiD60Tx 93sdkHf88e1aL3zKWb8r/5hOxbZ7K0luKU5gX7ts4T72t3kXgwSIU+TipeZd5fKl /ltog3e+wL46/jJXXqfr28+AE94vM5/LS9EZKR5zTqxO8Cbd15Fl5IzQZRgiN2o4 Yc4NDXKUQH2Gbfjld1UQKzQFCjcsZkj9oNJTE8ZkZHhliJ7TDSTw0FYQQRpSCDPp TTSHbrGIsEm39rvXjOQH =fMEZ -END PGP SIGNATURE-
Re: Identifying the NetBSD shell
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, 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.) SH_VERSION. That's "intuitive" for people used to zsh and bash. > 2) what value should it have? I am expecting it will be a read-only >var. Something relating to the OS and release, I suppose, or the most recent checkin. But for portability's sake, it should be something that other BSDs should be able to implement as well. I'd certainly argue for compatible values in the FreeBSD sh, assuming I can get them past the standards nazis. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua signature.asc Description: PGP signature
Re: Identifying the NetBSD shell
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 (though I believe it is still BASH_VERSION when bash is installed as /bin/sh) However, to meet my objective, it would then need to contain a value identifying which shell, and testing it would be (fractionally) more complex -- the NetBSD and FreeBSD shells are not the same (don't even implement quite the same language) and testing which of those is in use is one of the primary needs. I can already detect bash, ksh, zsh, it is determining which of those left over it is, when it is not one of those three (or clones thereof) that is of most interest. | > 2) what value should it have? | Something relating to the OS and release, As Paul said. we do not want to duplicate (or replace) uname. The OS from which the shell originates perhaps (the one where it is installed in /bin/sh in a standard installation) and shell version (or release) would make some sense. | I'd certainly | argue for compatible values in the FreeBSD sh, assuming I can get them | past the standards nazis. I am fairly certain that there's no standard preventing new variables being implemented (every shell, including the various ksh's, which are the primary source for the posix sh spec, has variables that are not included in the list in posix). So, that problem should not be hard to overcome. I am not sure the values themselves need to be compatible, but if there is to be a shared var name, then the syntax of that var should be consistent (that is, if it contains "SHELL_SOURCE version" it should contain those two elements, in the same order, everywhere ... but what the "version" etc looks like need not be the same.) kre
Re: Identifying the NetBSD shell
Date:Mon, 21 Mar 2016 15:00:18 +0800 (PHT) From:Paul GoyetteMessage-ID: | > Given the (very) slight preponderence above for xxx_VERSION, why not use | > NBSD_VERSION? | | Er, typo, should have been | | NBSH_VERSION I didn't much like the first attempt, but that one is certainly plausible. | > 2) what value should it have? | Hmmm. Start with "1.0" and increment when "appropriate"? That's certainly one possibility. | The shell version should/would be separate from system version, right? Not identical, for sure, but perhaps they don't have to be totally different, but could be related. | We can always use uname(1) for OS version. Yes, replacing that is definitely not an objective. | Sidebar: perhaps the shell version could be used as a proxy for the | "userland version" to detect userland/kernel mismtaches? That kind of possibility, and discussion of whether it would be useful or not, is what I am hoping to see. And any other similar possible uses. For my primary purpose (I want to know I am in the NetBSD shell so $ENV can do the right things) it doesn't matter at all what the value is. But just having a variable that is set or unset with no defined value seems like a waste of an opportunity, so ... (nb: the variable value does not have to be the shell version string, though if we call it NBSH_VERSION it will probably be expected to be that.) kre
Re: Identifying the NetBSD shell
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. !DSPAM:56ef954d25218757515768! +--+--++ | 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 | +--+--++