printf %ls conversion

The mbsrtowcs call here doesn't convert the final \0 of mbs, leaving the final byte of ws as whatever was just malloc-ed. Noticed in an ASAN build which makes sure that this is never L'\0'. Oddly, this didn't actually trigger an ASAN report, just saw that nothing was getting printed by printf. --

Docs: "shell-transpose-words" in "8.4.4 Killing And Yanking"

Hello, The "shell-transpose-words" command is documented in the section "8.4.4 Killing And Yanking", but I think it should be in "8.4.3 Commands For Changing Text". That way, just like the other "shell-*" commands, it would be documented next to its counterpart "transpose-words". Thanks.

Re: printf %ls conversion

On 7/17/23 3:19 AM, Grisha Levit wrote: The mbsrtowcs call here doesn't convert the final \0 of mbs, leaving the final byte of ws as whatever was just malloc-ed. Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' -

Re: [PATCH] print regerror string on regcomp error

On 7/12/23 12:01 PM, Grisha Levit wrote: Since bash-5.3 now shows an error message when a regular expression can't be compiled, I thought it might be useful to add the regerror()-supplied string that provides more specifics on the failure, so we can get messages like: $ [[ x =~ [z-a] ]] bash: [[

Re: [PATCH] print regerror string on regcomp error

On Mon, Jul 17, 2023, 12:09 Chet Ramey wrote: > I guess we'll see how much the text of regerror(3) > error messages varies across regexp implementations. > Is that a concern? The GNU strings [1] are translated and even their untranslated text does differ from that of the BSD ones [2]. The set o

Re: [PATCH] print regerror string on regcomp error

On 7/17/23 1:10 PM, Grisha Levit wrote: On Mon, Jul 17, 2023, 12:09 Chet Ramey > wrote: I guess we'll see how much the text of regerror(3) error messages varies across regexp implementations. Is that a concern? The GNU strings [1] are translated and even t

Re: [PATCH] normalization tweaks for macOS

On 7/7/23 5:05 PM, Grisha Levit wrote: A few small tweaks for the macOS-specific normalization handling to handle the issues below: The issue is that the behavior has to be different between cases where the shell is reading input from the terminal and gets NFC characters that need to be convert

Re: Docs: "shell-transpose-words" in "8.4.4 Killing And Yanking"

On 7/17/23 4:06 AM, Sebastian Carlos wrote: Hello, The "shell-transpose-words" command is documented in the section "8.4.4 Killing And Yanking", but I think it should be in "8.4.3 Commands For Changing Text". That way, just like the other "shell-*" commands, it would be documented next to its c

Re: Some Readline variables are not available in "bind -v"

On 7/16/23 9:25 AM, Sebastian Carlos wrote: Hello, I noticed that the following variables are not visible in "bind -v": - active-region-start-color - active-region-end-color Thanks for the report. These two variables aren't reported by `bind -v' if they have a value, so that needs to be fixed.

Re: history-size reported as "0" even is value is "-1"

On 7/16/23 7:28 AM, Sebastian Carlos wrote: Hello, history-size is documented as follows: If set to a value less than zero, the number of history entries is not limited. But after setting it to "-1", for example with this line in .inputrc: set history-size -1 It is still reported as "0" in

Re: [PATCH] normalization tweaks for macOS

On Mon, Jul 17, 2023 at 3:29 PM Chet Ramey wrote: > > On 7/7/23 5:05 PM, Grisha Levit wrote: > > A few small tweaks for the macOS-specific normalization handling to > > handle the issues below: > > The issue is that the behavior has to be different between cases where > the shell is reading input

[PATCH] fix bind -X quoting

The output of `bind -X' is not reusable if the bound command has quotes, backslashes, etc. $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo \"x\"" $ bind -x "$(bind -X)" $ bind -X "\eX": "echo \\\"x\\\"" This patch changes rl_macro_dumper to not untranslate the macro body when passed a negative