On Feb 13, 2008 7:57 AM, Elijah Newren <newren@xxxxxxxxx> wrote: > On Feb 12, 2008 3:30 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > A quick work-around for Elijah is to add > > > > > > GIT_EXEC_PATH=/home/enewren/software/install/linux/git/bin > > > > > > to .profile on the remote host. > > > > I guess you meant .bashrc, as .profile is not sourced when using ssh > > transport (it does not spawn a shell) AFAIR. > > As far as I can tell, setting paths in .bashrc doesn't really work (or > else I'm just doing it wrong). If it did, I would have never hit this > bug. Observe the difference between (feel free to replace PATH with > GIT_EXEC_PATH; same general result occurs): > > $ ssh localhost > # Wait for connection to be made, then run > $ echo $PATH > > AND > > $ ssh localhost 'echo $PATH' > > AND > > $ ssh localhost 'source .bashrc > echo $PATH' > > The first and the third give the same result, but the second gives > something different. It is the second form that git uses, meaning > that my paths never get set up. I had this problem as well, and the only solution I found was setting up my .ssh/environment file. I guess when you specify a command for ssh, it executes this command by itself, not within a shell environment. Usually it is bash that sources .bashrc and .profile, so you don't get your paths set up. Unfortunately .ssh/environment is not a scripting environment, so you have to just specify your full path there, based on what you get when you echo $PATH from the shell. Also, this requires putting the following in sshd_config: PermitUserEnvironment yes Which, and this is the biter, is not usually a default on most systems, as far as I can see.. so it could mean bugging the sysadmin if it's not your machine, which is not always convenient. Can't see any alternative though. Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
