FreeBSD: zrepl status => infocmp not found in $PATH error

[cobber]

When I run zrepl status I get the error exec: "infocmp": executable file not found in $PATH

Platform: FreeBSD 12.2
Installed via: pkg install zrepl (expectation: all dependencies are also installed)

After some searching, I finally discovered this comment on issue #204 (already closed) which only mentioned this error as a side-note.

The first solution offered was "install ncurses" followed by "this is an edge case, so I wouldn't add ncurses as a hard dependency of the package on FreeBSD"

huh? "you need ncurses, but ncurses should not be a dependency"?
isn't that a contradiction?

But installing curses is only treating the symptom, it doesn't help identify the problem!

This may be "an edge case", but by not specifying what the expected environment should or could be, it's a pretty bad user experience for anyone who happens to get caught on that edge. (i.e. anyone logging into a server via ssh with the TERM setting for their client terminal - which could be anything!)

The cause, however, appears to be that zrepl only has limited $TERM support.

However, this is not documented in the manpage or even https://zrepl.github.io, except for a very indirect hint in the Changelog section where it mentions "zrepl status now supports TERM=screen (tmux on FreeBSD / FreeNAS)".
What other TERM settings are supported? Which TERM settings are not supported? Why does it even fall back to infocmp at all?

If I hadn't noticed the echo $TERM lines in @problame's comment, I may never have found the cause.

Suggestion:

Provide an error such as: "$TERM=<...> not supported. Please use or install ncurses" if the user's $TERM is not set and zrepl status tries to start infocmp and also fails.

Of course, some information along those lines in the manpage and/or online documentation would also be very helpful.

Cheers and thanks

[problame]

I'm not sure I'm following. Did installing the ncurses package fix your problem on FreeBSD?
Which zrepl binary are you deploying? The freebsd ports one or the binary release from GitHub?

Provide an error such as: "$TERM=<...> not supported. Please use or install ncurses" if the user's $TERM is not set and zrepl status tries to start infocmp and also fails.

zrepl doesn't deal with TERM itself, it's all done through the tcell library. I linked to the relevant thread on their issue tracker in my original response.
So we'd have to check for this specific error from tcell and provide a better error message.

@cobber could you try out #297 ? It's the new status UI which is built using tcell.v2 - I haven't had time to go through their changelog yet - maybe things have improved on the tcell side?

[cobber]

Thanks for the quick reply!

I'm using the zrepl binary provided by FreeBSD's pkg system, currently zrepl-0.2.1.
i.e.: pkg install zrepl

Initially, my $TERM was set to linux, which triggered the error.
My first attempt was to install ncurses (the first solution I found)... and that worked.
But it annoyed me that this apparent dependency wasn't installed by pkg.

I then found your post, noticed that you were checking $TERM, removed ncurses (got the error again) and changed my $TERM setting to xterm-256color (as per your post) and it worked.
export TERM=xterm also worked.

As for tcell, that's an implementation detail which users should not know or care about.
You could replace tcell with something else tomorrow and with a bit of luck, no-one would notice :-)

I think that's also the cause, from tcell/terminfo/README.md

All terminal definitions are supplied by one of two methods:

• Compiled Go code
• For systems with terminfo and infocmp, dynamically generated at runtime.

Which implies, that since FreeBSD only has termcap by default, we get the third option... a misleading error.
The solution would be for tcell to add a termcap parser :-|

As for #297, I don't have a go environment setup - that's beyond me :-(
But, quickly scanning the tcell repo I can see that they now have a linux terminal definition built in, so perhaps that will partially improve things (an additional termcap parser would, of course, be the 100% solution, as they would then cover terminfo and termcap).

... but this is quickly turning into a rabbit hole...
I just wanted to replicate some ZFS snapshots... :-)

[problame]

cc @woodsb02 (the zrepl FreeBSD port maintainer): maybe we should just add ncurses as a dependency?

As for #297, I don't have a go environment setup - that's beyond me :-(

You can use the CI binaries, e.g. https://minio.cschwarz.com/minio/zrepl-ci-artifacts/07f2bfff6a9d9309cceb5bff08921c2958cb414b-pipeline-2111/quickcheck-go-amd64-freebsd-1.16/

Make sure to read 0.3 and 0.3.1 changelog at https://zrepl.github.io/changelog.html

[woodsb02]

Thanks for reporting this.

I just committed an update to the sysutils/zrepl port on FreeBSD to add ncurses as a runtime dependency.
https://svnweb.freebsd.org/changeset/ports/566917

Note that since a new version of zrepl 0.3.1 was committed to the latest ports branch in January, I didn't mark this commit as one to be merged back to quarterly, which has the version 0.2.1 you are using.

So this issue should be fixed for you by the first ports run in April, with the workaround being to manually install ncurses until then.

Does that work for you @cobber?

[problame]

Closing due to inactivity, I assume @woodsb02 's fix will be sufficient.