Could not run bk after installing bk-7.2ce-x86_64-macosx.pkg on OS X 10.11

I downloaded bitkeeper 7.2ce on OS X and ran the .pkg file to install it.

The installer seemed to work correctly, including asking for my password, but I was then unable to run bk from command line.

According to the OS X installation instructions, the password allows the installer to create a symlink in /usr/bin for the bk executable.

I found no bk in /usr/bin/ so I tried to create it manually:

sudo ln -s /Applications/ /usr/bin/bk

But got the response ln: /usr/bin/bk: Operation not permitted

(perhaps that’s why the installer couldn’t do it?)

I then made a symlink in /usr/local/bin (which is also in my path)

sudo ln -s /Applications/ /usr/local/bin/bk

This sorta-kinda works.

If I run /usr/local/bin/bk, an application called Wish creates a small window and my command prompt changes to %

If I run /usr/local/bin/bk version -s,

I get Error in startup script: couldn't read file "version": no such file or directory

My guess is that the installer couldn’t create the symlink it wanted, and my attempt doesn’t work because /Applications/ might not be the correct thing to symlink anyway.

I’m headed to bed so will be slow to reply to any suggestions on how to proceed.

I don’t think OS X allows sudo anymore. What the installer does is that it tries
to add /Applications/ to /etc/paths.d/10-BitKeeper.

See the create_bklink() function in:

Maybe all you need to do is exit your current terminal and start a new one?

tl;dr New shells should get the correct path and be able to see bk

First, your symlink was incorrect. You’re pointing at the binary that starts the application bundle.

ln -s /Applications/ /usr/local/bin/bk

would work.

However, that shouldn’t be necessary. Simply restarting a new shell should be enough.

By default on MacOS X, /etc/profile will run:

```eval `/usr/libexec/path_helper -s````

and that should build a path from the contents of /etc/paths and files in /etc/paths.d.

MacOSX 10.11 does some magic where /usr/bin was not writeable by anybody, ever. To work around this, our postinstall script detects that situation and will create /etc/paths.d/10-BitKeeper with the correct contents.

See man path_helper for information about that command.

TL;DR ran `eval /usr/libexec/path_helper -s manually.

@georgn I deleted the incorrect symlink.

I see /etc/paths.d/10-BitKeeper

cat /etc/paths.d/10-BitKeeper gives me


But restarting shell didn’t seem to help. I’m using iTerm2, so I quit that and restarted, but no luck. I also tried Terminal, but that didn’t work either.

Though my /etc/profile seems fine

$ cat /etc/profile

System-wide .profile for sh(1)

if [ -x /usr/libexec/path_helper ]; then
eval /usr/libexec/path_helper -s

if [ “${BASH-no}” != “no” ]; then
[ -r /etc/bashrc ] && . /etc/bashrc

When I ran /usr/libexec/path_helper manually, it seems to have solved it:

$ ls -al /usr/libexec/path_helper
-rwxr-xr-x 1 root wheel 18896 Dec 3 15:36 /usr/libexec/path_helper
$ eval /usr/libexec/path_helper -s
$ bk version -s

Thank you @ob and @georgn for helping me get started!

Certainly, if you are manually setting your PATH in your own profile/bashrc then you’ll break what we were attempting to achieve. Glad you’re over this particular hump.