grc not sourced using ohmyzsh or z4h source/load
Closed this issue · 16 comments
Operating System:
MacOS 12.3 (Monterey)
Terminal Environment(s):
Terminal.app and Alacritty
ZSH version:
zsh --version
zsh 5.8 (x86_64-apple-darwin21.0)
Issue:
Sourcing grc.zsh installed by Homebrew with any of these methods in .zshrc fails:
z4h source -- ${HOMEBREW_PREFIX:+$HOMEBREW_PREFIX/etc/grc.zsh}z4h load ohmyzsh/ohmyzsh/plugins/grc[[ -s "${HOMEBREW_PREFIX}/etc/grc.zsh" ]] && source ${HOMEBREW_PREFIX}/etc/grc.zsh
If I clean the ~/.cache/zsh4humans directory, I find sometimes output for recognized commands is colorized. Both Terminal.app and Alacritty are set to report TERM=xterm-256color
Expected Behaviour:
Output from ls, ping and other commands should return colorized output.
zsh4humans has very limited support. Unfortunately, this issue isn't something I have the time to look into.
That's a shame. I really wanted to persist with zsh4humans because of how fast it was and it's nice feature touches. Do you have any recommendations for alternatives if this project is going to fall by the wayside?
Do you have any recommendations for alternatives if this project is going to fall by the wayside?
Not really. I'm using zsh4humans myself.
The reason I'm not helping you with this issue is because it's not reproducible and it's quite likely that the problem is on your side. You might be able to fix it yourself.
Just an update to confirm this is also an issue on Ubuntu Linux (22.04) within a Docker container/VSCode. I've also tried source /etc/grc.zsh directly in my zshrc with no luck with that method either.
A check with type ping shows the original path to the binary and not a zsh function or bash alias.
I can confirm that running grc ping google.com or other tools does colorize the output. Likewise, if I source /etc/grc.zsh after the shell has loaded, it also works fine.
The above is out of courtesy in case you do have time to look into this further and want more info on where I've beem able to reproduce this.
As I mentioned earlier, this is not reproducible for me. This is what I tried:
docker run -e TERM -e COLORTERM -w /root -it --rm ubuntu sh -uec '
cd
apt-get update
apt-get install -y zsh curl grc
curl -fsSLO https://raw.githubusercontent.com/romkatv/zsh4humans/v5/.zshenv
curl -fsSLO https://raw.githubusercontent.com/romkatv/zsh4humans/v5/.zshrc
echo "z4h source /etc/grc.zsh" >>~/.zshrc
exec zsh'OK. Here's what I found...
When I first run the container as per previous comment, ls -al provides colorized output. If I subsequently install ping with apt-get install -y iputils-ping and then try a ping of google.com, the output isn't colorized.
Next I try exec zsh as perhaps the command lookup of ping via /etc/grc.zsh needs to re-discover this utility. No luck, the output is still without ANSI colors.
Next, I notice when I echo $TERM it reports tmux-256color even though tmux isn't installed or running a session. If I manually change that to xterm-256color (yes, bad form I know), IT WORKS right after I exec zsh again!
So, why is TERM set as tmux-256color ? None of my terminal emulators are configured to send that. Which leads me to think this is being set somehow by zsh4humans along with another bunch of tmux vars. eg
COLORTERM=truecolor
GPG_TTY=/dev/pts/1
HOME=/root
HOSTNAME=6492777824ef
INFOPATH=
LC_ALL=C.utf8
LESS=-iRFXMx4
LOGNAME=root
LSCOLORS=ExGxDxDxCxDxDxFxFxexEx
LS_COLORS=fi=00:mi=00:mh=00:ln=01;36:or=01;31:di=01;34:ow=04;01;34:st=34:tw=04;34:pi=01;33:so=01;33:do=01;33:bd=01;33:cd=01;33:su=01;35:sg=01;35:ca=01;35:ex=01;32:no=38;5;248
MANPATH=/root/.cache/zsh4humans/v5/fzf/man:
OLDPWD=/root
P9K_SSH=0
P9K_TTY=old
PATH=/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/.cache/zsh4humans/v5/fzf/bin
PWD=/root
SHELL=/usr/bin/zsh
SHLVL=1
TERM=tmux-256color
TERMINFO=/root/.terminfo
TERM_PROGRAM=tmux
TERM_PROGRAM_VERSION=next-3.4
TREE_COLORS=fi=00:mi=00:mh=00:ln=01;36:or=01;31:di=01;34:ow=01;34:st=34:tw=34:pi=01;33:so=01;33:do=01;33:bd=01;33:cd=01;33:su=01;35:sg=01;35:ca=01;35:ex=01;32
_=/usr/bin/grc
_P9K_TTY=/dev/pts/1
_Z4H_TMUX=/tmp/z4h-tmux-0-xterm-256color-1652188921-tc,3515,0
_Z4H_TMUX_CMD=/root/.cache/zsh4humans/v5/tmux/bin/tmux
_Z4H_TMUX_PANE=%0
_Z4H_TMUX_TTY=/dev/pts/1
Adding to the above. I wasn't prompted on whether I wanted to run sessions inside Tmux during the install wizard, and yet zsh4humans is putting a copy into /root/.cache/zsh4humans/v5/tmux/bin/tmux and a session is launched which can be seen as $TERM_PROGRAM
I think the default Tmux config should be using the term override option eg
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB"
for GRC to work
When I first run the container as per previous comment,
ls -alprovides colorized output.
Good.
If I subsequently install ping with
apt-get install -y iputils-pingand then try a ping of google.com, the output isn't colorized.
This is the expected behavior. If you look at /etc/grc.zsh, you'll see that it creates aliases only for commands that exist. ping didn't exist when /etc/grc.zsh was sourced, hence no alias for ping.
Next I try
exec zshas perhaps the command lookup of ping via /etc/grc.zsh needs to re-discover this utility. No luck, the output is still without ANSI colors.
Cannot reproduce this.
I'm going to close this issue as it's taking more of my time than I can afford.
Thanks @romkatv, I understand this has taken some of your time to diagnose. I'm almost confident now that I've narrowed this down to a GRC version specific quirk/issue.
I'm able to get colorized output from grc 1.11.3 (ships with Ubuntu 20.04) both within and outside of Tmux. Whereas, on Ubuntu 22.04 which currently ships grc 1.13, I get colorized output within Tmux, but not outside.
Both environments had their tmux config set with the previously mentioned overrides.
set -g default-terminal "tmux-256color" set -ag terminal-overrides ",xterm-256color:RGB"
Leaving this here for posterity in case someone runs into the same and solves it.
Cannot reproduce.
docker run -e TERM=xterm -w /root -it --rm ubuntu:22.04 sh -uec '
apt-get update
apt-get install -y zsh curl grc
curl -fsSLO https://raw.githubusercontent.com/romkatv/zsh4humans/v5/.zshenv
echo "zstyle :z4h: start-tmux no" >~/.zshrc
echo "z4h init || return" >>~/.zshrc
echo "z4h source /etc/grc.zsh" >>~/.zshrc
exec zsh'When prompt appears, ls -la is colorized by grc as expected.
Neither can I now on a fresh virtual machine. Can't isolate any further myself so consider this dead. Thanks for your help again.
I have run into this issue of grc not working when sourced from .zshrc of zsh4humans. This is an issue with a change in grc.zsh and has nothing to do with zsh4humans. If the first and last line of the /etc/grc.zsh is reverted to the earlier 1.11.3 version of crc then all works fine.
if [[ "$TERM" != dumb ]] && (( $+commands[grc] )) ; then
and
# Clean up variables unset cmds cmd fi
I ended up solving this with:
source /etc/grc.zsh
in my .zprofile file which meant I didn't need to undo the grc package maintainers updates. Maybe @garabik will get to the bottom of this.
I ended up solving this with:
source /etc/grc.zshin my
.zprofilefile which meant I didn't need to undo the grc package maintainers updates. Maybe @garabik will get to the bottom of this.
That works perfectly, thanks. I created and added it to .zprofile
This is the culprit: https://github.com/garabik/grc/blob/f4a579e08d356a3ea00a8c6fda7de84fff5f676a/grc.zsh#L3-L6
grc refuses to load if stdin is not a TTY. Why it cares, I cannot tell. IMO it should load if the user explicitly sources the file. In your .zshrc after you invoke z4h init and until initialization finishes, stdin is not a TTY. This is indicated by comments in the file (above z4h init). You can also read more here and here.
As a workaround you can do this:
z4h source /etc/grc.zsh <$TTYThis is better than modifying .zprofile because the latter won't work in non-login shells.