Re: rl_filename_rewrite_hook called on wrong filename

[Grisha Levit]

On Tue, Sep 26, 2023, 10:24 Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 9/25/23 7:02 PM, Karl O. Pinc wrote:
> > On Mon, 25 Sep 2023 18:35:53 +0200
> > "Stefan H. Holek" <stefan@epy.co.at> wrote:
> >
> >> I am however not sure supporting different character sets is still
> >> useful in 2023. Everything is UTF-8 these days, and your code is fine
> >> if NFD/NFC is the only problem we have to solve.
> >
> > I am not following the details here but I've noticed some
> > cloud providers provision C.UTF-8 by default.  This may
> > not be relevant, but is certainly ASCII-like so I thought
> > you might want to know.
>
> Right now, this code is only active on macOS, which doesn't yet support
> C.UTF-8 (at least as of Ventura).

I think the issue Stefan brings to light is that, while the filename rewrite
hook installed by Bash is a noop other than on macOS, Readline will now apply
any existing rewrite hook to the completion word, which existing hooks (if
such exist) are likely not designed to deal with.

E.g., if one already had a rewrite hook to convert UTF-8 file system names
for matching (in as much as that is possible) against ISO-8859-1 terminal

text, applying that same hook now to terminal input as well will produce

garbage results.

Not sure if this is kind of hook is actually part of something people are

still building against new Readline versions but I would feel bad breaking

backwards compatibility needlessly so here's a patch to split up the hook

that gets applied to the filename portion of the input from the hook that

gets applied to directory entries read from the file system, in case that

seems reasonable to you.

0001-split-rl_filename_-rewrite-completion-_hook.patch
Description: Source code patch