Re: [PATCH] Add active mark, face support; activate mark on paste
On 4/12/20 6:23 PM, Chet Ramey wrote: On 4/12/20 2:15 PM, gentoo_esh...@tutanota.com wrote: There is one more/different 'face' issue: if I paste a line and then press Enter (as opposed to any alphanumeric key or arrow keys) then the highlight remains(highlighted), possibly because the ^M is echoed and thus moves the cursor one line up(?) before the highlight is attempted to be removed. But I'm just guessing. Unsurprising. The highlights are added and removed in readline's redisplay. Once you enter newline (or any key bound to accept-line), readline returns the line immediately without any redisplay, so the line remains as is. Is that a regression relative to my original patch? I could have sworn I made command submission deactivate the mark and redisplay, but maybe I'm recalling incorrectly. In any case, isn't that the right thing to do? FWIW, for debugging the kinds of issues we're discussing here, rr(1) is _incredibly_ helpful.
Re: [PATCH] Add active mark, face support; activate mark on paste
On 4/12/20 2:15 PM, gentoo_esh...@tutanota.com wrote: > There is one more/different 'face' issue: if I paste a line and then press > Enter (as opposed to any alphanumeric key or arrow keys) then the highlight > remains(highlighted), possibly because the ^M is echoed and thus moves the > cursor one line up(?) before the highlight is attempted to be removed. But > I'm just guessing. Unsurprising. The highlights are added and removed in readline's redisplay. Once you enter newline (or any key bound to accept-line), readline returns the line immediately without any redisplay, so the line remains as is. > That's an intriguing patch format, may I inquire as to how it was generated > (some unusual 'diff' args?) ? That's OG BSD context diff format (diff -c), which dates from 1981. I find it easier to read than unified or `git' format. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Add active mark, face support; activate mark on paste
Apr 12, 2020, 19:30 by chet.ra...@case.edu: > > I'm glad it worked, but I think this is a more correct version: > > *** ../bash-20200408/lib/readline/display.c 2020-04-07 14:55:15.0 > -0400 > --- lib/readline/display.c2020-04-12 12:01:22.0 -0400 > *** > *** 1759,1762 > --- 1759,1765 > nd = newbytes; > nfd = new + nd; > + ofdf = old_face + oldbytes; > + nfdf = new_face + newbytes; > + > goto dumb_update; > } > tested it to (also) work. There is one more/different 'face' issue: if I paste a line and then press Enter (as opposed to any alphanumeric key or arrow keys) then the highlight remains(highlighted), possibly because the ^M is echoed and thus moves the cursor one line up(?) before the highlight is attempted to be removed. But I'm just guessing. >>> >>> > > It may be the case that this is called from a signal handler context, where > the terminating signal is blocked. This patch should fix that: > > *** ../bash-20200408/sig.c2020-04-07 16:41:19.0 -0400 > --- sig.c 2020-04-12 13:26:50.0 -0400 > *** > *** 609,613 > /* We don't change the set of blocked signals. If a user starts the shell > with a terminating signal blocked, we won't get here (and if by some > ! magic chance we do, we'll exit below). */ > set_signal_handler (sig, SIG_DFL); > > --- 609,617 > /* We don't change the set of blocked signals. If a user starts the shell > with a terminating signal blocked, we won't get here (and if by some > ! magic chance we do, we'll exit below). What we do is to restore the > ! top-level signal mask, in case this is called from a terminating signal > ! handler context, in which case the signal is blocked. */ > ! restore_sigmask (); > ! > set_signal_handler (sig, SIG_DFL); > > Confirmed working, much appreciated. Cheers! That's an intriguing patch format, may I inquire as to how it was generated (some unusual 'diff' args?) ?
Re: [PATCH] Add active mark, face support; activate mark on paste
On 4/12/20 1:04 AM, gentoo_esh...@tutanota.com wrote:
>
>
>
> Apr 11, 2020, 23:11 by chet.ra...@case.edu:
>
>> On 4/11/20 12:04 PM, gentoo_esh...@tutanota.com wrote:
>>
What's your $PS1?
>>> $ echo $PS1
>>> \ ---\n\ \[\a\]\ \[\e[1;37m\e[42m\]\u@\H\[\e[0m\] \
>>> \[\033[1;30m\]$(date "+%Y/%m/%d %H:%M:%S")\[\033[0m\] \ \[\e[0;37m\]\s\V
>>> t:\l j:\j \ d:${SHLVL} pp:${PPID} p:$$ ut`cat /proc/uptime | cut -f1
>>> -d.`\[\e[0m\]\n\ \[\e[0;37m\]!\!\[\e[0m\] \ \[\033[0;36m\]\#\[\033[0m\] \
>>> $(evalexitcode "${__earlyec[@]}" ) \ \[\e[0m\]$(uname -r) $(uname -v)
>>> $(ps_lepath "\w")\[ \033];\w\a\] \[\e[1;32m\]\$\[\e[0m\] \
>>>
>>
>> I have to hand it to you; that's one of the most complicated prompt strings
>> I've ever seen.
>>
>> In any event, that didn't help me reproduce the seg fault, but I was able
>> to use the stack traceback you sent to find a problem. I've attached a
>> patch.
>>
>
> This is amazing, that patch completely fixed the issue, thank you!
I'm glad it worked, but I think this is a more correct version:
*** ../bash-20200408/lib/readline/display.c 2020-04-07 14:55:15.0
-0400
--- lib/readline/display.c 2020-04-12 12:01:22.0 -0400
***
*** 1759,1762
--- 1759,1765
nd = newbytes;
nfd = new + nd;
+ ofdf = old_face + oldbytes;
+ nfdf = new_face + newbytes;
+
goto dumb_update;
}
>> Bash does catch SIGSEGV and does some cleanup, to the extent that it can do
>> anything, and kills itself with the same signal (that's why you see 139 as
>> the exit status). That should still result in a core dump.
>>
> Oh that's good to know. I've tracked down the issue to an exit that happens
> before bash gets the chance to re-issue the coredump/kill self with SEGV, by
> using the attached patch to simulate a segmentation fault inside bash, I get
> this:
> $ ./bash
> TERM='xterm-256color'
> /usr/bin/blugon
> 2069.22 7138.70
> ---
> user@Z575 2020/04/12 07:00:36 bash5.0.16 t:6 j:0 d:4 pp:16407 p:155787 ut2069
> !76112 1 0 5.6.3-gf9fb85751506 #90 SMP PREEMPT Thu Apr 9 19:22:52 CEST 2020
> /home/user/build/1packages/4used/bash-devel-git/makepkg_pacman/bash/src/bash
> $ !1!
> !2!
> !3!
> !4!
>
> that "!4!" is in sig.c here:
> if (dollar_dollar_pid != 1) {
> fprintf (stderr, "!4!\n");fflush (stderr);
> exit (128+sig); /* just in case the kill fails? */
> }
That code happens after bash sets the signal handler to SIG_DFL and resends
itself the signal with kill(2), so it's supposed to ensure exit if the kill
fails to kill the bash process.
It avoids the rest of the code in the function, which is supposed to handle
this pathological Linux situation described in this thread:
https://lists.gnu.org/archive/html/bug-bash/2018-04/msg00088.html
https://lists.gnu.org/archive/html/bug-bash/2018-05/msg1.html
It may be the case that this is called from a signal handler context, where
the terminating signal is blocked. This patch should fix that:
*** ../bash-20200408/sig.c 2020-04-07 16:41:19.0 -0400
--- sig.c 2020-04-12 13:26:50.0 -0400
***
*** 609,613
/* We don't change the set of blocked signals. If a user starts the shell
with a terminating signal blocked, we won't get here (and if by some
! magic chance we do, we'll exit below). */
set_signal_handler (sig, SIG_DFL);
--- 609,617
/* We don't change the set of blocked signals. If a user starts the shell
with a terminating signal blocked, we won't get here (and if by some
! magic chance we do, we'll exit below). What we do is to restore the
! top-level signal mask, in case this is called from a terminating signal
! handler context, in which case the signal is blocked. */
! restore_sigmask ();
!
set_signal_handler (sig, SIG_DFL);
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
