Robert Elz <k...@munnari.oz.au> wrote:
> Date: Mon, 29 May 2017 11:47:04 +0200
> From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
> Message-ID:
> <592bee18.kvZiYpLd6LS/Evf/%joerg.schill...@fokus.fraunhofer.de>
>
> | If the related shells would be available as portable code,
> | it would be easy to test them.
>
> There is no requirement that you, or I, or anyone else in particular,
> be able to build and run any particular shell. While that's nice if
> possible, a shell is still a shell even if its source code is not openly
> available at all (like any that are in closed source systems, if any of
> those still really exist.) Users get to experience those shells too.
The problem is that I have a FreeBSD system available for testing, but not a
NetBSD system...
Moreover, I like to run frequent tests with various shells on my main
development machine.
> If no-one can test the shell, that would be different, but as long as someone
> can run tests, we have all we absolutely need.
>
> | For now, the problem is that these shells massively rely on non-POSIX
> | extensions in /usr/include and in libc.
>
> I don't think the NetBSD shell has any such code in it (the debugging code
> relies on asprintf() and friends, but you don't need that to compile it.)
> Formatter output (for messages, and such) will use vasprintf() if available,
> but that's conditionally compiled, and can be done without.
*BSD typically uses things like "err()" that are not portable.
> Similarly, use of vfork() is conditionally compiled (it runs the same
> without, just slower). We only use waitpid() currently (which is POSIX)
> though the shell is supposed to be able to build and work (with some loss
> of functionality) with just wait() for ancient systems. (I am adding
> waitid() support as one of my back-burner tasks, but that doesn't really
> fix anything that's broken, so it is low priority.)
vfork() is not a real problem except when your vfork() support code might not
be correct enough to correctly deal with process groups and similar. The fact
that a real vfork() implementation changes the timing, causes some constructs
to fail unless there is special code inside.
You may like to make your shell available if you are interested in getting
other people to test it.
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
