Open stephenjamieson opened 5 years ago
I think I've seen something similar before. Since you posted the locale
output, you probably saw my troubleshooting text that mentioned gyscos/Cursive#13. Are you running moonfire-nvr config
through sudo
? It might be removing important environmental variables (because security). So if you're running it like this:
$ sudo -u moonfire-nvr moonfire-nvr config
then try checking out the locale like this:
$ sudo -u moonfire-nvr locale
$ sudo -u moonfire-nvr sh -c 'echo $TERM'
It looks like sudo has a --preserve-env
option; you could try that:
$ sudo -u moonfire-nvr --preserve-env moonfire-nvr config
If that's not it...the ncurses ui is based on cursive. Could you see if you can reproduce with cursive's examples as of the version in moonfire-nvr's Cargo.lock
?
$ git clone https://github.com/gyscos/Cursive
$ cd Cursive
$ git checkout 0.10.0
$ cargo run --example dialog
then, assuming so, see if the problem is still present at the latest version of Cursive?
$ git checkout master
$ cargo run --example dialog
If so, could you file an issue against Cursive and link it from here? I bet they'll want to know (in addition to what Cursive version you're using and that locale
output) what platform you're using, what $TERM
is, and what terminal emulator you're using.
Thank you for the response Scott,
I tried all of the above and used the cursive example. The cursive example works fine. I'm not sure what's going on. Enabled login for the moonfire-nvr user to avoid any sudo issues, unfortunately same issue.
That's puzzling. My code doesn't use cursive in any special way so I don't know why it'd behave differently than the cursive examples.
What platform is moonfire-nvr running on? What's $TERM
? What terminal emulator? (different platform?) Are you using tmux or screen?
A couple more questions about the sudo thing because I swear I'd seen that before. Logging in as moonfire-nvr is a good experiment, but I wonder if you have a different .bash_profile
with your normal user or something.
Could you try running moonfire-nvr config as your normal user? You can use a throwaway database for it; it doesn't really matter.
mkdir throwaway
moonfire-nvr init --db-dir=throwaway
moonfire-nvr config --db-dir=throwaway
and/or could you try running the cursive example as the moonfire-nvr user?
Without more information, I can't do anything to help you.
I've run into the same problem using PuTTY to a Virtual Machine where I am installing Moonfire NVR.
My command (as root): `ares /usr/local/src/moonfire/moonfire-nvr/target/release # sudo -u moonfire-nvr ./moonfire-nvr config 2>debug-log
ares /usr/local/src/moonfire/moonfire-nvr/target/release # echo $TERM xterm ares /usr/local/src/moonfire/moonfire-nvr/target/release # ` I have this version of ncurses installed:
[I] sys-libs/ncurses
Available versions: 6.1_p20181020(0/6)^t 6.1_p20190609(0/6)^t 6.2-r1(0/6)^t {ada +cxx debug doc gpm minimalofile split-usr static-libs test threads tinfo trace unicode ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S3"32 64" ABI_X86="32 64 x32"}
Installed versions: 6.2-r1(0/6)^t(00:19:29 05/16/20)(cxx gpm split-usr tinfo unicode -ada -debug -doc -mini -profile -static-libs -test -threads -trace ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64BI_X86="64 -32 -x32")
Homepage: https://www.gnu.org/software/ncurses/ https://invisible-island.net/ncurses/
Description: console display library
When I tried using the nucurses on my Gentoo laptop, there was no problem. I am supposing this is a configuration of PuTTY and/or an X Windows issue. I'll get it resolved, but I thought I would chime in here for posterity.
sudo from my initial login account, jlpoole, doesn't finesse the problem, either. I get the same result as depicted in the screenshot in my prior post in this topic.
jlpoole@ares /usr/local/src/moonfire/moonfire-nvr/target/release $ sudo -u moonfire-nvr ./moonfire-nvr config 2>debug-log jlpoole@ares /usr/local/src/moonfire/moonfire-nvr/target/release $
My previous attempts to run the ncurses configuration was using PuTTY from Windows. I just tried running from a Gentoo laptop on an ssh connection and the display was fine. Therefore, the client accessing the session is this distinguishing factor. The TERM variable is different from my Gentoo laptop vs. my Windows PuTTY session which was "term" only. I'll try changing the session from Windows to "xterm-256color" and see if that makes a difference.
echo $TERM
xterm-256color
Here is how the ncurses screen should look (from Gentoo laptop), there are box and line characters:
Thanks for the report. Does this happen with cursive's examples? The current version I'm using is 0.14.0, so you'd check via:
$ git clone https://github.com/gyscos/Cursive
$ cd Cursive
$ git checkout v0.14.0
$ cargo run --example dialog
I'd be very happy to add more info to the troubleshooting doc if we can get this figured out.
I spent several hours down this rabbit hole. The problem I am encountering is due to Windows Putty and UTF-8. It's a mapping issue and involves several items. One proferred solution was to try using screen or tmux; I tried screen, but no luck. I ended up downloading the suite of ncurses tests and trying various configurations and realized time was slipping by so I abandoned trying to get it to work out. As I indicated, coming from a shell on a Gentoo laptop was no problem, so I just moved to my Gentoo laptop to do the configuration stuff.
The take-away is that using ncurses, may present problems for users coming from a Windows machine with PuTTY.
The take-away is that using ncurses, may present problems for users coming from a Windows machine with PuTTY.
Hmm, that's too bad. Long-term I would like all the configuration to be through a web UI (except bootstrapping authentication from the CLI) but that might be a ways off.
I am able to create the disparity (garbled through Windows PuTTY, fine through an ssh from another Linux box) using the example code featured in Starting With Cursive, step 2/3 at https://github.com/gyscos/cursive/blob/master/doc/tutorial_2.md
I'll review the issues there and log a ticket if what I have encountered is not already documented.
The code is: `
use cursive::Cursive;
use cursive::views::Dialog;
fn main() {
let mut siv = cursive::default();
siv.add_layer(Dialog::text("This is a survey!\nPress <Next> when you're ready.")
.title("Important survey")
.button("Next", show_next));
siv.run();
}
fn show_next(s: &mut Cursive) {
s.pop_layer();
s.add_layer(Dialog::text("Did you do the thing?")
.title("Question 1")
.button("Yes!", |s| show_answer(s, "I knew it! Well done!"))
.button("No!", |s| show_answer(s, "I knew you couldn't be trusted!"))
.button("Uh?", |s| s.add_layer(Dialog::info("Try again!"))));
}
fn show_answer(s: &mut Cursive, msg: &str) {
s.pop_layer();
s.add_layer(Dialog::text(msg)
.title("Results")
.button("Finish", |s| s.quit()));
}`
Problem solved -- for the most part. Turns out my VM did not have the locale specified. See https://github.com/gyscos/cursive/issues/13#issuecomment-636272227
Same fix as jlpoolen. Needed to set the locale/LANG.
@mcd1992, Are you using the new prebuilt Docker container? It has ENV LC_ALL=C.UTF-8
, which I thought would take care of that for you.
Ah no. This issue was on me; manually doing it in my proxmox lxc container with cargo. It was just a weird thing to debug since I was blaming my ncurses libs or the TERM envar. Didn't think to look at the locale.
Thanks though!