Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


removes sudo from global installation #1807

merged 1 commit into from

5 participants


The /usr/local/bin folder shouldn't require sudo access.

@sclarson sclarson removes sudo from global installation
The /usr/local/bin folder should require sudo access.
@Seldaek Seldaek merged commit 8f619c1 into from

@sclarson are you sure?

$ touch /usr/local/bin/foo
touch: cannot touch `/usr/local/bin/foo': Permission denied
@Seldaek Seldaek referenced this pull request from a commit
@Seldaek Seldaek Remind people to use sudo, refs #1807 cf6cb35

@tristanlins I think it's one of those platform specific things, I added a n about sudo.


Yes, I'm sure.

Depending on your linux distribution it may not be, but in general it is better to instruct people to use less privilege and possibly add additional steps in case of the error message. Using escalated privilege by default can cause other package managers (homebrew on OSX) to have issues.

I may be wrong, but my viewpoint is that if you're in the situation where it is locked down by default, you're more likely to know what sudo does and know that you need it.


@sclarson: i've never seen a linux distribution in which /usr/local/bin was available for normal users to write to. so sudo is pretty well a necessity.


@sclarson: i've never seen a linux distribution in which /usr/local/bin was available for normal users to write to.

Yes I also not see any distribution allow a regular user to write into /usr/local/bin (and I tried a lot).
/usr/local/bin is for local system wide (=> all users) installation and should only be possible by an admin.
~/bin is for user wide installation and should work on most (not all) distributions out of the box. But can be activated in ~/.profile or ~/.bashrc.


@jrobeson I looked back at our production servers and you're correct. It was my local and some vm's that had that open. I still do prefer assuming not to use sudo unless necessary though as there are a lot of osx users where this is writable by users.

A good alternative may be removing this and adding wording for osx users to not use sudo or to use homebrew to install composer globally.


IMO the advice to use sudo can (should) be omitted entirely as those who are running a server where system wide installation is desired MUST know how to make a binary globally available and how to install it there.
People who do NOT know how to do this are not administrator enough to do it and should use local installations.

I strongly discourage everyone to use sudo without knowing exactly what is happening then, therefore the phrasing in the last commit by @Seldaek should at least be rephrased a little with an explanation. Currently it sounds like: "Hey try this and if it does not work out, simply do it as root, trust us, it won't do any harm." which transports the wrong message, anyone running something as root should be extremely cautious.

On another hand, I already feel people complaining about "why does selfupdate not work for me" etc.
Two sides of the medal.

OTOH: I encourage everyone to install composer in ~/bin vs. system wide, as this is IMO the best way to install anyway.

@digitalkaoz digitalkaoz referenced this pull request from a commit in digitalkaoz/composer
@Seldaek Seldaek Remind people to use sudo, refs #1807 02a1674
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 17, 2013
  1. @sclarson

    removes sudo from global installation

    sclarson authored
    The /usr/local/bin folder should require sudo access.
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 1 deletion.
  1. +1 −1  doc/
2  doc/
@@ -84,7 +84,7 @@ executable and invoke it without `php`.
You can run these commands to easily access `composer` from anywhere on your system:
$ curl -sS | php
- $ sudo mv composer.phar /usr/local/bin/composer
+ $ mv composer.phar /usr/local/bin/composer
Then, just run `composer` in order to run Composer instead of `php composer.phar`.
Something went wrong with that request. Please try again.