Cursor jumps to leftmost column on trap ... SIGALRM
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
uname output: Linux .fraunhofer.de 5.15.12-200.fc35.x86_64
#1 SMP Wed Dec 29 15:03:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.1
Patch Level: 8
Release Status: release
Description:
The position of the cursor changes to the first column when bash,
running inside xterm, receives the signal SIGALRM
Expected behavior: No change in cursor position
Repeat-By:
# Start a bash in xterm w/o customizations
xterm -class nothing -e bash --norc &
# within this xterm, enter:
function sigalarm_test { echo -n ; } # define an empty signal handler
trap sigalarm_test SIGALRM# install the signal handler
echo $$ # report the shells PID
# in a different shell, send SIGALRM to the PID of the previously
started bash
kill -s SIGALRM PID # use the PID reported by 'echo
$$' above
=> now the cursor position jumps to the first column in the xterm
running bash
So far I've watched this behavior only with SIGALRM.
Re: Cursor jumps to leftmost column on trap ... SIGALRM
On Fri, 4 Feb 2022 13:19:37 -0500 Chet Ramey wrote: > On 2/4/22 9:54 AM, Markus Schwarzenberg wrote: > > > Bash Version: 5.1 > > Patch Level: 8 > > Release Status: release > > > > Description: > > The position of the cursor changes to the first column when > > bash, running inside xterm, receives the signal SIGALRM > > Thanks for the report. It's readline and bracketed paste. Interestingly, I can't reproduce the behavior myself on the following system (opensuse tumbleweed) Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fun> uname output: Linux XXX 5.15.12-1-default #1 SMP Wed Dec 29 14:50:16 UTC 2> Machine Type: x86_64-suse-linux-gnu Bash Version: 5.1 Patch Level: 12 Release Status: release [ ... ] > We can force a redisplay in the code that handles the return from the > signal handler. That, however, has its own problems. If the > application's signal handler doesn't do anything, forcing the cursor > to a new line and forcing a redisplay will result in duplicated > lines. (If we don't force a new line, we can potentially overwrite > output from the application's signal handler.) > > I'll have to think about it. I'd be happy with some command forcing redisplay, executed from within the handler as a workaround. Note: The example given in the bug description is just the simplest way to reproduce that behavior. Practically I've been using the SIGALRM handler for really a long period now (ca. 20 years). Usage: It's invoked from a xterm key binding and finally makes the running bash open a file guessed from the currently selected ls -l output line (or gcc error line, etc.). The observed readline behavior is quite new ( < 1 year). It didn't happen in older versions. Thanks, Markus Schwarzenberg
Re: Cursor jumps to leftmost column on trap ... SIGALRM
On Fri, 4 Feb 2022 17:37:06 -0500 Chet Ramey wrote: > It depends on whether or not bracketed paste is active. Must admit I wasn't aware of this. And will think about whether I need it. > On 2/4/22 4:11 PM, Markus Schwarzenberg wrote: > > On Fri, 4 Feb 2022 13:19:37 -0500 > > Chet Ramey wrote: > > > > I'd be happy with some command forcing redisplay, executed from > > within the handler as a workaround. > > On a new line? Duplicating what was there before the SIGALRM? I think > you'd be surprised at how many people would disagree with you. Didn't mean on a new line, of course. Rather tought of a kind of redraw command. Markus
eval complains about array syntax valid in bash-3.0.16
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.8
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8'
-DCONF_VENDOR='sun' -DLOCALEDIR='/sw/opensrc/gnu/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-I/sw/opensrc/gnu/include -I/sw/opensrc/include -I/sw/opensrc/include/freetype2
-I/usr/local/ssl/include -O6
uname output: SunOS suni2 5.8 Generic_117350-24 sun4u sparc SUNW,Sun-Blade-2500
Machine Type: sparc-sun-solaris2.8
Bash Version: 3.1
Patch Level: 0
Release Status: release
Description:
Assigning arrays using
testvar=( $(echo A) $(echo B) )
is accepted in bash-3.1.0. However, using the
same in an eval-construct
eval testvar=( $(echo A) $(echo B) )
is rejected:
bash: syntax error near unexpected token `('
This behavior is different in bash-3.0.16, where the eval statement is
accepted.
I'm not shure whether that's a real bug or 3.0.16 was too tolerant.
Repeat-By:
eval testvar=( $(echo A) $(echo B) )
Fix:
Workaround:
eval testvar="(" $(echo A) $(echo B) ")"
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
eval in functions in pipelines doesn't set variables globally
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.8
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8'
-DCONF_VENDOR='sun' -DLOCALEDIR='/sw/opensrc/gnu/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-I/sw/opensrc/gnu/include -I/sw/opensrc/include -I/sw/opensrc/include/freetype2
-I/usr/local/ssl/include -O6
uname output: SunOS suni2 5.8 Generic_117350-24 sun4u sparc SUNW,Sun-Blade-2500
Machine Type: sparc-sun-solaris2.8
Bash Version: 3.1
Patch Level: 0
Release Status: release
Description:
Normally, the eval builtin used in functions to set variables
makes these variables available globally otutside the function.
However, when the function gets input from a pipline, the variables
are set only locally. This bug was already present in bash-3.0, maybe
also in earlier version. The correct behavior would be very usefull
to be able to write functions which receive stdin and put it's
contens - preprocessed by awk or similar - into an array.
Note: What I atually wanted to do was to use
function arrayset {
eval $( gawk -vn=$1 '{gsub(/"/,"\\\"");printf("%s[%i]=\"%s\";",n,NR,$0);}' )
}
to set up an array containing complete unmodified lines of input,
which is not possible using read -a (setting IFS to '\n' still
supresses whitespace betweeen the words read in, there).
Repeat-By:
Prerequisites
function evalfunc_stdin # shows the bug
{
cat > /dev/null
eval $1=$2
eval echo "inside the function $1 = ${!1}"
}
function evalfunc_nostdin # works correctly
{
eval $1=$2
eval echo "inside the function $1 = ${!1}"
}
Test Procedure:
a) correct behavior, set A=test using evalfunc_nostdin:
% unset A
% echo $A
% evalfunc_nostdin A test
inside the function A = test
% echo $A
test
---> variable A is correctly set globally
b) the bug using evalfunc_stdin
% unset B
% echo $B
% echo | evalfunc_stdin B test
inside the function B = test
% echo $B
---> variable B is not set in global scope!
Fix:
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
