Even though path is correct, I get an error "bash: git-receive-pack: command not found."

1,057 views
Skip to first unread message

mbs400

unread,
Jun 25, 2012, 11:45:51 PM6/25/12
to trac-...@googlegroups.com
When I try to do a $ git push origin master, I get an error "bash: git-receive-pack: command not found."

When I do a $ which git on the remote server, it gives me the same path /usr/local/git/bin/git, asn shown in echo $PATH.

$ cd '/data/git/sandbox/tmp/'

$ pwd
  ---> /data/git/sandbox/tmp

$ git status
  ---> # On branch master
  ---> nothing to commit (working directory clean)

############################
### (next command) ERROR ###
############################

$ git push origin master
  ---> Password:
  ---> bash: git-receive-pack: command not found
  ---> fatal: The remote end hung up unexpectedly

### (next command) works fine if I force the path at the time I push. So git seems
### git-receive-pack if I force the same path shown when I echo the $PATH below.

$ git push origin master --receive-pack=/usr/local/git/bin/git-receive-pack
  ---> Password:
  ---> Everything up-to-date

  ---> Password:
  ---> Last login: Mon Jun 25 21:37:36 2012 from 192.168.1.97

### (next command) Correct path for git on server

server:~ roscoe$ which git
  ---> /usr/local/git/bin/git

### (next command) correct git path is shown in $PATH

server:~ roscoe$ echo $PATH
  ---> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin

### (next command) interesting that git-receive-pack is a symlink to -> git

server:~ roscoe$ ls -la /usr/local/git/bin
  ---> total 15736
  ---> drwxr-xr-x  9 root  wheel      306 Jun 20 19:22 .
  ---> drwxr-xr-x  8 root  wheel      272 Jun 20 19:22 ..
  ---> -rwxr-xr-x  1 root  wheel  4053064 Jun 19 12:23 git
  ---> -rwxr-xr-x  2 root  wheel   120933 Jun 19 12:23 git-cvsserver
  ---> lrwxr-xr-x  1 root  wheel        3 Jun 20 19:22 git-receive-pack -> git
  ---> -rwxr-xr-x  2 root  wheel  1738816 Jun 19 12:23 git-shell
  ---> lrwxr-xr-x  1 root  wheel        3 Jun 20 19:22 git-upload-archive -> git
  ---> -rwxr-xr-x  2 root  wheel  1797408 Jun 19 12:23 git-upload-pack
  ---> -rwxr-xr-x  1 root  wheel   329597 Jun 19 12:23 gitk

server:~ roscoe$ 

I tried adding the path in ~/.bashrc, ~/.bash_profile, /etc/bashrc, and then in /etc/rc.common, and I didn't think it would make any difference, and sure enough it did not change anything.

I dont mind using :

$ git push origin master --receive-pack=/usr/local/git/bin/git-receive-pack

but it would be a lot nicer if I could just use:

$ git push origin master

Grateful for any ideas...

Bill Hernandez
Plano, Texas

mbs400

unread,
Jun 25, 2012, 11:51:56 PM6/25/12
to trac-...@googlegroups.com
This :
 
### (next command) works fine if I force the path at the time I push. So git seems
### git-receive-pack if I force the same path shown when I echo the $PATH below.

Should have been:

Matthew Caron

unread,
Jun 26, 2012, 8:28:56 AM6/26/12
to trac-...@googlegroups.com

On 06/25/2012 11:45 PM, mbs400 wrote:
> When I try to do a $ git push origin master, I get an error "bash:
> git-receive-pack: command not found."
>
> When I do a $ which git on the remote server, it gives me the same path
> /usr/local/git/bin/git, asn shown in echo $PATH.

/usr/local/git/bin/git is a nonstandard path, and is something you added
to the path yourself, yes? Is is possible that the configuration file
you used only applies to login shells, and not for a noninteractive shell?

As a general case, rather than continually adding to the path and
growing it ever longer, I tend to symlink things in to the correct
spots. So:

cd /usr/local/bin && ln -s /usr/local/git/bin/* .

It also has a nice secondary effect of avoiding problems like this.
--
Matthew Caron, Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office


Bill Hernandez

unread,
Jun 26, 2012, 9:51:13 AM6/26/12
to trac-...@googlegroups.com
Matthew,

On Jun 26, 2012, at 7:28 AM, Matthew Caron wrote:

/usr/local/git/bin/git is a nonstandard path, and is something you added to the path yourself, yes? Is is possible that the configuration file you used only applies to login shells, and not for a noninteractive shell?

My workstation with OSX Lion came with git installed. My Snow Leopard Server did not, so used one of the available installers after I went to github the other day, and installed git, but I didn't touch the path at all. 

I probably should have done more research, but it seemed straight-forward enough so I didn't bother. After receiving your reply I googled 'OSX git install' and found quite a bit that I will now take the time to read through.

As a general case, rather than continually adding to the path and growing it ever longer, I tend to symlink things in to the correct spots.

I do this a lot with things I am familiar with, but never even thought of it this time...

So:
cd /usr/local/bin && ln -s /usr/local/git/bin/* .

It also has a nice secondary effect of avoiding problems like this.

Thank You very much for taking the time to help me. I am most grateful…

Bill Hernandez
Plano, Texas

mbs400

unread,
Jun 26, 2012, 9:44:37 PM6/26/12
to trac-...@googlegroups.com
Matthew,

I ran these on the server as you suggested

$ cd /usr/local/bin
$ sudo ln -s /usr/local/git/bin/* .

but the error is still there.


# ====================
# From my workstation
# ====================

$ cd '/data/git/sandbox/tmp/'

$ pwd
  ---> /data/git/sandbox/tmp

$ git status
  ---> # On branch master
  ---> nothing to commit (working directory clean)

# ====================
# ERROR (next command)
# ====================
$ git push origin master
  ---> Password:
  ---> bash: git-receive-pack: command not found
  ---> fatal: The remote end hung up unexpectedly

# worked ok with the new symlinks, but still the same problem.

$ git push origin master --receive-pack=/usr/local/bin/git-receive-pack
  ---> Password:
  ---> Everything up-to-date

I restored the server boot disk from an earlier backup, and started over again by getting the osx installer from the git official site.
----------
Latest stable release (download installer)
1.7.11.1
Release Notes (2012-06-21)

----------

Double clicked on the installer from the git site, installed and restarted the server. After it came up to speed I checked :

$ which git
  ---> /usr/local/git/bin/git

Which shows a non standard path as you can see.

BIll Hernandez
Plano, Texas

Matthew Caron

unread,
Jun 27, 2012, 8:23:04 AM6/27/12
to trac-...@googlegroups.com
On 06/26/2012 09:44 PM, mbs400 wrote:
> Matthew,
>
> I ran these on the server as you suggested
>
> $ cd /usr/local/bin
> $ sudo ln -s /usr/local/git/bin/* .
>
> but the error is still there.

It's possible that /usr/local/bin is not in the noninteractive login path.

mbs400

unread,
Jun 27, 2012, 9:23:42 PM6/27/12
to trac-...@googlegroups.com
I described the whole process how I got this working without the errors when I tried to pust to the remote repository, in the hopes it might help someone else. I could have been here till the cows came in, if it hadn't been for matthew Caron and his constant help.


At the Server :

I restored the server boot disk from an earlier backup, and started over again by getting the osx installer from the git official site.
----------
Latest stable release (download installer)
1.7.11.1
Release Notes (2012-06-21)

http://git-scm.com/download/mac
----------

Double clicked on the installer from the git site, installed and restarted the server. After it came up to speed I checked :

$ which git
  ---> /usr/local/git/bin/git

Which shows a non standard path as you can see.

The OSX Server (Snow Leopard) configuration that I am using, has one local admin user with a home directory. The other users are not local users, but LDAPv3 users, so they exist for the purposes of authentication, etc., and have no home directories assigned to them, which is where the problem with the 'interactive shell path' vs the 'non-interactive shell path' comes into play. 

I don't know where the main system wide 'non-interactive shell path' is set at, but one place I was able to set the 'non-interactive shell path' is at ~/.bashrc . Since I did not have a home directory on the server, there was no way to access  ~/.bashrc in order to add the git path. So with this problem in mind, I created a home directory for myself and added a ~/.bashrc file.

I noticed that if I SSH into the remote server via 

local $ ssh ros...@192.168.1.45  

then try to get the $PATH via :

server:~ roscoe $ echo $PATH
  ---> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin

the path that is returned is the 'interactive shell path'. Good so far...

But if instead of logging into the server via ssh, I just issue a remote command (as shown below), then I get the 'non-interactive shell path', which is different from the one above...

$ ssh ros...@192.168.1.45 'echo $PATH;'
  ---> /usr/bin:/bin:/usr/sbin:/sbin

So with this problem in mind (this is a little repetitious, but bare with me), I created a home directory for myself on the server and added a ~/.bashrc file with the following contents, with the last two lines only used during testing...

# (BEGIN) ~/.bashrc
GIT_PATH=/usr/local/git/bin
PATH=$PATH:${GIT_PATH}
export PATH

echo -e "GIT_PATH = ${GIT_PATH} : path set in /Users/roscoe/.bashrc"
echo -e "Called from : /Users/roscoe/.bashrc \nThe current path is : ${PATH}"
# (_END_) ~/.bashrc


On the next command, I get the correct value for the 'non-interactive shell path', which includes '/usr/local/git/bin', hallelujah...

$ ssh ros...@192.168.1.45 'echo $PATH;'
  ---> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin

If I now SSH into the server, I notice below that the path I added in ~/.bashrc does not create a duplicate entry in the 'interactive shell path'

SSH into the server, then check the 'interactive shell path'

$ ssh ros...@192.168.1.45              
  ---> Password:

server:~ roscoe $ echo $PATH
  ---> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin

server:~ roscoe $ 

Sure enough, everything appears OK now. I will test this out !

$ cd 'data/git/sandbox/tmp/'

$ pwd
  ---> data/git/sandbox/tmp

$ git status
  ---> # On branch master
  ---> nothing to commit (working directory clean)

Made some slight changes to the file 'projects/www/index.php' in order to get a valid change in status

$ git status
  ---> # On branch master
  ---> # Changes not staged for commit:
  ---> #   (use "git add <file>..." to update what will be committed)
  ---> #   (use "git checkout -- <file>..." to discard changes in working directory)
  ---> #
  ---> # modified:   projects/www/index.php
  ---> #
  ---> no changes added to commit (use "git add" and/or "git commit -a")

$ git add projects/www/index.php

$ git status
  ---> # On branch master
  ---> # Changes to be committed:
  ---> #   (use "git reset HEAD <file>..." to unstage)
  ---> #
  ---> # modified:   projects/www/index.php
  ---> #

$ cd 'data/git/sandbox/tmp/'

$ git status
  ---> # On branch master
  ---> # Changes to be committed:
  ---> #   (use "git reset HEAD <file>..." to unstage)
  ---> #
  ---> # modified:   projects/www/index.php
  ---> #

$ git commit -m "Testing to overcome remote origin problems."
  ---> [master da64db1] Testing to overcome remote origin problems.
  --->  1 files changed, 3 insertions(+), 1 deletions(-)

$ git remote rm origin
  ---> error: Could not remove config section 'remote.origin'

$ git remote add origin ssh://ros...@192.168.1.45/Volumes/Git/Remote/tmp

$ git push origin master                                                   
  ---> Password:
  ---> fatal: protocol error: bad line length character: Call
  ---> fatal: The remote end hung up unexpectedly

I could not figure out why now I had a new problem, but I reset the /Volumes/Git/Remote permissions on the server , tried it again, and life is now swell. You can see below that it worked...

$ git push origin master
  ---> Password:
  ---> Counting objects: 15, done.
  ---> Delta compression using up to 2 threads.
  ---> Compressing objects: 100% (10/10), done.
  ---> Writing objects: 100% (15/15), 1.60 KiB, done.
  ---> Total 15 (delta 1), reused 0 (delta 0)
  ---> To ssh://ros...@192.168.1.45/Volumes/Git/Remote/tmp
  --->  * [new branch]      master -> master

mbs400

unread,
Jun 27, 2012, 9:26:10 PM6/27/12
to trac-...@googlegroups.com
I tried to pust to the remote repository

Should be : I tried to PUSH to the remote repository

 

Matthew Caron

unread,
Jun 28, 2012, 8:25:11 AM6/28/12
to trac-...@googlegroups.com
On 06/27/2012 09:23 PM, mbs400 wrote:

Glad I could help.

> But if instead of logging into the server via ssh, I just issue
> a remote command (as shown below), then I get the
> 'non-interactive shell path', which is different from the one
> above...
>
>
> $ ssh ros...@192.168.1.45 'echo $PATH;'
>
> ---> /usr/bin:/bin:/usr/sbin:/sbin

Of note on the above - symlinking all the git stuff into /usr/bin would
have also fixed the problem. In fact, that's where most Linux distros
put it these days, since everyone installs from the package manager and
it doesn't put anything in /usr/local (since that's generally for
manually installed things).

(mattc@E2-06L) ~$ which git
/usr/bin/git

Bill Hernandez

unread,
Jun 28, 2012, 1:58:54 PM6/28/12
to trac-...@googlegroups.com
What you are suggesting does make a lot more sense, which I interpret as follows :

( 1 ) Avoid adding to any $PATH if possible
( 2 ) From the existing $PATH, see if there is a suitable place place some symlinks
( 3 ) from the results below, the most logical would be /usr/bin

Note : If I had fully understood what you were trying to get across earlier, with LDAPv3 in mind, i.e. users without home directories in my server setup :

( a ) I could have avoided having to create a home directory for myself on the server.
( b ) Also avoided having to create a ~/.bashrc with the appended path
( c ) If I wanted to grant access to ssh git remote on my server, to other developers, I would have to repeat steps ( a ) and ( b ) for every developer which would be a giant pain.

Now that you point this out again (for like the third time), I can see great value in your approach.

The biggest problem that I had, and didn't know I had, was the difference between the "interactive" and "non-interactive" bash shells. Once you put me onto that concept and I began to research it on the web, I realized the difference between ( A ) and ( B ) below :

( A ) "non-interactive bash shell" echo $PATH result

       $ ssh ros...@192.168.1.45 'echo $PATH;'

          ---> /usr/bin:/bin:/usr/sbin:/sbin


( B ) "interactive bash shell" echo $PATH result

Password:

server:~ roscoe $ echo $PATH
  ---> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin

server:~ roscoe $ which git
  ---> /usr/local/git/bin/git

server:~ roscoe $ 

This has been a great learning experience for me. I will use your approach, i.e. create symlinks to the git stuff in /usr/local/git/bin and put them in /usr/bin which is already in my non-interactive $PATH, and delete the home directory and ~/.bashrc file.

Thanks a million for all the help !

mbs400

unread,
Jun 28, 2012, 2:11:52 PM6/28/12
to trac-...@googlegroups.com
I've attached a picture of my email response, which for some reason gets all messed up when I reply via email instead of on the google group web page.

Any ideas how to respond via email, and not have the display on the web page get so messed up ?
 
google_groups.png
Reply all
Reply to author
Forward
0 new messages