Re: [PATCH] Add active mark, face support; activate mark on paste
On Tue, Sep 24, 2019 at 10:20 PM Daniel Colascione wrote: > > On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote: > > > > On 9/23/19 7:32 AM, Daniel Colascione wrote: > > > On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote: > > >> > > >> On 1/9/19 2:39 PM, Daniel Colascione wrote: > > >>> Any chance we can revive this patch now that Bash 5 is out? (The patch > > >>> itself, of course, would need to be rebased.) > > >> > > >> Yes, I plan to. > > > > > > Have you had a chance to look at the patch? > > > > Sorry, I have not. I need a bigger chunk of time than I've had available > > to figure out the intent of the patches, and whether they're a good idea > > to include in readline, before looking closely at the code. > > I've had a people tell me that this patch is very useful for helping > them understand editing operations and pasting. I sent this patch over > a year and a half ago. Should I expect another year and a half of > pinging this thread? :-) Is there anything I can do to get this patch looked at?
Re: Filename Expansion bug
On 1/8/20 2:34 AM, Mickael KENIKSSI wrote: Hello, I found a bug regarding how pathnames are processed during filename expansion. The result for non-normalized path-patterns may get mangled in a such a way that it becomes inconsistent and unpredictable, making it useless for string comparison or any kind of string manipulation where having it in the exact same form as the pattern is required. How to reproduce : $ mkdir -p a/b/c d/e/f g/h/e; printf '%s\n' .*//*///* .a/b/c .d/e/f .g/h/e This is correct from a filesystem perspective but not from a string perspective, where you'd need each of the computed path as-is: .a//b///c .d//e///f .g//h///i You're not going to get the path with multiple slashes preceding pattern characters, because the pathname has single slashes, those slashes are, as POSIX says, "explicitly matched by using one or more characters in the pattern," and the matched pathnames that replace the pattern don't have multiple slashes. The reason that the three leading slashes aren't removed is that those directory names don't have any pattern characters and are left unchanged. Since the kernel's filename resolution treats multiple slashes the same as a single slash, the constructed pathname matches what's in the file system. That means, for instance, you have a directory `.' and a pattern `*'. You opendir `' and read it for every filename matching `*' (a, d, g), construct the pathnames, and go on with the rest of the pattern. The intermediate runs of multiple slashes get removed as part of the matching algorithm, as described above. They're essentially null pathname components. -- ``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: Cursor can land before the prompt after calling beginning-of-line
On 1/8/20 4:13 AM, Julien Palard wrote: It can be reproduced on Debian bullseye with bash 5.0.11 on urxvt and xterm and by a friend on MacOS with bash 3.2.57. With this procedure I'm able to reproduce it consistently: - Move ~/.bashrc elsewhere just to start clean - Start a new terminal (in my case tput cols tells it's 79 columns, beware, the bug varies according to the terminal width). - run `bash --norc` in it, to start clean - Prompt in my case is `bash-5.0$ `, beware, the bug varies according to the length of the prompt. - type `printf "Hello World\n"` (1) - hit the `uparrow` of your keyboard to see the printf again (2) - hit C-a (bash shortcut for beginning-of-line) (3) Readline assumes it starts in column 0. If it doesn't know the physical screen position of the cursor when it starts, it can't make correct decisions about redisplay. Sometimes it wants to go to the beginning of the line and redraw/erase characters, sometimes it wants to move backwards and do it, but all these decisions assume that it knows where it is on the line. -- ``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/
Cursor can land before the prompt after calling beginning-of-line
It can be reproduced on Debian bullseye with bash 5.0.11 on urxvt and xterm and by a friend on MacOS with bash 3.2.57. With this procedure I'm able to reproduce it consistently: - Move ~/.bashrc elsewhere just to start clean - Start a new terminal (in my case tput cols tells it's 79 columns, beware, the bug varies according to the terminal width). - run `bash --norc` in it, to start clean - Prompt in my case is `bash-5.0$ `, beware, the bug varies according to the length of the prompt. - type `printf "Hello World\n"` (1) - hit the `uparrow` of your keyboard to see the printf again (2) - hit C-a (bash shortcut for beginning-of-line) (3) After (1) you should see (I'm using ■ to mark the place of the cursor) which is OK: bash-5.0$ printf "Hello World\n Hello World bash-5.0$ ■ After (2) you should see (still OK): bash-5.0$ printf "Hello World\n" Hello World bash-5.0$ printf "Hello World\n"■ After (3) you should see (not OK): bash-5.0$ printf "Hello World\n" Hello World ■ bash-5.0$ printf "Hello World\n" The cursor should not go that far, it should stop on the `p` of `printf`. I straced and played a bit with, and noted a few interesting things: - Bug appear, or not, depending on the length of the prompt (happen with short prompts, bug disapear with long prompts) - Bug appear, or not, depending on the length of the command (happend with long commands, bug disapear with short commands) - Bug appear, or not, depending on the width of the terminal - When beginning-of-line calls `write(2, "\r\33[C\33[C\33[C\33[C\33[C...` I have the bug - When beginning-of-line calls `write(2, "\10\10\10\10\10\10\10\10\10...` I don't have the bug It can be reproduced without using spaces: mdk@seraph:~$ printf "Hello World\n01234567890123456789" Hello World 01234567890123456789mdk@seraph:~$ printf "Hello World\n01234567890123456789" ^ The point jumps here (on the 2nd 4) Cross-posted here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948343 -- Julien Palard https://mdk.fr
Filename Expansion bug
Hello, I found a bug regarding how pathnames are processed during filename expansion. The result for non-normalized path-patterns may get mangled in a such a way that it becomes inconsistent and unpredictable, making it useless for string comparison or any kind of string manipulation where having it in the exact same form as the pattern is required. How to reproduce : $ mkdir -p a/b/c d/e/f g/h/e; printf '%s\n' .*//*///* > .a/b/c > .d/e/f > .g/h/e > This is correct from a filesystem perspective but not from a string perspective, where you'd need each of the computed path as-is: .a//b///c > .d//e///f > .g//h///i > This occurs on all versions >= Bash 3.2. Best regards, Mickaël
