These were being reported as strange values because the WEXITSTATUS macro from the GNO headers would erroneously sign-extend them.
Thanks to Kelvin Sherlock for posting an example that demonstrated this problem.
The only substantive change is about when simple line input mode is used.
I also bumped the version number and included a GNO-version-specific component.
The bug is that an #if condition may be mis-evaluated if it immediately follows a use of a function-like macro. I also modified a couple other places that could possibly trigger the bug (including a possibly more reliable fix for the instance of this problem I worked around earlier in include/xatonum.h).
We do this by maintaining a mask (for each pid) giving the fds to be closed on exec. We wrap functions that close fds so that their close-on-exec bits can be cleared at that point.
This implementation may close the fds even if the execve operation ultimately fails.
Sometimes ARG_MAX is small (like 32k) yet sysconf(_SC_ARG_MAX)
is big, and people prefer using the bigger value.
OTOH, with sufficiently large ARG_MAX, further wins from
sysconf(_SC_ARG_MAX) being bigger are exponentially smaller:
you can see 4 times fewer fork+execs when you run find, but
when each execed process already takes a thousand parameters
it's likely execution time is dominated by what that process
does with each parameter.
Thus, with this change ARG_MAX is used if it's sufficiently big,
otherwise sysconf(_SC_ARG_MAX) is used.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
*Most significantly, we avoid using setpgid(), because it doesn't work and in fact corrupts the kernel's process group table.
*Also, work around tctpgrp() returning garbage instead of 0 on success.
This adds an implementation of tcsetpgrp that works by reading the process tables to find a process in the appropriate group. This isn't used for the main job control operations, though, since it might be relatively slow.
At this point, basic job control seems to work.
* Push/pop environment to make sure it is isolated from our parents and children.
* Make all environment vars (and shell vars) case-insensitive, consistent with GNO's internal handling of environment vars.
* Wrap putenv and unsetenv to make sure they are called with lower-case variable names, which is necessary to maintain consistency between the environ array and the kernel's internal representation of variables.
This should avoid strange behavior due to races when the parent has resumed but the child is still running the exec* code in libc, which mainly manifests itself when running at low speed.
We also change to signaling the child's completion with SIGALRM, and setting an extra alarm in the parent in case the child doesn't actually do it.
GNO's _exit (contrary to its man page) does clean-up for stuff like the memory allocator, which is inappropriate in a forked child process and leads to hangs and crashes.
*Use .null instead of /dev/null
*Account for GNO's dup2(), which non-standardly returns 0 on success
*Always call open with appropriate number of arguments
*Use STDIN_FILENO instead of (implicitly) 0
In particular, it will buffer information about children other than the one being waited for, so it isn't lost. It can also emulate a non-blocking wait by arranging to interrupt the wait with a signal.
This involved breaking things up into more segments in debug mode, since the code is larger. I also had to remove some unused extern definitions, which were causing link errors when debug code was enabled.
To enable debug code, pass "DEBUG=1" to make or build.gs.
This involved using signal() rather than sigaction(), which GNO doesn't have. signal() doesn't have the signal-blocking feature of sigaction(), but I've tried to emulate it.
This disables long argument support, since that requires getopt_long(), which isn't included in GNO. There is a separate library available for it, but it's simpler to avoid depending on that.
This is a BSD-licensed poll() implementation by Brian M. Clapper. Its performance characteristics aren't as good as a "native" poll() would be, but this shouldn't be a problem in practice.
Dmake gets confused if you use over-15-character file names, so they needed to be shortened to get it to work. While I was at it, I also switched _ to . in the filenames so they're fully ProDOS compatible.
The shell/hush_test directory (not needed to build the code) still uses ProDOS-incompatible file names.
