POSIX says that _exit() should do this, but on GNO it doesn't. This implementation should match the POSIX behavior in most cases, although it's not exactly the same.
Gsh also kills jobs on exit, but does so whether they're stopped or not and uses SIGKILL.
The logic for this was broken (giving a signal number rather than a mask to sigblock), and if it wasn't broken then it would have caused the wait call to hang.
Blocking SIGCHLD is required by POSIX, but gsh doesn't do it, so existing GNO code shouldn't be relying on it.
The issue is that GNO's login (and other BSD-derived versions) start up the login shell with SIGTSTP ignored. Hush was recording this configuration and propagating it to its child processes, causing ^Z not to work. The fix is to not do that (for login shells only).
Also, set the system vector to run hush before running any of the startup scripts, in case something run in them uses it.
Commands in the range of 16k-32k should now work, and commands longer than that should cause hush to die with an error message instead of corrupting stuff (at least in the simple cases I tested).
It would be possible to eliminate the 32k limit by using a type larger than "int" for lengths, but that would be a more invasive change.
This matches the semantics the original hush code obtained by using the SA_RESTART flag when installing signal handlers, and avoids error messages about waitpid being interrupted.
The sigprocmask implementation in GNO 2.0.6 libc has bugs that cause it to never actually unblock signals that have been blocked. This was causing many signals to remain blocked when they shouldn't be, particularly after running signal handlers.
This problem combined with a kernel issue (wait() calls won't recognize that a child has finished if SIGCHLD is blocked) to cause hangs in certain conditions.
This patch works around these issues by defining our own non-buggy version of sigprocmask in place of libc's.
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.
I think this problem is probably due to a bug in GNO's implementation of select().
The workaround is not to use poll (which calls select) when reading a key with no timeout (which is the normal case for command-line input).
This addresses a problem where something invoked in a group or function (e.g. gsh) could change the terminal's pgrp, and this would result in hush getting backgrounded.
We can still get strange behavior when a backgrounded child process changes the pgrp. Trying to deal with this would be inherently racy. Gsh also has problems in this scenario.
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.
Hush uses recursion for (at least) parsing nested constructs like { ... }, so it's possible for pathological/malicious scripts to overflow the stack, but this should be enough for just about anything non-pathological (e.g. up to about 10 levels of nested { }).
Based on the following user report:
I ran into an issue where I was seeing a long delay in the scripts called
in udhcp_run_script. I was using an old version of OpenWrt (kamikaze)
and a satellite modem. An NTP script was being called and the modem
would sometimes take a long time to respond to the DNS lookup when
it was offline.
This delay started affecting my lease time. The lease that I would
get from my satellite modem before it was online would be short:
only 60 seconds. The delay with NTP and the modem would typically
be about 18 seconds. This would cause the first DHCP renew request
from dhcpc to be a little late. Under certain circumstances,
I could even see the first DHCP renew to occur after the lease
had expired!
function old new delta
udhcpc_main 2816 2837 +21
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The --bb options now depends on LONG_OPTS. Omit mentions of --bb from usage
text when LONG_OPTS is disabled.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The problem seemed to be that it crashes if the t_intrc special character is set to -1 on a pty. I worked around this by setting it to an obscure control character instead in that case.
The Required_argument macro is only defined when long options are enabled.
Fixes the following build error:
miscutils/nandwrite.c: In function 'nandwrite_main':
miscutils/nandwrite.c:120:10: error: expected ',' or ';' before 'Required_argument'
Reported-by: Christian Kästner <kaestner at cs.cmu.edu>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In vi-mode lineedit tries to detect some escape sequences.
After the ESC it reads the next character to check for certain
values. This read should have a timeout or a user-entered ESC to
switch to command mode doesn't properly handle the next character.
Signed-off-by: Ron Yorston <rmy@tigress.co.uk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
