Re: [PATCH] Add active mark, face support; activate mark on paste

[gentoo_eshoes]

Apr 11, 2020, 17:19 by chet.ramey@case.edu:

> On 4/11/20 8:43 AM, gentoo_eshoes@tutanota.com wrote:
>
>> It silently segfaults when pasting a line of text twice(or a long enough 
>> line once), seems to be length dependent, unsure.
>>
>> Removing commit ea31c00845c858098d232bd014bf27b5a63a668b from only the file 
>> lib/readline/display.c  works around the issue.
>>
>
> Well, sure, since that's the commit that adds the face changes to
> redisplay.
>
true, but my intent was to say that even though that commit also modifies other 
files(since it seems to be an aggregation of a bunch of commits with 
unrelated-to-'face' changes inside it) I only reverted the changes in that 
file, as I've no idea in which other files those specific 'face' changes were. 
Anyway, it doesn't matter, but it does make bisecting a bit harder with regards 
to pinpointing the exact culprit.

commit ea31c00845c858098d232bd014bf27b5a63a668b
Date:   Wed Apr 8 17:09:56 2020 -0400

    commit bash-20200406 snapshot


>
> 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\] \

$ echo ${PS1@A}
declare -x 
PS1=$'\\\n-----------\\n\\\n\\[\\a\\]\\\n\\[\\e[1;37m\\e[42m\\]\\u@\\H\\[\\e[0m\\]
 \\\n\\[\\033[1;30m\\]$(date "+%Y/%m/%d %H:%M:%S")\\[\\033[0m\\] 
\\\n\\[\\e[0;37m\\]\\s\\V t:\\l j:\\j \\\nd:${SHLVL} pp:${PPID} p:$$ ut`cat 
/proc/uptime | cut -f1 -d.`\\[\\e[0m\\]\\n\\\n\\[\\e[0;37m\\]!\\!\\[\\e[0m\\] 
\\\n\\[\\033[0;36m\\]\\#\\[\\033[0m\\] \\\n$(evalexitcode "${__earlyec[@]}" ) 
\\\n\\[\\e[0m\\]$(uname -r) $(uname -v)\n$(ps_lepath "\\w")\\[ 
\\033];\\w\\a\\]\n\\[\\e[1;32m\\]\\$\\[\\e[0m\\] \\\n'

evalexitcode () 
{ 
    local ps=("$@");
    for i in "${ps[@]}";
    do
        if test "$i" -ne "0"; then
            echo -ne "\x01\e[1;31m\x02${i}\x01\e[0m\x02 ";
        else
            echo -ne "\x01\e[1;30m\x02${i}\x01\e[0m\x02 ";
        fi;
    done
}

ps_lepath () 
{ 
    local lepath="$*";
    local lepath2="${*#\~}";
    if test "$lepath" != "$lepath2"; then
        lepath="$(realpath ~)${lepath2}";
    fi;
    printf %q "${PWD}"
}

$ echo $PROMPT_COMMAND
__earlyec=("${PIPESTATUS[@]}")
$ echo ${PROMPT_COMMAND@A}
declare -x PROMPT_COMMAND='__earlyec=("${PIPESTATUS[@]}")'

/usr/bin/cat is owned by coreutils 8.32-1
/usr/bin/uname is owned by coreutils 8.32-1
/usr/bin/date is owned by coreutils 8.32-1


>> Please someone tell me how to disable bash's trapping of SIGSEGV so that the 
>> OS is allowed to generate a proper coredump(ctl), rather than have bash 
>> silently exit with exit code 139, for future reference.
>>
>
> You should just have to run `ulimit -c unlimited'.
>
Thank you for your reply. It was already 'unlimited'. But when firefox 
segfaults it works (that is, `coredumpctl -r`  does list it), yet it doesn't 
happen for bash and I thought it's because bash is somehow catching it and 
handling it internally, just like this sample program does it (for which only 
gdb can catch it, just like for bash): http://wulf.eu.org/code/fix-segfault.c
But given your reply, I'm starting to wonder if it's something else going wrong 
on my OS, though a dummy test seems to imply not:
$ ./a.out 
Segmentation fault (core dumped)$ coredumpctl -r|head -2
TIME                            PID   UID   GID SIG COREFILE  EXE
Sat 2020-04-11 17:54:45 CEST 138406  1000  1000  11 present   /tmp/a.out
$ cat a.c
int main() {
  int *a=0;
  *a=1;
}

So I'm a little lost.

>
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>