Best way to teleport different files than local files?

[VorpalBlade]

I want to teleport a few extra files across, such as .gitconfig. Unfortunately I can't teleport the exact .gitconfig across that I use on my dev machines, as that one has commit signing with gpg enabled. For security reasons I'm not teleporting the gpg keys across, nor am I forwarding the gpg-agent (yes I know that is possible). Thus I'd like a way to teleport a different file across and use as the remote .gitconfig.

My .gitconfig is also currently templated with chezmoi to detect if git-lfs is installed and only enable to required filter section if that is the case. This is also something that needs to be handled somehow when ssh teleporting.

One way to do this is to detect the situation in .zshrc and patch the teleported .gitconfig, since it is a one line change for the signing (and a question of removing a few lines if git-lfs is missing). But I was wondering if there was a better, more structured option, that might also work when the changes are more major. I'm not sure what the best way to solve this is.

[romkatv]

You can create .gitconfig-remote on your local machine with the content of .gitconfig for remote machines. Then do this:

function z4h-ssh-configure() {
  z4h_ssh_send_files[$HOME/.gitconfig-remote]='~/.gitconfig'
}

z4h-ssh-configure allows you to do things that you cannot achieve with simple zstyle definitions. It's invoked after the instructions from zstyle are applied. Within that functions you have readonly access to the following parameters:

• z4h_ssh_client -- local hostname
• z4h_ssh_host -- remote hostname

You also have read/write access to these:

• z4h_ssh_enable -- 1 to teleport, 0 to do plain ssh
• z4h_ssh_send_files -- list of files to send to the remote; keys are local file names, values are remote file names
• z4h_ssh_retrieve_files -- the same as z4h_ssh_send_files but for pulling files from remote to local; the primary use case is for pulling command history
• z4h_ssh_command -- command to use as ssh
• z4h_ssh_run, z4h_ssh_prelude, z4h_ssh_setup, z4h_ssh_teardown -- these are low level blocks that run on the remote

In the example above we are adding one more file to z4h_ssh_send_files. We cannot use a zstyle for this because the file name is different on local and remote.

[romkatv]

You might be the first person to use this API apart from myself. I'd appreciate feedback.

[VorpalBlade]

Awesome, I'll look into this.

[romkatv]

When using ssh teleportation, you get Z4H_SSH environment variable on the remote machine. The important parts of it are the hostname of the client and the name of the remote as it was passed to ssh. E.g., when I run ssh bar on foo, I get Z4H_SSH=500000021:foo:bar. The last part is probably most useful. You can use it instead of HOSTNAME because it's likely more descriptive. For example, here's how you can display this in terminal title:

zstyle ':z4h:term-title:ssh' precmd   ${${${Z4H_SSH##*:}//\%/%%}:-%m}': %~'
zstyle ':z4h:term-title:ssh' preexec  ${${${Z4H_SSH##*:}//\%/%%}:-%m}': ${1//\%/%%}'

This is the same as the default but it uses the last component of Z4H_SSH instead of HOSTNAME if Z4H_SSH is set.

And here's how you can configure context in ~/.p10k.zsh to do the same thing:

() {
  POWERLEVEL9K_CONTEXT_ROOT_FOREGROUND=178
  POWERLEVEL9K_CONTEXT_FOREGROUND=180
  POWERLEVEL9K_CONTEXT_ROOT_TEMPLATE=%B%n@$1
  POWERLEVEL9K_CONTEXT_TEMPLATE=%n@$1
  typeset -g POWERLEVEL9K_CONTEXT_{REMOTE,REMOTE_SUDO}_FOREGROUND=81
  typeset -g POWERLEVEL9K_CONTEXT_{DEFAULT,SUDO}_{CONTENT,VISUAL_IDENTIFIER}_EXPANSION=
  typeset -g POWERLEVEL9K_CONTEXT_{REMOTE,REMOTE_SUDO}_TEMPLATE=$1
} ${${${Z4H_SSH##*:}//\%/%%}:-%m}

This is for Lean style. If you aren't using Lean, I highly recommend running p10k configure and switching to Lean. Also see https://github.com/romkatv/powerlevel10k#what-is-the-best-prompt-style-in-the-configuration-wizard. A very good combo: Lean + two lines + sparse + transient + few icons + no frame.

[VorpalBlade]

I will keep this in mind. Having access to the alias from ssh might indeed be quite useful, as that might not be the same as the host name. It will likely be a few days before I have time to really tweak this.

[romkatv]

Having access to the alias from ssh might indeed be quite useful, as that might not be the same as the host name.

That's exactly it. I also sometimes have several different aliases in ~/.ssh/config for the same machine and I get different command history and other stuff depending on whether I connect to the machine via ssh webserver or ssh pihole.

[romkatv]

Answered all questions => closing.