SIGINT in a sourced script does not clean up some special variables

[Grisha Levit]

Apologies if I'm missing something about the expected SIGINT behavior.  I've 
read through the previous SIGINT discussions but this still seems unexpected:

$ declare -p BASH_ARGC BASH_ARGV BASH_SOURCE BASH_LINENO
declare -a BASH_ARGC=()
declare -a BASH_ARGV=()
declare -a BASH_SOURCE=()
declare -a BASH_LINENO=()

$ source <(echo 'kill -INT $$')

$ declare -p BASH_ARGC BASH_ARGV BASH_SOURCE BASH_LINENO
declare -a BASH_ARGC=([0]="1")
declare -a BASH_ARGV=([0]="/dev/fd/63")
declare -a BASH_SOURCE=([0]="/dev/fd/63")
declare -a BASH_LINENO=([0]="5")

Additionally, FUNCNAME is not cleared in some cases:

$ declare -p FUNCNAME
declare -a FUNCNAME

$ source <(echo 'die() { kill -INT $$; }; die')
$ declare -p FUNCNAME
declare -a FUNCNAME

$ source <(echo 'die() { : && kill -INT $$; }; die') 
$ declare -p FUNCNAME
declare -a FUNCNAME=([0]="source")


If the sourced script is running a foreground command then these values are 
returned back to their initial state after the shell receives a SIGINT -- so I 
suspect it's possible to do the same in the cases above.

Re: ${var@P} expansion includes 0x01 and 0x02

[Chet Ramey]

On 11/9/15 7:53 PM, Dennis Williamson wrote:

> 
> With editing off, I find that I must delimit variables with braces. Without
> the braces, only the second escape sequence is output. The \] isn't
> terminating the variable name when editing is off.

When line editing isn't enabled, the \[ and \] escapes have no meaning,
so they're removed.  In the example you give, removing them results in
the variable name including `Hello'.  If this is a problem for your prompt,
you should delimit variable names with braces.

-- 
``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: BASH_ARG{C,V} set when sourcing, even without extdebug

[Chet Ramey]

On 11/10/15 1:59 AM, Grisha Levit wrote:
> It looks like the source builtin pushes its own argc and argv onto the arrays 
> but only if it is called with no other arguments.

Yes, bash has always done this as a convenience.  This is a way to get the
name of the sourced file in the common case.

When given additional arguments, bash sets BASH_ARGC and BASH_ARGV only
when debugging mode is in effect.

-- 
``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: Bug in bash 4.4-beta: suspending and restarting "man" program

[Chet Ramey]

On 11/9/15 5:55 PM, Keith Thompson wrote:
> I have some more information on this.  In the latest test,
> the problem occurs when I run bash under rxvt, but not when I run it under
> xterm.
> 
> Using strace, I've found a difference in a call to rt_sigaction().  It calls
> 
> rt_sigaction(SIGTSTP, {SIG_DFL, ...})
> 
> under xterm (which works correctly), but
> 
> rt_sigaction(SIGTSTP, {SIG_IGN, ...})
> 
> under rxvt (where it doesn't).

This can happen if SIGTSTP is ignored when the shell is invoked.  When
bash restores the original signal dispositions in child processes, it
restores SIG_IGN.

-- 
``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: SIGINT in a sourced script does not clean up some special variables

[Chet Ramey]

On 11/10/15 3:36 AM, Grisha Levit wrote:
> Apologies if I'm missing something about the expected SIGINT behavior.  I've 
> read through the previous SIGINT discussions but this still seems unexpected:

Thanks for the report.  I'll take a look.

-- 
``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: Proposed Prompt Escapes

[Dennis Williamson]

On Mon, Nov 9, 2015 at 5:09 PM, Dennis Williamson <
dennistwilliam...@gmail.com> wrote:

>
>
> On Thu, Nov 5, 2015 at 6:26 PM, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
>
>> It might be handy to have some of the escapes that work in $'string'
>> quoting to also work in prompts especially now with the ${parameter@P}
>> transformation.
>>
>> Specifically the hex, unicode and control ones: \xHH, \u, \U
>> and \cx.
>>
>> I presume that the dollar-single-quote escapes should not be touched
>> since they are "specified by the ANSI C standard". Also, they needn't be
>> since we have the @P transformation.
>>
>> --
>> Visit serverfault.com to get your system administration questions
>> answered.
>>
>
>
> I obviously overlooked the collision between \u - username and \u -
> unicode. It could be dealt with by interpreting the escape as username if
> the following character is non-hex, but that would stand a good chance of
> breaking existing prompts. Since \U functionally is a complete superset of
> \u - unicode, perhaps the latter wouldn't need to be duplicated for
> prompting.
>
>
> --
> Visit serverfault.com to get your system administration questions
> answered.
>


Of course, the obvious way to do this is to assign a variable using
$'\u' or similar.

dbl_6_dom=$'\U1F061'
prompt='\u, something about dominoes $dbl_6_dom \@ '
echo "${prompt@P}"

But wait, you don't need the intermediate step! It already works!!!

prompt=$'\u, something about dominoes \U1F061  \@ '
echo "${prompt@P}"


-- 
Visit serverfault.com to get your system administration questions answered.

Re: Proposed Prompt Escapes

[Andreas Schwab]

Dennis Williamson  writes:

> But wait, you don't need the intermediate step! It already works!!!
>
> prompt=$'\u, something about dominoes \U1F061  \@ '

You should quote the backslashes.

prompt=$'\\u, something about dominoes \U1F061  \\@ '

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Proposed Prompt Escapes

[Dennis Williamson]

On Tue, Nov 10, 2015 at 12:14 PM, Andreas Schwab 
wrote:

> Dennis Williamson  writes:
>
> > But wait, you don't need the intermediate step! It already works!!!
> >
> > prompt=$'\u, something about dominoes \U1F061  \@ '
>
> You should quote the backslashes.
>
> prompt=$'\\u, something about dominoes \U1F061  \\@ '
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>


Thanks. That's better since it defers their evaluation which is important
when there is a conflict between the ANSI-C escapes and the prompt escapes
(e.g. \u (user) followed immediately by hex chars, \t, \v).


-- 
Visit serverfault.com to get your system administration questions answered.

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

But there's still a mystery here. Why does it behave differently under rxvt
vs. xterm,
and why does that difference show up in bash 4.4-beta but not in 4.3.30?
(Both versions of bash are built from source on the same system.)

Running bash 4.3.30 under either xterm 261 or rxvt v2.6.4, I get:

bash-4.3$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU

and Ctrl-Z works correctly.

Running bash-4.4-beta under xterm, I get

bash-4.4$ trap
trap -- '' SIGTTOU

and Ctrl-Z works correctly.  Running bash-4.4-beta under rxvt, I get:

bash-4.4$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU

and Ctrl-Z *doesn't* work.

The issue for me personally is that I'd like to run bash 4.4-beta, which
corrects
some bugs I've run into, under urxvt, which has better font support than
xterm.

Is there a workaround, a way to re-enable correct Ctrl-Z handling?

On Tue, Nov 10, 2015 at 7:33 AM, Chet Ramey  wrote:

> On 11/9/15 5:55 PM, Keith Thompson wrote:
> > I have some more information on this.  In the latest test,
> > the problem occurs when I run bash under rxvt, but not when I run it
> under
> > xterm.
> >
> > Using strace, I've found a difference in a call to rt_sigaction().  It
> calls
> >
> > rt_sigaction(SIGTSTP, {SIG_DFL, ...})
> >
> > under xterm (which works correctly), but
> >
> > rt_sigaction(SIGTSTP, {SIG_IGN, ...})
> >
> > under rxvt (where it doesn't).
>
> This can happen if SIGTSTP is ignored when the shell is invoked.  When
> bash restores the original signal dispositions in child processes, it
> restores SIG_IGN.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>



-- 
Keith Thompson 

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Chet Ramey]

On 11/10/15 2:15 PM, Keith Thompson wrote:
> But there's still a mystery here. Why does it behave differently under rxvt
> vs. xterm,
> and why does that difference show up in bash 4.4-beta but not in 4.3.30?
> (Both versions of bash are built from source on the same system.)
> 
> Running bash 4.3.30 under either xterm 261 or rxvt v2.6.4, I get:
> 
> bash-4.3$ trap
> trap -- '' SIGTSTP
> trap -- '' SIGTTIN
> trap -- '' SIGTTOU
> 
> and Ctrl-Z works correctly.
> 
> Running bash-4.4-beta under xterm, I get
> 
> bash-4.4$ trap
> trap -- '' SIGTTOU
> 
> and Ctrl-Z works correctly.  Running bash-4.4-beta under rxvt, I get:
> 
> bash-4.4$ trap
> trap -- '' SIGTSTP
> trap -- '' SIGTTIN
> trap -- '' SIGTTOU
> 
> and Ctrl-Z *doesn't* work.

It seems like you need to figure out why rxvt starts the shell with
SIGTSTP ignored.  It doesn't seem like anything that the system /bin/sh
or the bash version you're running does, since xterm doesn't exhibit
this behavior.

The difference between bash-4.3 and bash-4.4 is a bug fix: if the shell
is started with SIGTSTP ignored (any signal, really), it's supposed to
pass that setting on to the children it invokes.  bash-4.3 didn't do that
in this case, and bash-4.4 does.

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: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey  wrote:

>
>
> It seems like you need to figure out why rxvt starts the shell with
> SIGTSTP ignored.  It doesn't seem like anything that the system /bin/sh
> or the bash version you're running does, since xterm doesn't exhibit
> this behavior.
>
> The difference between bash-4.3 and bash-4.4 is a bug fix: if the shell
> is started with SIGTSTP ignored (any signal, really), it's supposed to
> pass that setting on to the children it invokes.  bash-4.3 didn't do that
> in this case, and bash-4.4 does.
>
>
And I think I've found it.  In rxvt 2.6.4, src/command.c:

 /*
 * mimick login's behavior by disabling the job control signals
 * a shell that wants them can turn them back on
 */
#ifdef SIGTSTP
signal(SIGTSTP, SIG_IGN);
signal(SIGTTIN, SIG_IGN);
signal(SIGTTOU, SIG_IGN);
#endif  /* SIGTSTP */

The latest release, rxvt 2.7.10, has the same code in src/init.c.
rxvt-unicode (urxvt) has the same code in src/init.C.

Would you consider this a bug in rxvt? It's obviously intentional, but I
don't understand signal handling well enough to know whether it's
reasonable.
The comment implies that it's the shell's responsibility to re-enable the
signals -- which bash did prior to 4.4-beta, but no longer does.

There's certainly a bug *somewhere*, since anyone using bash 4.4-beta or
later
under rxvt or urxvt won't be able to use Ctrl-Z.  If it's rxvt that's
buggy, I'll
contact the rxvt and urxvt maintainers (and I'll probably recompile my own
version with those lines commented out).

-- 
Keith Thompson 

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Chet Ramey]

On 11/10/15 3:17 PM, Keith Thompson wrote:
> On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey  > wrote:
> 
> 
> 
> It seems like you need to figure out why rxvt starts the shell with
> SIGTSTP ignored.  It doesn't seem like anything that the system /bin/sh
> or the bash version you're running does, since xterm doesn't exhibit
> this behavior.
> 
> The difference between bash-4.3 and bash-4.4 is a bug fix: if the shell
> is started with SIGTSTP ignored (any signal, really), it's supposed to
> pass that setting on to the children it invokes.  bash-4.3 didn't do that
> in this case, and bash-4.4 does.
> 
> 
> And I think I've found it.  In rxvt 2.6.4, src/command.c:
> 
>  /*
>  * mimick login's behavior by disabling the job control signals
>  * a shell that wants them can turn them back on
>  */
> #ifdef SIGTSTP
> signal(SIGTSTP, SIG_IGN);
> signal(SIGTTIN, SIG_IGN);
> signal(SIGTTOU, SIG_IGN);
> #endif  /* SIGTSTP */
> 
> The latest release, rxvt 2.7.10, has the same code in src/init.c.
> rxvt-unicode (urxvt) has the same code in src/init.C.

Does it do this only when it's starting a login shell?  Or all interactive
shells?

See, the problem is not the behavior of the shell rxvt starts.  It's that
shells are supposed to restore the original signal dispositions when they
create processes.  A shell that has SIGTSTP ignored when it starts is
permitted to change the disposition to whatever it wants (though the user
can't set a trap on it), but is supposed to restore the original signal
handler (SIG_IGN in this case) in child processes it forks to run other
programs.

> Would you consider this a bug in rxvt? It's obviously intentional, but I
> don't understand signal handling well enough to know whether it's reasonable.
> The comment implies that it's the shell's responsibility to re-enable the
> signals -- which bash did prior to 4.4-beta, but no longer does.

That's not quite it, see above.

> There's certainly a bug *somewhere*, since anyone using bash 4.4-beta or later
> under rxvt or urxvt won't be able to use Ctrl-Z.  If it's rxvt that's
> buggy, I'll
> contact the rxvt and urxvt maintainers (and I'll probably recompile my own
> version with those lines commented out).

You might ask them to reconsider that decision.  What's the concern, that
a non-job-control shell will suspend itself when someone hits ^Z?

I can make bash blow away the original signal dispositions and pretend they
were SIG_DFL when an interactive shell starts, if there is no alternative.

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: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

On Tue, Nov 10, 2015 at 12:56 PM, Chet Ramey  wrote:

> On 11/10/15 3:17 PM, Keith Thompson wrote:
> > On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey  > > wrote:
> >
> >
> >
> > It seems like you need to figure out why rxvt starts the shell with
> > SIGTSTP ignored.  It doesn't seem like anything that the system
> /bin/sh
> > or the bash version you're running does, since xterm doesn't exhibit
> > this behavior.
> >
> > The difference between bash-4.3 and bash-4.4 is a bug fix: if the
> shell
> > is started with SIGTSTP ignored (any signal, really), it's supposed
> to
> > pass that setting on to the children it invokes.  bash-4.3 didn't do
> that
> > in this case, and bash-4.4 does.
> >
> >
> > And I think I've found it.  In rxvt 2.6.4, src/command.c:
> >
> >  /*
> >  * mimick login's behavior by disabling the job control signals
> >  * a shell that wants them can turn them back on
> >  */
> > #ifdef SIGTSTP
> > signal(SIGTSTP, SIG_IGN);
> > signal(SIGTTIN, SIG_IGN);
> > signal(SIGTTOU, SIG_IGN);
> > #endif  /* SIGTSTP */
> >
> > The latest release, rxvt 2.7.10, has the same code in src/init.c.
> > rxvt-unicode (urxvt) has the same code in src/init.C.
>
> Does it do this only when it's starting a login shell?  Or all interactive
> shells?
>

It looks like it does it for all interactive shells.  For all 4 combinations
(rxvt vs. rxvt -ls, xterm --norc vs. xterm --norc --login),
Ctrl-Z doesn't work.


> See, the problem is not the behavior of the shell rxvt starts.  It's that
> shells are supposed to restore the original signal dispositions when they
> create processes.  A shell that has SIGTSTP ignored when it starts is
> permitted to change the disposition to whatever it wants (though the user
> can't set a trap on it), but is supposed to restore the original signal
> handler (SIG_IGN in this case) in child processes it forks to run other
> programs.
>
> > Would you consider this a bug in rxvt? It's obviously intentional, but I
> > don't understand signal handling well enough to know whether it's
> reasonable.
> > The comment implies that it's the shell's responsibility to re-enable the
> > signals -- which bash did prior to 4.4-beta, but no longer does.
>
> That's not quite it, see above.
>
> > There's certainly a bug *somewhere*, since anyone using bash 4.4-beta or
> later
> > under rxvt or urxvt won't be able to use Ctrl-Z.  If it's rxvt that's
> > buggy, I'll
> > contact the rxvt and urxvt maintainers (and I'll probably recompile my
> own
> > version with those lines commented out).
>
> You might ask them to reconsider that decision.  What's the concern, that
> a non-job-control shell will suspend itself when someone hits ^Z?
>
> I can make bash blow away the original signal dispositions and pretend they
> were SIG_DFL when an interactive shell starts, if there is no alternative.
>
> Thanks, I'll pass this information on to the rxvt and urxvt maintainers.

-- 
Keith Thompson 

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Andreas Schwab]

Chet Ramey  writes:

> I can make bash blow away the original signal dispositions and pretend they
> were SIG_DFL when an interactive shell starts, if there is no alternative.

Given that login(1) has the same behaviour there is probably no
alternative.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab 
wrote:

> Chet Ramey  writes:
>
> > I can make bash blow away the original signal dispositions and pretend
> they
> > were SIG_DFL when an interactive shell starts, if there is no
> alternative.
>
> Given that login(1) has the same behaviour there is probably no
> alternative.
>
> Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and
Ctrl-Z works correctly.
I verified that the shell's parent process was "login".
Perhaps (at least the Debian version of) login(1) *doesn't* do that.

-- 
Keith Thompson 

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

[Keith Thompson]

On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson 
wrote:

> On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab 
> wrote:
>
>> Chet Ramey  writes:
>>
>> > I can make bash blow away the original signal dispositions and pretend
>> they
>> > were SIG_DFL when an interactive shell starts, if there is no
>> alternative.
>>
>> Given that login(1) has the same behaviour there is probably no
>> alternative.
>>
>> Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and
> Ctrl-Z works correctly.
> I verified that the shell's parent process was "login".
> Perhaps (at least the Debian version of) login(1) *doesn't* do that.
>
> I'm going to hold off on contacting the rxvt and urxvt developers
for now.  If you decide to modify bash to blow away the original signal
dispositions, there's no point in reporting this as a bug in rxvt.

Does that make sense?

-- 
Keith Thompson