Date:        Mon, 29 May 2017 14:38:02 +0200
    From:        Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
    Message-ID:  <592c162a.syoz+dozzpogtqep%joerg.schill...@fokus.fraunhofer.de>

  | The problem is that I have a FreeBSD system available for testing,
  | but not a NetBSD system...

It is fairly easy to set up NetBSD - it runs (kind of badly...) under
qemu, and quite well under Xen, virtualbox and vmware.

(If you want to try any of that, for this purpose, definitely use one
of the NetBSD current daily builds, not a release version, the shell in
those is ancient...)

  | Moreover, I like to run frequent tests with various shells on my main 
  | development machine.

Yes, so do I, but I don't have them all (too much of a good thing!)

  | *BSD typically uses things like "err()" that are not portable.

Yes, a lot of utilities do, using that encourages more consistent behaviour,
but the shell does not (err() is kind of obvious - what it does is almost
never what the shell would want to do, but we don't use warn() either).

For the utilities that do use them, when they're being compiled on some other
system (NetBSD can be built almost anywhere, but we need a sane environment
to do that, so the first step of the build process is to build a set of
NetBSD tools on the host) there is a nbcompat library that can be used that
provides essentially all of the pieces missing from other libc's.

  | The fact that a real vfork() implementation changes the timing,
  | causes some constructs to fail unless there is special code inside.

Yes, there is "special code" - our shell can only use vfork() if it is
a real vfork() - if a system provides a vfork() that is just fork() wrapper
(or some abomination in between) for the benefit or programs that assume
that vfork() exists, and use it blindly, then that's no use at all, and
our shell won't (can't) use that, it will just fork() instead.

  | You may like to make your shell available if you are interested in getting 
  | other people to test it.

Yes, one day, I will.   That's definitely an objective.   But right now
I have enough bugs (and missing pieces) that I already know about that need
fixing, that I don't really need people finding more which aren't currently
bothering anyone (many of the bugs are in exotica that no real script ever
uses.)

kre


Reply via email to