syncing .zsh* files

syncing .zsh* files

[Timothy Luoma]

I'm interested in keeping my .zsh(rc|env) files synced across 3 
different machines.

Anyone have any good techniques for doing so, especially when there are 
some things ($PATH) which are different on each machine?

Should I have separate .zshenv files and the same .zshrc file perhaps?

Do .zshrc and .zshenv both get used when logging in (ssh)?

Thanks!

TjL

Re: syncing .zsh* files

[Björn Lindström]

Timothy Luoma <lists@tntluoma.com> writes:

> I'm interested in keeping my .zsh(rc|env) files synced across 3
> different machines.
>
> Anyone have any good techniques for doing so, especially when there
> are some things ($PATH) which are different on each machine?
>
> Should I have separate .zshenv files and the same .zshrc file perhaps?
>
> Do .zshrc and .zshenv both get used when logging in (ssh)?

I distribute patches for my dot-files across machines using darcs
(http://abridgegame.org/darcs/).

To simplify keeping track of the patches, I source .zshrc.local from
.zshrc, and put purely local stuff, there. OS-dependent stuff I let
.zshrc figure out with a few if:s.

Re: syncing .zsh* files

[Matt Pharr]

Timothy Luoma <lists@tntluoma.com> writes:

> I'm interested in keeping my .zsh(rc|env) files synced across 3 different
> machines.
>
> Anyone have any good techniques for doing so, especially when there are
> some things ($PATH) which are different on each machine?

FWIW I've found it works well to split things into core settings, the same
across all architectures, and then separate files that hold the
modifications to the baseline settings.

My .zshenv file, then, has something like:

export MARCH=`/bin/uname | /usr/bin/tr A-Z a-z | /bin/sed 's/64//g'`

if [[ -a ~/.zshenv.$MARCH ]] then
    source ~/.zshenv.$MARCH
fi

And then I have a .zshenv.linux, .zshenv.osx, .zshenv.irix, etc.
(Similarly for .zshenv, etc.)

-matt
-- 
Matt Pharr    matt@pharr.org    <URL:http://graphics.stanford.edu/~mmp>
=======================================================================
In a cruel and evil world, being cynical can allow you to get some
entertainment out of it. --Daniel Waters

Re: syncing .zsh* files

[Vincent Lefevre]

On 2004-08-06 12:17:23 -0400, Timothy Luoma wrote:
> I'm interested in keeping my .zsh(rc|env) files synced across 3 
> different machines.
> 
> Anyone have any good techniques for doing so, especially when there are 
> some things ($PATH) which are different on each machine?

I manage all my config files with Subversion and I have a script that
reinstall them (with a possible preprocessing) when I want to. For
zsh, I have a .zdomain file on each account, that sets up a $domain
variable, which I can test when need be.

> Should I have separate .zshenv files and the same .zshrc file perhaps?

In general, both files will have settings common to each account and
settings that may differ, even in the .zshrc file; for instance, in my
case, the precmd function contains something that depends on $domain:

  if [[ $domain == local.ay && "$(pmu_battery)" == "Battery" ]] then
    psvar[1]="[$(pmu_percent)%]"
  else
    psvar[1]=""
  fi

Also, some aliases are defined for some accounts only.

> Do .zshrc and .zshenv both get used when logging in (ssh)?

.zshenv, .zshrc and .zlogin (and possibly other files, RTFM...)
for a login shell (default case with ssh).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: syncing .zsh* files

[Michael Prokop]

* Timothy Luoma <lists@tntluoma.com> [20040806 19:18]:

> I'm interested in keeping my .zsh(rc|env) files synced across 3 
> different machines.

> Anyone have any good techniques for doing so, especially when there are 
> some things ($PATH) which are different on each machine?

I'm using subversion as a revision control system for all my main
config files - including zsh-setup.

Via .zlogin I'm checking for a timestamp (update only if timestamp
is older than one day) and run 'svn update'.

I'm doing the OS and machine stuff via:

,---- [ extract from my ~/.zshrc ]
| OS=${OSTYPE%%[0-9.]*}
|   case $OS in
|       linux-gnu)
|          source $ZSHDIR/zsh_linux
|       solaris)
|       freebsd)
|       nto-qnx)
|       [...]
`----

The same works of course for hostname (for machine-specific stuff).

You can find my (zsh) config online:
  http://www.michael-prokop.at/computer/config/
Feedback and suggestions are welcome ;-)

HTH && regards,
(-: Michael
-- 
www.michael-prokop.at
~
~
".signature" [New] 1L, 22C [w]

Re: syncing .zsh* files

[Bart Schaefer]

I have all my zsh configurations stored in CVS on a host I can access with 
CVS_RSH=ssh.  They're designed to be checked out into a directory ~/.zsh 
on each host, and then I have a little installer script that sets up a 
~/.zshenv file which does nothing more than assign ZDOTDIR=~/.zsh and then 
source the ~/.zsh/.zshenv file.  (If ZDOTDIR is already set, the ~/.zshenv
is never seen, so there's no reason to e.g. guard this with an "if".)

There can be a subdirectory named "local" in the .zsh directory from which 
host-specific files, if they exist, are sourced by the ~/.zsh/.zshrc 
(etc.) files.  I keep a set of subdirectories named for the host or domain 
(e.g. all hosts at work use the same one); those are checked into CVS and 
then I symlink the name "local" to the correct one for each install.

At first I tried organizing everything by host architecture or OS, but I 
ended up dividing it by, for lack of a better term, purpose -- things 
needed in all shells, in interactive shells, just once when starting a new 
session (e.g., before X11 startup), etc., and then sometimes subdividing 
into options, bindings, completion, terminal handling, etc. There's one 
file that sets up aliases or functions to mask differences in default 
behavior of ps, ls, df, etc. on different architectures, but most of the 
case-statements on $HOSTTYPE are scattered in various files because I 
could never find a common place in the startup sequence to do all of that 
at once.