Re: Identifying the NetBSD shell

[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.

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

[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 (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

[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 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

[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 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

[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 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

[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 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

[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 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

[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 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: USB scanners and PR 50340

[Stephen Borrill]

On Fri, 18 Mar 2016, Gary Duzan wrote:

=>Dave Tyson  writes:
=>
=>> I note that PR 50340 has been closed and with the latest pkgsrc
=>>under current (amd64) my Mustek 1200 UB scanner seems to work OK
=>>- but I have comment out the uscanner device in the kernel and use
=>>it as a ugen device. It seems that this is the 'new world order'
=>>and the sane backend code to handle uscanner devices is deprecated.
=>>Given this is the case is there any point in still keeping the
=>>
=>> uscanner* at uhub? port ?
=>>
=>> in GENERIC?
=>
=>Quite possibly we should remove (comment out) uscanner in GENERIC.
=>ulpt is more controversial, but cups wants to use libusb too.
=>
=>> I am of the same opinion as the PR originator that it is easier
=>>to control access permissions with a uscanner device rather than
=>>having to open up a whole raft of ugen devices, but I guess the
=>>sane developers feel that using libusb makes support easier...
=>
=>Perhaps if we had something called uscanner that would match scanners
=>and that libusb would fine, we could have the permissions management of
=>direct matching but the cope-with-the-rest-of-the-world benefit of
=>libusb.

  Can we not build some sort of bus-like device to which both the
specialized and generic devices can attach which prevents opening
both at the same time?


An alternative is to have a method to detach the kernel driver so that you 
can revert to ugen access (and probably method to reattach too). This is 
true for all usb devices (e.g. uvideo, umass, etc.). libusb has the 
following API, but we don't have the kernel support for it.



int 	libusb_kernel_driver_active (libusb_device_handle *dev, int 
interface_number)

Determine if a kernel driver is active on an interface.

int 	libusb_detach_kernel_driver (libusb_device_handle *dev, int 
interface_number)

Detach a kernel driver from an interface.

int 	libusb_attach_kernel_driver (libusb_device_handle *dev, int 
interface_number)
 	Re-attach an interface's kernel driver, which was previously 
detached using libusb_detach_kernel_driver().


int 	libusb_set_auto_detach_kernel_driver (libusb_device_handle *dev, 
int enable)


Being able to detach kernel drivers would allow for USB remoting (e.g. 
http://usbip.sourceforge.net/ or Citrix Receiver). It would aid 
development of drivers with rump too.


--
Stephen

Re: Identifying the NetBSD shell

[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, 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

[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 (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

[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, 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

[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 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 |
+--+--++