Open mlyle opened 6 years ago
I can confirm the issue. :)
Hmm... It definately should not trigger with ssh. That is not intended behavior. Seems to me that this theming is quite complicated to get right as a general solution. I'm considering disabling it by default.
Could you give me the output of this line when you are ssh'd to your manjaro?
basename "$(cat "/proc/$PPID/comm")
This is what is used to determine if the theming should be applied.
@Chrysostomus is there a problem with the package in repositories? I'm brand new to manjaro, but the version installed on my system in /etc/skel matches b07f66d801e3e7798d4dad1e3970fe3072caaa58, even after sudo pacman -Syu
... am I being an idiot somehow?
https://mirror.clarkson.edu/manjaro/stable/community/x86_64/manjaro-zsh-config-0.6-1-any.pkg.tar.xz appears to have the wrong / old code.
It's probably outdated
How do packages get updated?
How do packages get updated?
it is @Chrysostomus' package. he can update it. the PKGBUILD is located here: https://github.com/manjaro/packages-community/tree/master/manjaro-zsh-config
It gets updated when I build the package and upload it to repos with boxit. It goes straight to unstable and gets snapped to stable within two weeks or so.
It is going to take some time before I get around to do it, because I'm in the middle of moving to a new apartment.
Theoretically it could happen faster if someone else has time to build it sooner. @jonathonf , would you like to rebuild and upload the package?
I can do - I don't understand the repo layout though.
https://github.com/manjaro/packages-community/tree/master/manjaro-zsh-config has no files and only references https://github.com/Chrysostomus/manjaro-zsh-config as its source.
What's the correct, current, package source and version?
I'm not sure. I uploaded the new version now to unstable as 0.7. I always get confused with these pkgbuilds that point to specific git commit. I probably already updated the package earlier, but forgot to update the git commit line, so it bumped the version without actually changing the files... Well that's embarrassing...
But anyway, can someone tell me what is the output of
basename "$(cat "/proc/$PPID/comm")
when ssh'd to manjaro? I'm thinking of adding an exception for ssh, but I need a pattern for that. If it creates too many patterns, I might have to reverse the logic and instead list the terminals where the colors can be used.
~ >>> basename "$(cat "/proc/$PPID/comm")"
sshd
~ >>> ps -p$PPID
PID TTY TIME CMD
1096 ? 00:00:00 sshd
Thanks, that seems promising.
I still think this is evil. If you're going to do it, better to whitelist.. or just not to do it at all, and leave it commented in the file where a user can easily enable it if they're a moron who likes this kind of thing.
Yeah... That might make sense. Really the only terminal that really needs it is st, for others it is up to the user preference.
I mean, I'm not judging. People on the short bus need interactive terminal sessions, too.
I don't know what that means. But I think the first priority should be to have a working general solution. For me the second priority is to have something that works with st-manjaro. It doesn't have option to configure colors without recompiling it, so setting colors from a script makes a lot sense. Personally I like it in general, but it just doesn't work with all setups.
If this is for one terminal that's not a default of the official editions it probably doesn't need to be enabled by default.
Using a base16 theme by default causes really non-intuitive behavior-- I installed manjaro as a CLI / headless distribution, then ssh'd to it. The background color for my terminal and terminal colors were "permanently" changed on my host machine. Then I had to figure out that this was in turn the skel .zshrc and not /etc/zsh/zprofile, /etc/bash.bashrc, or some default terminfo thing... in the end, I threw up my hands and resorted to trolling on IRC.