Regression: FZF_CURRENT_ITEM breaks --preview when items contain NUL

[hguandl]

Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.73.0 (a24deef)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

In v0.73.0, every child process fzf spawns (eg,. preview) fails to start when the current item contains a NUL byte. v0.72.0 is unaffected.

The regression was introduced by #4803, which adds FZF_CURRENT_ITEM to the child environment by appending the raw item text:

fzf/src/terminal.go

Lines 1441 to 1443 in de1fca9

	if item := t.currentItem(); item != nil {
	env = append(env, "FZF_CURRENT_ITEM="+item.AsString(t.ansi))
	}

Items may contain NUL bytes (e.g. when --delimiter='\x00' is used to encode multi-field records on a single line). Go's os/exec rejects any environment entry containing NUL and the spawn fails, as the following command shows:

$ printf '\0foo\0/\n' | fzf --delimiter=$'\0' --preview 'echo ok'

• v0.72.0: preview window shows ok, fzf is usable.
• v0.73.0: the preview pane reports exec: environment variable contains NUL.

A typical project affected is Aloxaf/fzf-tab, which is a widely-used Zsh completion plugin. It uses \n as record separator and \x00 as an inner field delimiter to encode colors per line, paired with --delimiter='\x00' --nth=2,3. This is its core data format and has worked across many previous fzf versions. After upgrading fzf to v0.73.0, all fzf-tab previews stop working and complain the os/exec error.

[junegunn]

Thanks for the report. I'll release a bug fix release shortly.

[junegunn]

Fixed in https://github.com/junegunn/fzf/releases/tag/v0.73.1

[aktau]

Happily, I was able to use the nul-byte fix to workaround a problem introduced by FZF_CURRENT_ITEM.

Context: I'm passing the "search string" (the entire file content without newlines) as an fzf column to allow searching within it. I'm using termcode markers to gray it out so it's not visible until highlighted. It can get pretty large. The big string is column 6. The file name is column 5. I use --preview="cat {5}" to preview the file.

(I know the semi-hidden column thing is a hack, something like #4257 could help, but only if such hidden columns are not added to FZF_CURRENT_ITEM.)

Due to FZF_CURRENT_ITEM, the environment now gets so large (depending on the file) that fork/exec call fails with E2BIG). This was puzzling. It took me a long time to figure out (I ended up finding it with strace).

Now I add a \0 byte to the line (right before the newline), which disables FZF_CURRENT_ITEM.

[junegunn]

@aktau

Due to FZF_CURRENT_ITEM, the environment now gets so large (depending on the file) that fork/exec call fails with E2BIG). This was puzzling. It took me a long time to figure out (I ended up finding it with strace).

Oh, how large was the item in that case?

[junegunn]

When I decided to add the variable, I tested up to 500KB as I couldn't imagine going beyond that in ordinary use cases.

• Provide current item value as environment variable for child processes #4802 (comment)

[junegunn]

I've decided not to export the variable if the length exceeds 64KB.

• f2e4515

[aktau]

I've decided not to export the variable if the length exceeds 64KB.

Seems fine (better than previous behaviour), though I worry this might add extra slowdown to preview invocations.

Oh, how large was the item in that case?

Megabytes. Not all items were equal, which is why it worked for some but not others (puzzling me).

Like I said previously, it's a hack and I'm only doing it so that I can fuzzily search within a files contents, but also display some metadata that I want to search. Like so:

| preview: main file content (can be large)


2026-04-31 bdd2ba10-909c-479f-bfa7-26ba7d8fc626 typeB [grayed-out-entire-file-contents]
2026-05-30 d56052da-2b80-4af0-96b5-c12675857b0d typeA [grayed-out-entire-file-contents]
> foo bar 'bloop

A truncated version of the pipeline:

awk '{
      # ...
      print substr($1, 1, 19), source, id, slice(a,1, n-3), overview, "\033[8;38;5;232m" content "\033[0m\0"
}'
fzf \
    --delimiter $'\t' \
    --freeze-left 3 \
    --with-nth 1,2,3,5,6 \
    --accept-nth 4 \
    --preview "cat {5}" \
    --preview-window=top:60% \
    --ansi \
    --bind 'alt-w:toggle-preview-wrap')

Where {5} is the filename, {6} is the full file content (newlines replaced with spaces), using ANSI codes to gray it out.

Something like #4257 would hopefully allow me to avoid this hack. But I found another similar issue in the past and know you're not too enthused about this. That's fine, the workaround works reasonably (if a bit slowly when I get to >100 items).

[junegunn]

though I worry this might add extra slowdown to preview invocations.

Are you concerned about the delay caused by counting the number of bytes? len(s) is a constant time operation and I'm pretty certain that it will not add any noticeable delay. Please build a binary from the source and let me know how it feels.

I can fuzzily search within a files contents

fzf might not be the right tool for search within file contents. Ripgrep or traditional grep tools are optimized for the use case and easily outperform fzf in that area. Also, for fzf to support interactive search, it has to hold everything in memory, which might not be feasible for a large number of files. A common approach is to use Ripgrep as the 1st pass filter, then use fzf as the secondary fuzzy filter.

In this rg.fzf implementation, you can type in RIPGREP_QUERY / FZF_QUERY to combine two filters.

[aktau]

A common approach is to use Ripgrep as the 1st pass filter, then use fzf as the secondary fuzzy filter.

Yes, I do know about this approach, and I'm certainly considering it given the wonkiness of the current thing. But what I'm doing now does feel smoother and easier to use:

1. No need to mode switch (back and forth). Like when I realize after looking at an item in fzf mode that I might want to include others too, I'd need to move back to rg mode, re-do my query and then go to fzf mode to make further fuzzy adjustments. It's mentally taxing.
2. My fuzzy matching brain works differently from regex brain. I'm sure I'd get it wrong quite a number of times. For example, when in fuzzy mode I don't need to think about the order of words ("30 for range" would work to find a for range 30 in fuzzy mode).

Anyway, thanks for the help and advice. And the stellar tool.