dpayne / cli-visualizer

CLI based audio visualizer
MIT License
2.12k stars 122 forks source link

no display from $ sudo vis? #204

Open treatmesubj opened 2 years ago

treatmesubj commented 2 years ago

I noticed $ sudo vis is just a blank screen. Whereas $ vis run from my user works just as expected. I haven't been able to figure out why. I have a more complex problem that I hope will be solved if I can figure out how to just get $ sudo vis to work properly.

Here's my more complicated situation. I've got a Raspberry Pi with a LCD display hat on it and Raspberry Pi Lite OS (terminal only) installed. It has no keyboard and mouse, so I ssh into it. I'd like to see cli-visualizer on this Raspberry Pi display. So, on boot up, I've got /etc/rc.local start a tmux session for my user john, and then /home/john/.bashrc checks if it's /dev/tty1 and if it is, it attaches to the tmux session started by /etc/rc.local. This is cool because from my ssh session, I can attach to the tmux session too and make cool terminal stuff happen on the Raspberry Pi display. Unfortunately, vis doesn't work properly in the tmux session created by all this despite having a proper configuration inherited by /home/john/.tmux.config - it's got a proper $TERM and should I believe, not have any color problems from this setup. If I exit the tmux session and logged in as john, start a new tmux session, attach to it, and run vis, it all works fine, but of course won't be seen on the Raspberry Pi's display because it's no longer attached to the same tmux session. I suspect that even though /etc/rc.local runs sudo -u john tmux new-session -d -s tmuxsesh -c ~ to spawn the tmux session under my user john, something with it being run by root isn't allowing vis to work nicely. Then, I noticed that sudo vis doesn't work properly for me either. So that further raises my suspicions that I've got a problem with root and vis.

Any suggestions?

treatmesubj commented 2 years ago

used ~/.bashrc to check for /dev/tty1 to spawn and attach to the tmux session rather than /etc/rc.local as a workaround