`{q}` isn't escaped properly on Windows about fzf

[junegunn]

Thanks for the input. Will check again later, for some reason I can't connect to a Windows EC2 instance. 🤷

[junegunn]

Thanks for reporting this serious issue. 0.52.1 is a (hurried) attempt to fix the issue. Please test if it helps. I'm sure there are some other issues lurking, but at least it should be safer than what we had in 0.52.0.

[ibhagwan]

FYI, the last working version is 0.50, due to the fact the " is prefixed with a caret ^.

Using the below command we fail on purpose so we can look at the escaping sequence:

fzf --ansi --disabled --bind="change:IF {q}"

0.52 escape sequence

0.50 escape sequnece

[junegunn]

Searching for " works for me.

It works on cmd.exe,

And it works with :RG command of fzf.vim

I'm testing this on an EC2 Windows 16 server instance. Not sure if things are different on different versions of Windows.

[ibhagwan]

Searching for " works for me.

Does it also work with (when {q} isn't the last argument of the cmd)?

fzf --ansi --disabled --bind="change:reload:rg --line-number --column --color=always {q} 2>&1"

[ibhagwan]

@junegunn, you didn't test my use-case properly, I can see the command you ran in the screenshot:

THIS WORKS

fzf --disabled --preview-window up --preview "rg --line-number --column --color=always -- {q}"

BOTH WORK ON 0.50 AND FAIL ON 0.52

fzf --disabled --preview-window up --preview "rg --line-number --column --color=always -- {q} 2>&1"
fzf --disabled --preview-window up --preview "rg --line-number --column --color=always -- {q} || break"

The reason I need to add 2&1 || break is explained in the OP.

[ibhagwan]

@junegunn, the current escape sequnce also fails when searching for special characters prefixed by ", try:

fzf --disabled --preview-window up --preview "rg --line-number --column --color=always -- {q}"

Search for "\|

Search for ".*&, the & part of the regex is ignored, effectively searching for ".* only

Similarly serching for "\^ ignores the caret

Searching for "< or ">

fzf.vim's RG will also fail with these examples:

[ibhagwan]

Thanks for reporting this serious issue. 0.52.1 is a (hurried) attempt to fix the issue. Please test if it helps. I'm sure there are some other issues lurking, but at least it should be safer than what we had in 0.52.0.

Tysm @junegunn! I have seen some other oddities happening but will have to test this throughly so I can pinpoint the exact issue and whether this is a bug or just different behavior for which fzf-lua will have to adjust.

Will report back tomorrow.

[ibhagwan]

@junegunn, everything seems to be in order at first glance, but I think that ; also needs to be escaped with a caret.

Consider the following which attempts to run rg only when the user inputs a non-empty string (to avoid feeding all project lines unnecessarily):

fzf --ansi --disabled --bind="change:reload:IF {q} NEQ \^"^^\" rg --line-number --column --color=always {q}"

The condition works fine in all special characters I tested aside from ;, using ^; (in the code) solves the issue:

I believe ; should be added to the list of special characters in:

fzf/src/util/util_windows.go

Line 24 in 6432f00

var escapeRegex = regexp.MustCompile(`[&|<>()^%!"]`)

So that it will later be preceded by ^ in:

fzf/src/util/util_windows.go

Lines 137 to 139 in 6432f00

	return escapeRegex.ReplaceAllStringFunc(string(b), func(match string) string {
	return "^" + match
	})

[junegunn]

So I guess the problem with ; is relatively benign compared to the previous flaw, which would allow all kinds of crazy stuff?
Didn't know ; needed escaping. I'll address it in the next release. But I'm not going to rush it and take some time to hear from other Windows users (#3790).

In the meantime, maybe you could work around it by using a batch file and not directly writing conditionals in the binding expression? Just guessing.

[ibhagwan]

So I guess the problem with ; is relatively benign compared to the previous flaw, which would allow all kinds of crazy stuff? Didn't know ; needed escaping. I'll address it in the next release. But I'm not going to rush it and take some time to hear from other Windows users (#3790).

I also had no idea ; was a meta character, definitely no rush in this it’s totally benign.

In the meantime, maybe you could work around it by using a batch file and not directly writing conditionals in the binding expression? Just guessing.

I already have this handled in the lua wrapper this was just something that was popping up in the native versions of the pickers, it’s an edge case of an edge case.

[junegunn]

Good to hear that, thanks.