[PATCH] trap -p does not display ignored signals inherited from parent by a bash process
Hi,
I already reported this in Fedora rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=572305) This also seems
to be present upstream, so I hope you guys find this useful.
Description of problem:
trap -p doesn't show ignored signals inherited from its parent across an execve
Version-Release number of selected component (if applicable):
bash-4.1.2-3.fc14
How reproducible:
Always
Steps to Reproduce:
1. trap '' SIGINT
2. exec bash
3. trap -p
Actual results:
Nothing is returned as output of trap -p. But at the same time, running cat and
trying to interrupt it shows that the signal is in fact being ignored
Expected results:
The list of ignored signals should be returned
Additional info:
Attached patch ensures that inherited ignored signals are reflected in
trap_list and then subsequently displayed when trap -p is invoked.
--
Siddhesh Poyarekar
http://siddhesh.in
--- a/jobs.c 2009-11-30 03:42:05.0 +0530
+++ b/jobs.c 2010-03-11 00:43:59.0 +0530
@@ -3772,9 +3772,16 @@ set_new_line_discipline (tty)
void
initialize_job_signals ()
{
+ SigHandler *old_int;
+
if (interactive)
{
- set_signal_handler (SIGINT, sigint_sighandler);
+ old_int = set_signal_handler (SIGINT, sigint_sighandler);
+
+ /* If a handler has been modified or inherited, restore the old one */
+ if ( old_int != (SigHandler *)SIG_DFL )
+set_signal_handler (SIGINT, old_int);
+
set_signal_handler (SIGTSTP, SIG_IGN);
set_signal_handler (SIGTTOU, SIG_IGN);
set_signal_handler (SIGTTIN, SIG_IGN);
--- a/trap.c 2010-03-11 00:35:25.0 +0530
+++ b/trap.c 2010-03-11 00:41:31.0 +0530
@@ -142,9 +142,23 @@ initialize_traps ()
for (i = 1; i < NSIG; i++)
{
pending_traps[i] = 0;
- trap_list[i] = (char *)DEFAULT_SIG;
+ /* These will be set by initialize_signals(), but we don't want to show
+ * them in the traps list */
+ if ( i == SIGTSTP || i == SIGTTOU || i == SIGTTIN )
+{
+ trap_list[i] = (char *)DEFAULT_SIG;
+ }
+ else
+{
+ /* Don't assume that the original signal was SIG_DFL */
+ original_signals[i] = (SigHandler *)set_signal_handler (i, SIG_DFL);
+ set_signal_handler (i, original_signals[i]);
+
+ trap_list[i] = (char *)original_signals[i];
+ }
sigmodes[i] = SIG_INHERITED;
- original_signals[i] = IMPOSSIBLE_TRAP_HANDLER;
+ if ( original_signals[i] == SIG_DFL )
+original_signals[i] = IMPOSSIBLE_TRAP_HANDLER;
}
/* Show which signals are treated specially by the shell. */
What is $[ ] ?
Hi, I could not find the dollar square brackets $[ ] expansion documented in the manual. Is it the same as $(( )) ? Cheers, Marc Le 22/03/2010 13:13, tbart...@gmx-topmail.de a écrit : > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Compiler: i686-pc-linux-gnu-gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I. -I./include -I./lib > -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' > -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' > -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' > -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -O2 -march=core2 > -mfpmath=sse -msse4.1 -fomit-frame-pointer -pipe > uname output: Linux blackknight 2.6.31-gentoo-r6 #1 SMP PREEMPT Mon Nov 30 > 19:03:35 CET 2009 i686 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz > GenuineIntel GNU/Linux > Machine Type: i686-pc-linux-gnu > > Bash Version: 4.0 > Patch Level: 35 > Release Status: release > > Description: > The man page seems to be wrong regarding the handling of numbers with > different bases. It states one has to use [base#]n although it seems to be > [base#n] that needs to be used... > (I know I do not have the latest bash, but with 4.1 it is the same in the > man page.) > > Repeat-By: > blackknight ~ $ echo $[2#]10 > 010 > blackknight ~ $ echo $[2#10] > 2 > > Fix: > Correct the man page
Re: What is $[ ] ?
On Tue, Mar 23, 2010 at 12:41 PM, Marc Herbert wrote: > Hi, > > > I could not find the dollar square brackets $[ ] expansion documented > in the manual. Is it the same as $(( )) ? > > Cheers, > > Marc > > $[ ] is an older version of $(( )) but it's deprecated. that's probably why it's not documented any more.
Re: unicode aware printf \u and \U switches not supported
On Mon, Mar 22, 2010 at 02:24:48PM +0100, Thomas Bartosik wrote: > Repeat-By: > tb...@blackknight ~ $ /usr/bin/printf "\u20AC\n" > ? > tb...@blackknight ~ $ type printf > printf is a shell builtin > tb...@blackknight ~ $ printf "\u20AC\n" > \u20AC Must be a GNUism. On HP-UX: imadev:~$ /usr/bin/printf "\u20AC\n" u20AC imadev:~$ printf "\u20AC\n" \u20AC Wonder why the HP-UX printf(1) is eating the first backslash... *shrug*. OpenBSD gives a warning: cyclops:~$ /usr/bin/printf "\u20AC\n" printf: unknown escape sequence `\u' u20AC cyclops:~$ echo $? 1 Then again, OpenBSD doesn't even have locale(1).
Re: unicode aware printf \u and \U switches not supported
On 03/23/2010 03:01 AM, Chet Ramey wrote: On 3/22/10 9:24 AM, Thomas Bartosik wrote: Bash Version: 4.0 Patch Level: 35 Release Status: release Description: bash's printf does not understand \u and \U although the man page says it supports all expressions that printf(1) supports. The man page says the bash printf supports the standard printf(1) escape sequences. \u and \U are not standard escape sequences. They are on the list for possible inclusion in a future release. Chet Just few links; Opengroup printf utility specification[1], there is not any note about \u or \U format. Coreutils printf has this extension [2], but there is not any note, from where it comes or what it is specific for. [1] http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html [2] http://www.gnu.org/software/coreutils/manual/html_node/printf-invocation.html RR
Re: What is $[ ] ?
On 3/23/10 6:41 AM, Marc Herbert wrote: > Hi, > > > I could not find the dollar square brackets $[ ] expansion documented > in the manual. Is it the same as $(( )) ? It's the deprecated version of $((...)), dating from Posix.2 draft 9 circa 1989 or so. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH] trap -p does not display ignored signals inherited from parent by a bash process
On 03/23/2010 01:29 AM, Siddhesh Poyarekar wrote: > Steps to Reproduce: > 1. trap '' SIGINT > 2. exec bash > 3. trap -p POSIX states: "Signals that were ignored on entry to a non-interactive shell cannot be trapped or reset, although no error need be reported when attempting to do so. An interactive shell may reset or catch signals ignored on entry." http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap I see no bug - bash is within its rights to pretend that an inherited ignored SIGINT has no trap setting, seeing as how the user cannot modify that through any use of trap. That is, 'trap -p' is designed to output the text that will restore traps to their normal state, but since there is no way to change the state of SIGINT from being ignored, there is nothing needed in the output. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] trap -p does not display ignored signals inherited from parent by a bash process
On Tue, Mar 23, 2010 at 7:46 PM, Eric Blake wrote: > On 03/23/2010 01:29 AM, Siddhesh Poyarekar wrote: >> Steps to Reproduce: >> 1. trap '' SIGINT >> 2. exec bash >> 3. trap -p > > POSIX states: > > "Signals that were ignored on entry to a non-interactive shell cannot be > trapped or reset, although no error need be reported when attempting to > do so. An interactive shell may reset or catch signals ignored on entry." > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap > > I see no bug - bash is within its rights to pretend that an inherited > ignored SIGINT has no trap setting, seeing as how the user cannot modify > that through any use of trap. That is, 'trap -p' is designed to output > the text that will restore traps to their normal state, but since there > is no way to change the state of SIGINT from being ignored, there is > nothing needed in the output. > Thanks for that explanation. I guess we can also detect if a signal is being ignored by trying to set a trap for that signal and verify that it has not been set. This was my original problem and I went about trying to fix it in code rather than reading the docs carefully :) -- Siddhesh Poyarekar http://siddhesh.in
