Installing zsh4humans without internet connection
codyhan94 opened this issue · comments
On a server without outside connection to the internet, but where I am able to copy source packages downloaded from a local machine, how would you manually install zsh4humans? Starting point would be with the following downloaded:
- all of the github archives for fzf, powerlevel10k, systemd, zsh-completions, ... found in -z4h-install-one
- zsh4humans v5
How are you connecting to the machine? Over SSH?
yes, over SSH on a windows machine, openssh 8.1.0.1
If the remote machine has the same OS kernel and CPU, you can run this command on your local machine to copy z4h over to the remote:
tar -C ~ -chz .{zshrc,zshenv,p10k.zsh}{,.zwc}(N) .terminfo .cache/zsh4humans |
command ssh HOSTNAME 'tar -C ~ -xz' &&
command ssh HOSTNAME 'Z4H_BOOTSTRAPPING=1 . ~/.zshenv'Replace HOSTNAME with the actual hostname/ip before running the command.
If you are using WSL on your local Windows host and Linux on the remote host, this should work.
I connect to the remote machine through windows without WSL, but I copied over the files from my setup and untarred/sourced zshenv as you suggested, and it works. There's a little funny business in tmux; when I exec zsh in tmux it tries to download tmux since my old config did not have a tmux setup, but that's OK, I have the tmux features in z4h turned off since I have tmux configured outside of z4h.
There's one slight startup speed issue that I can't track down (that seems less pronounced with my old setup which was also using p10k); every once in a while when I open a new terminal tab from windows terminal (which logs into the remote machine via ssh username@hostname), all of my config loads but the shell prompt takes a while to appear. I can type keystrokes that appear on the prompt when it shows up, but nothing until then. If I place zmodload/zprof at the start of my zshrc and zprof at the end, it prints out all of the zprof lines and hangs for a moment until the prompt shows up. If I place an echo "done with zshrc" after the zprof call, that also shows up before the prompt does. The sum of time spent in each function and its descendants never adds up to more than ~100ms, which is far shorter than the delay that I'm seeing occasionally.
This only happens if I don't open a new terminal/session for a while, and does not seem to happen in tmux.
As far as I can tell, I am using the instant prompt that comes configured with z4h.
What I've tried:
- Move as many things to local disk as possible in my config to reduce NFS latency (zsh binary, most of the paths in my fpath)
- Check the zcompdump file to make sure it's not getting regenerated over and over (it's not, zprof would show this too)
Some extra possibly related context:
- My "shell" as reported by chsh is
/bin/bashand I do not have permissions to change this - I use a
~/.profilefile suggested by https://unix.stackexchange.com/questions/136423/making-zsh-default-shell-without-root-access to start zsh on login. Its contents are
export SHELL=/path/to/local/zsh
exec /path/to/local/zsh -l
I'm closing the issue with this comment as the question has been answered satisfactorily, any extra help or suggestions you could make to help me track down this occasional (startup?) delay would be appreciated but it's not a big deal.
The slowdown you are describing sounds like instant prompt being disabled. This can happen if one interactive zsh has one value of TERM and the next has a different TERM. For example, if you run plain zsh when you ssh and then manually run tmux from it, you'll have no instant prompt. The workaround is to run tmux over ssh bypassing the intermediate shell. Alternatively, instruct z4h to start tmux for you.
Would it be possible to prevent instant prompt from being disabled by configuring tmux to not use a different value of TERM?
Of course it's possible but your use case is too rare to justify it.
Is there a way that I can conclusively determine that what you're talking about regarding instant prompt being disabled is happening?
You should be able to see a way to test this on your end. You've demonstrated more than enough intelligence for this task already.
Do you have z4h on the client machine from which you ssh to the remote?
set -g default-terminal "xterm-256color"
This is really not a good idea. tmux is incompatible with xterm-256color.
my (work) machine does not have WSL
Ouch. That's one way to render a windows machine nearly useless.
The best solution would be to install WSL and have a local terminal with screen-256color or tmux-256color and then ssh from that one. If you cannot have WSL, maybe you can find some other way to achieve this. Before WSL people used mingw and cygwin for this.
Another solution is to always run tmux when you connect over ssh. If you want some connections to be outside of the "main" tmux, you can run a different (standalone) tmux for them or within the same tmux but a different session.
From man tmux:
For tmux to work correctly, [default-terminal] must be set to ‘screen’, ‘tmux’ or a derivative of them.
You can see the incompatibility by comparing the output of infocmp screen and infocmp xterm.