I am trying to build espeak-NG https://github.com/espeak-ng/espeak-ng/blob/master/docs/building.md on a laptop with Windows 10 and currently trying to implement the prereq step of installing 'the pcaudiolib project checked out to src (as src/pcaudiolib).' - I cloned pcaudiolib https://github.com/espeak-ng/pcaudiolib to the src folder in espeak-ng and attempted to run ./autogen.sh in WSL, resulting in the following:
root#DESKTOP-CLS8BP6:/mnt/c/users/lenovo/desktop/espeak-ng/src/pcaudiolib# ./autogen.sh
-bash: ./autogen.sh: /bin/sh^M: bad interpreter: No such file or directory
When I use ls to check the contents of the directory, autogen.sh is clearly there:
root#DESKTOP-CLS8BP6:/mnt/c/users/lenovo/desktop/espeak-ng/src/pcaudiolib# ls
AUTHORS autogen.sh CHANGELOG.md configure.ac COPYING Makefile.am README.md src
What's going on?
From the comments, it's apparent that you have a script with DOS-style CRLF line-endings that "confuse" Linux/WSL apps/shells/etc., since they expect Unix/Linux LF-only line-endings.
This might have been caused during the checkout. You checked out the repo to your Windows desktop (/mnt/c/users/lenovo/desktop/), so I'm assuming you did it with Windows git.
Typically, you'll want to stick with the Linux tools (git, your editor, etc.) when working with code in WSL.
Attempting to clean up every potentially impacted file manually is probably not the best option.
Try this:
Start in your WSL distribution. I'm assuming this is Ubuntu, but it probably doesn't matter unless you need additional packages.
mkdir ~/src
cd ~/src
git clone https://github.com/espeak-ng/espeak-ng.git
cd espeak-ng
./autogen.sh
That should avoid the mixture of Linux/Windows-DOS style line-endings.
Related
I have some Unix Executable Files in a paticular directory, say /Users/myUserName/Developer/sdcc/bin/.
I find I must get into this directory using cd before running that command, or it complains zsh: command not found.
But it can be of inconvenience. I know the commands can be used in any directory if it's installed by Homebrew. How can I do the same thing?
Homebrew usually links the necessary executables to /usr/local/bin directory, which should be in your $PATH. Thus, when you execute a command like sdcc, your shell will seek through the $PATH directories, and when it looks at /usr/local/bin, it will find sdcc, follow the link and execute it.
Some packages do not perform this linking, which means you cannot execute them without knowing where they are. You can ask Homebrew to tell you where a package is installed: brew --prefix <formula>, where <formula> is the package name (e.g. brew --prefix sdcc). The executable files will normally be under a bin subdirectory. For example, brew --prefix sdcc would likely tell you something like /usr/local/opt/sdcc; then you can invoke sdcc using /usr/local/opt/sdcc/bin/sdcc, without having to cd there. You could also put /usr/local/opt/sdcc/bin into your $PATH directly, though I do not recommend it. Another alternative is to create your own bin (mine is in $HOME/.local/bin), put it in $PATH, and link there (ln -s <source> $HOME/.local/bin/) any executables you wish your shell to easily find.
However, with Homebrew packages, I strongly suggest you do not try to imitate Homebrew by yourself, by installing things in Homebrew's domain. You can confuse Homebrew and create problems. Instead, let Homebrew do it.
If you need to install a package on a different OS than the one you are downloading at, you may need to first find out the bottle tag for the target (installation) computer. For example, for Big Sur, it is big_sur. See brew info --json <formula>, under bottle.stable.files you should find the bottle tags. Use --bottle-tag <tag> in step 1 and 2 to select the right OS.
Use brew fetch --deps <formula> to download (but not install) a package, including its dependencies. If you use the --verbose flag, Homebrew will tell you where it downloaded each of the files.
If you haven't used --verbose and still want to know where the downloaded files are: brew deps <formula> will list all the packages it depends on. If a package needs to be compiled, you may need to also use the --include-build option. brew --cache <formula> will show you where a package file is downloaded.
If you need to copy a package file to another computer, you should find out where the Homebrew would expect to find it: use brew --cache --force-bottle <formula> on the target computer, and copy the package file there. Don't forget to do that for each dependency package as well.
After that, brew install <formula> will install from cache.
The only part of this process that needs internet connection is the first step, brew fetch.
For Unix (which MacOS is a family member) and Unix-like (eg. Linux) operating systems the thing that controls this feature is the PATH environment variable.
To know which folders allow you to run programs without cd-ing into them or prefix ./ to your program name you can print out the value of PATH:
echo $PATH
On my machine it prints out:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/slebetman/bin:/opt/homebrew/bin
There are two things to notice:
The string is a list of folder paths separated by :
There is a path listed as /opt/homebrew. Presumably this is where homebrew installs command-line programs.
Copying your program/script into any of the folders listed in PATH will allow you to use it like any installed/built-in command. This is what it means to install command-line programs on Unix. It's that simple.
There is another thing to notice: I have in my PATH the folder /Users/slebetman/bin. This is my own personal standard - probably not invented by me but one I adopted from my college days - for installing my own programs. I have this ~/bin folder on all my Unix and Linux machines. It is where I keep my personal collection of scripts that I've written or collected over a lifetime.
Having a personal ~/bin folder is nice because you don't need sudo permission to write to it. Also, if you buy a new PC/Mac you can just copy the folder to your new machine and all the scripts you've gotten used to now exist on the new machine. Better yet, you can manage the folder with git and sync it with github/gitlab/bitbucket to make it easy to keep all your computers updated.
Since PATH is a standard environment variable you can easily modify it to add your own folder. Just add the following in your .profile or .zshrc or .bashrc file (depending on your shell) to add your own bin folder to PATH:
export PATH=$PATH:$HOME/bin
The command above simply says add $HOME/bin to PATH and export it so that other programs will inherit the new PATH variable.
In your case you can even do something like:
export PATH=$PATH:/path/to/your/sdcc/bin
to have all your SDCC commands work like regular commands.
EDIT: I've rebooted my computer, and the issue is fixed. I have no idea why it fixed it.
In vs code on windows, when I try to Initialize Repository, I get the error
However, it used to worked fine. It changed when I tried to install Ubuntu on Windows following this video. Git is installed, and the path is in the .json file.
I'll recommend you to install git in ubuntu by apt
The git.path you've specified is to bash, not git. There's probably some wrapper that invokes that binary using git, and so when you type git init, you're really invoking bash init, which asks bash to run the script named init. Since it doesn't exist, your command is failing.
You should set git.path to a path to a Git binary, and not a bash binary.
I'm reading the github wiki for git-for-windows and it says that msys2 bundles pacman: https://github.com/git-for-windows/git/wiki/Package-management
But when I invoke it I get:
$ pacman
bash: pacman: command not found
Does anyone have an idea what is going on?
Which git version does this wiki refer to?
Is there a way to install additional packages to msys2 inside Git for windows?
As mentioned in issue 397:
This is intended. We do not ship pacman with Git for Windows.
If you are interested in a fully fledged package manager maintained environment you have to give the Git for Windows SDK a try.
The bash that you see in the latest git for Windows (2.5.3), which is a more recent bash than the old msysgit one, is only there to execute git commands.
It is not a full-fledged linux environment to install any third-party package.
Warning: dhj reports in the comments
Do not link your existing git for windows with the msys2 main system by using a directory junction.
If you uninstall it will decide that linked directory belongs to it and DELETE YOUR ENTIRE HOME DIRECTORY including sub-directories like "Downloads".
Beware dealing with msys2.
I don't know if the same is true for the git for windows SDK, but BE CAREFUL trying to get pacman from other systems integrated with git for windows.
Git for Windows (https://gitforwindows.org/ or https://git-scm.com/downloads) has Git Bash but it does not include tree.
tree is available via pacman (Package Manager), but that is only available if you install "Git for Windows SDK" (scroll to the bottom of https://gitforwindows.org/ which provides a link to download installer for it from https://github.com/git-for-windows/build-extra/releases/latest)
The accepted answer was very helpful. They mention that git-for-windows was not meant to include pacman in the default install.
So I installed "Git for Windows SDK", then in its bash prompt (SDK-64) I ran the
following to install current tree v1.7.0-1 (as of this posting Aug 30, 2018):
[SDK-64: Bash Terminal for Git for Windows SDK]
pacman -S tree
...
Proceed with installation? [Y/n] Y
On my system, Git for Windows SDK is installed under: C:\git-sdk-64, so from my Git for Windows Bash shell (which did not have tree installed), I copied it over tree.exe to its /usr/bin directory, e.g.
[MINGW64: Bash Terminal for Git for Windows]
cd /usr/bin
cp /c/git-sdk-64/usr/bin/tree.exe .
Now I can run tree v1.7.0 from both Git Bash shells.
To make it even easier for others and maybe myself on a future machine, I looked at where pacman was getting the tree package from by running the following in my Git for Windows SDK Bash terminal:
$ pacman -S --info tree
Repository : msys
Name : tree
Version : 1.7.0-1
Description : A directory listing program displaying a depth indented list of files
Architecture : x86_64
...
The key thing here is that pacman is getting tree from the "msys" repository (FYI: even though it says msys, it really is using msys2), so I looked at /etc/pacman.d/mirrorlist.msys and the first mirror points to http://repo.msys2.org/msys/$arch/
So next time you want a package that is NOT in Git for Windows, you can download them from: http://repo.msys2.org/msys/x86_64/ (for 64-bit) or from http://repo.msys2.org/msys/i686/ (32-bit)
e.g. direct download link for tree v1.7.0-1
64-bit: http://repo.msys2.org/msys/x86_64/tree-1.7.0-1-x86_64.pkg.tar.xz
or https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/tree-1.7.0-1-x86_64.pkg.tar.xz
32-bit: http://repo.msys2.org/msys/i686/tree-1.7.0-1-i686.pkg.tar.xz
or https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/tree-1.7.0-1-i686.pkg.tar.xz
FYI: Git SCM's Window's download at https://git-scm.com/download/ pulls the latest from Git for Windows GitHub (https://github.com/git-for-windows/git from the https://github.com/git-for-windows/git/releases/ link)
I did not want to move from my already working Git for Windows installation so I improvised a bit:
Install Git for Windows SDK somewhere else. You'll need more than 3 GB of free space for that.
Copy ${git-sdk}/usr/bin/pacman.exe to ${git}/usr/bin
Copy ${git-sdk}/etc/pacman.conf and ${git-sdk}/etc/pacman.d to ${git}/etc
Copy ${git-sdk}/var to ${git}/
That's all. You can now open your Git Bash and run pacman -S python to install packages on your existing Git for Windows setup.
You will need write access to Git for Windows directory. Also, your pacman now thinks it has a lot of packages installed (from SDK) but it did not stop me from using it.
"Git for Windows SDK" is 5.33GB compared to "Git for Windows" 691MB compared to "Portable Git" 275MB. I use the lean and mean Portable Git. At first, it seems hopeless trying to restore and use pacman in the latter two flavors of Git (msys2), because Google excluded ALL metadata files in /var/lib/pacman/local. Please read this official explanation:
https://wiki.archlinux.org/index.php/Pacman#.22Failed_to_commit_transaction_.28conflicting_files.29.22_error
Without those metadata files, you don't know the exact collection and version of the msys2 packages Google selected to build a release of those 2 flavors of Git. If you force to install or copy the current version of msys2 packages, you run the risk of version mismatch with git binaries Google built and tested.
Well, that's until I discover this file: /etc/package-versions.txt, the laundry list of matching msys2 packages and versions. Now there is a definitive source in github. Here is how I restore pacman in Portable Git (commands can be copy & paste into git-bash shell all at once):
Step 1: Run these commands to download /etc/pacman.conf and 3 packages: pacman, pacman-mirrors and msys2-keyring. See my Dec 9, 2022 comment below on why you need zstd in .xz format. These packages/versions were tested on both 32 and 64-bit Portable Git 2.38.1:
if [[ "$HOSTTYPE" == "i686" ]]; then
pacman="
pacman-6.0.0-4-i686.pkg.tar.zst
pacman-mirrors-20210703-1-any.pkg.tar.zst
msys2-keyring-1~20210213-2-any.pkg.tar.zst
"
zstd=zstd-1.5.0-1-i686.pkg.tar.xz
else
pacman="
pacman-6.0.1-18-x86_64.pkg.tar.zst
pacman-mirrors-20220205-1-any.pkg.tar.zst
msys2-keyring-1~20220623-1-any.pkg.tar.zst
"
zstd=zstd-1.5.2-1-x86_64.pkg.tar.xz
fi
for f in $pacman; do curl https://repo.msys2.org/msys/$HOSTTYPE/$f -fo ~/Downloads/$f; done
curl -L https://github.com/mcgitty/pacman-for-git/raw/main/$zstd -o ~/Downloads/$zstd
curl https://raw.githubusercontent.com/msys2/MSYS2-packages/7858ee9c236402adf569ac7cff6beb1f883ab67c/pacman/pacman.conf -o /etc/pacman.conf
Step 2: Unpack them at the root then restore pacman with these commands:
cd /
tar x --xz -vf ~/Downloads/$zstd usr
for f in $pacman; do tar x --zstd -vf ~/Downloads/$f usr etc 2>/dev/nul; done
mkdir -p /var/lib/pacman
pacman-key --init
pacman-key --populate msys2
pacman -Syu
Step 3: The next set of commands restore all matching metadata (be patient). Like the zstd packages in Step 1, this relies on my public github repo pacman-for-git to provide the git-sdk commit ID of each Portable Git release, which I'll do my best to update:
t=`grep -E 'mingw-w64-[ix_0-9]+-git ' /etc/package-versions.txt`
t=`curl -sL https://github.com/mcgitty/pacman-for-git/raw/main/version-tags.txt|grep "$t"`
[[ "$t" == "" ]] && echo "ERROR: Commit ID not logged in github pacman-for-git." && read
b=64 && [[ "$t" == *-i686-* ]] && b=32
URL=https://github.com/git-for-windows/git-sdk-$b/raw/${t##* }
cat /etc/package-versions.txt | while read p v; do d=/var/lib/pacman/local/$p-$v;
mkdir -p $d; echo $d; for f in desc files mtree; do curl -fsSL "$URL$d/$f" -o $d/$f;
done; [[ ! -f $d/desc ]] && rmdir $d; done
Step 4: Now, is it too much to ask for 'make' and 'zip'?
pacman -S make zip
Voilà, still just a 337MB mean little environment that can expand and upgrade!
There seems to be a documented way to do this without having to install the Git for Windows SDK (which is very large). I was given the link to this info by PhilipOakley when I asked about all this on GitHub issue #1912.
Here's the current text of the Git for Windows GitHub wiki page about it:
##Install inside MSYS2 proper
###Please note that this scenario is not officially supported by Git for Windows
(The reason this is unsupported is that there are no volunteers to support that scenario.)
This guide assumes that you want the 64-bit version of Git for Windows.
Git for Windows being based on MSYS2, it's possible to install the git package into an existing MSYS2 installation. That means that if you are already using MSYS2 on your computer, you can use Git for Windows without running the full installer or using the portable version.
Note however that there are some caveats for going this way. Git for Windows created some patches for msys2-runtime that have not been sent upstream. (This had been planned, but it was determined in issue #284 that it would probably not be happening.) This means that you have to install Git for Windows customized msys2-runtime to have a fully working git inside MSYS2.
Here the steps to take:
Open an MSYS2 terminal.
Edit /etc/pacman.conf and just before [mingw32] (line #71 on my machine), add the git-for-windows packages repository:
[git-for-windows] Server = https://wingit.blob.core.windows.net/x86-64
and optionally also the MINGW-only repository for the opposite architecture (i.e. MINGW32 for 64-bit SDK):
[git-for-windows-mingw32] Server = https://wingit.blob.core.windows.net/i686
Authorize signing key (this step may have to be repeated occasionally until https://github.com/msys2/msys2/issues/62 is fixed)
curl -L https://raw.githubusercontent.com/git-for-windows/build-extra/master/git-for-windows-keyring/git-for-windows.gpg | pacman-key --add - && pacman-key --lsign-key 1A9F3986
Then synchronize new repository
pacboy update
This updates msys2-runtime and therefore will ask you to close the window (not just exit the pacman process). Don't panic, simply close all currently open MSYS2 shells and MSYS2 programs. Double-check Task Manager and kill pacman.exe it's still running after the window is closed, because it can linger. Once all are closed, start a new terminal again.
Then synchronize again (updating the non-core part of the packages):
pacboy update
And finally install the Git/cURL packages:
pacboy sync git:x git-doc-html:x git-doc-man:x git-extra: curl:x
Finally, check that everything went well by doing git --version in a MINGW64 shell and it should output something like git version 2.14.1.windows.1 (or newer).
#VonC pointed out in the comments that there is discussion about possible additional steps needed in this approach, around half-way down the discussion at https://github.com/git-for-windows/git/issues/2688.
And now, potentially a new way to achieve the required result too:
https://github.com/git-for-windows/git/issues/2688#issuecomment-772311418
Tested on msys2 20190524 on Windows 10 x86_64 1909 10.0.18363.752 and msys2 20220128 on Windows 11 x86_64 21H2 10.0.22000.434
Using regular Git for Windows.
Install msys2 (Version 20190524 is tested.) or Git for Windows SDK. (Not fully tested, but it should work.) Both include PacMan and Git.
Using VFS for Git for Windows or Scalar for Git for Windows (Aka Microsoft git). Method #1 (with some limitations)
Install VFSForGit ( https://github.com/microsoft/VFSForGit ).
Install Microsoft git ( https://github.com/microsoft/git ) with this option "Git from the command line and also from 3rd-party software" enabled.
Create a symbolic link named "git" in msys64\usr\bin\ pointing to C:\Program Files\Git\bin\git.exe . Execute the following command in cmd.exe, not in bash. mklink git "C:\Program Files\Git\bin\git.exe"
Clone a new gvfs repo. gvfs clone https://dev.azure.com/somebody/_git/somerepo. Only the gvfs command can not be executed on msys2.
Use the git command as you are on msys2 normally.
Using VFS for Git for Windows or Scalar for Git for Windows. Method #2
Virtual Filesystem for Git (formerly was GVFS. Official website https://vfsforgit.org/ ) is recommended. Version 2.22 & 2.26 are tested. Scalar (Official website https://github.com/microsoft/scalar ) is NOT recommended, nor completely tested.
Install GVFS and Git for Windows with GVFS patch. Or install Scalar for Git and Git for Windows with Scalar patch. NOT BOTH on the same machine. The default installation destination is C:\Program Files\Git.
Install msys2 x64 somewhere other than C:\Program Files\Git. By default, it is in C:\msys64.
Copy files and subfolders of msys2 (except /etc and git binaries. The msys2 comes without git from factory.) to Git for Windows VFS edition, and copy /etc/pacman.d and /etc/pacman.conf in msys64 folder to Git installation folder, overwrite existing files. It will update msys2 and MinGW runtime to the latest version. For PacMan, the necessary files are /usr/bin/pac* ; /etc/pacman.conf ; /etc/pacman.d/ ; /var ; /usr/bin/msys* ; .(Not fully tested.)
Setup terminal applications. Run C:\Program Files\Git\bin\bash.exe will launch the bash of Git for Windows. Run C:\Program Files\Git\usr\bin\bash.exe will launch bash of msys2. Configure the path of bash for terminal programs, such as Hyper Terminal. Since Git is in the system folder, terminal programs should be Run as administrator.
Config $PATH the environmental variable for GVFS. Run this command in Git Bash. export PATH=$PATH:/C/Program\ Files/GVFS or export PATH=$PATH:"/C/Program Files/GVFS". Or set environmental variables for GVFS in the system property of the control panel. Relogin to take effect. Sometimes this configuration does not work, but PacMan can still run.
Fix PacMan. Set executable permission for binaries. Fox example. chmod +x /usr/bin/pacman ; pacman-key --init ; pacman-key --populate msys2 ; pacman-key --refresh-keys ; pacman --sync pacman --refresh --sysupgrade --sysupgrade --overwrite "*" . Use the option --overwrite \* because some packages were installed by Git for Windows instead of PacMan.
pacman is compressed using zstd now.
So updated #michael-chen 's scenario (i use wsl's unzstd):
for f in pacman-6.0.1-25-x86_64.pkg.tar.zst pacman-mirrors-20221016-1-any.pkg.tar.zst msys2-keyring-1~20221024-1-any.pkg.tar.zst; do curl https://repo.msys2.org/msys/x86_64/$f -o ~/Downloads/$f; done
cd /
tar --use-compress-program=unzstd -xvf ~/Downloads/msys2-keyring-1~20221024-1-any.pkg.tar.zst usr
tar --use-compress-program=unzstd -xvf ~/Downloads/pacman-mirrors-20221016-1-any.pkg.tar.zst etc
tar --use-compress-program=unzstd -xvf ~/Downloads/pacman-6.0.1-25-x86_64.pkg.tar.zst usr
mkdir -p /var/lib/pacman
pacman-key --init
pacman-key --populate msys2
pacman -Sy
export URL=https://github.com/git-for-windows/git-sdk-64/raw/main
cat /etc/package-versions.txt | while read p v; do d=/var/lib/pacman/local/$p-$v; mkdir -p $d; echo $d; for f in desc files install mtree; do curl -sSL "$URL$d/$f" -o $d/$f; done; done
Copying pacman from msys2 works for me, at the end most people forget that you can use pacman for self update as pacman -Syy msys/pacman
Run in msys pacman -Ql pacman
Copy files listed that match
/etc/*.conf
/usr/bin
/usr/include
/usr/lib
/var/lib
And copy databases as well
/etc/pacman
At this point I already have a working pacman,I check it with pacman -Ss pacman but there are missing files so I run self refresh
pacman -Syy msys/pacman
When trying to install pkg-config on a brand new install of 10.8.5 i got a ./configure: no such file or directory.
first I downloaded the source with git
git clone git://anongit.freedesktop.org/pkg-config
then I switched to the directory
cd /Users/nah/Desktop/pkg-config
when I run ls I can see the configure file but when I run
./configure --with-internal-glib
I get ./configure: no such file or directory. Even though I see the file in the pkg-config directory.
When I searched for answers online The two i saw were are you in the correct directory which i clearly am, and the second answer i saw was to use homebrew or Macports. I know homebrew and macports will work but that doesn't really answer the question it's sort of a work around. I than realized that the configure file wasn't executable so I ran chmod on it to make it executable but I get the same thing. The other thing I thought of was the configure file is configure.ac , a quick glance at a bunch of other source files on my computer and they all have configure files with no .ac.
I also tried dragging the executable configure file to terminal to run it and I got
line 1: syntax error near unexpected token [2.62}
/Users/nah/pkg-config/configure.ac: line 1: 'AC_PREREQ([2.62])'
do you think there's a problem with the configure script for Mountain lion, i did this on snow leopard about a month ago with no problems.
so in conclusion, i can't install pkg-config using normal ./configure; make; make install;
And would like to know way to solve problem with out homebrew or Macports work around.
Is this possible?
All tutorials I've come across on how to build and use Rebar involve Unix commands, and I'm a most unfortunate Windows user. I'd really like to avoid installing Cygwin if I can help it.
For example, to build Rebar you get:
$ git clone git://github.com/rebar/rebar.git
$ cd rebar
$ ./bootstrap
Recompile: src/getopt
...
Recompile: src/rebar_utils
==> rebar (compile)
Congratulations! You now have a self-contained script called "rebar" in
your current working directory. Place this script anywhere in your path
and you can use rebar to build OTP-compliant apps.
What is the windows-cmd equivalent?
Any links or tutorial below to offer step by step instructions on how to utilize rebar in windows shell would be greatly appreciated.
UPDATE:
After manually downloading and extracting Rebar to my directory located at:
C:\erlang\rebar
I go to the windows shell and enter:
SET PATH=C:\Program Files\erl5.10.1\bin
This is the 'bin' folder located inside the directory holding erlang.exe
Next I enter:
C:\erlang\rebar>bootstrap.bat
Compiled! :)
There should be a bootstrap.bat script in the rebar directory. You don't need cygwin for this to work, but you will need Erlang installed and on the path.
I assume you have erlang istalled already and added to your path.
You can just download the Git and install it. Then open the git bash and type
git clone https://github.com/rebar/rebar.git
once cloned it to your desired location then you can run the command by going inside the rebar directory.
./bootstrap
Now it will work just fine and tell you that you have the rebar file compiled in your current working directory.
Nice you are good to go with using rebar for your project.
You can also just invoke path\to\erlang-install\bin\escript.exe bootstrap from a (Windows) command shell.
bootstrap is just an e(rlang) script.
You can download and install Git for Windows
Then, use it to run the same exact instructions:
git clone git://github.com/rebar/rebar.git
cd rebar
./bootstrap
and everything should work fine.