Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS usr/local/bin
- Thread starter SHankara
- Start date
- Sort by reaction score
To gain more understanding of what is going on. Finder seems to give mixed messages about the availability of /usr/local/bin. It might also be a permissions related issue for example.
Not if you copy/paste my commands in integrality with sudo.
You do like to argue though.
Eh, /usr/local looks like this: drwxrwxr-x
Meaning you should not need to use sudo, if you do, then perhaps the OP is not logged in as admin, in which case he can not use sudo anyway.
See how that relates to permissions?
I'm not logged in to a Mac. If he had tried sudo and wasn't part of the admin group, it wouldn't have said "Permission denied", it would have told him he's not in the sudoers file.
Again, you just like to argue. End thread if you ask me. These are not Unix types that want to know all these intricate details and broken installers that don't create inexisting directories are just broken, it's not the system's fault.
Mine doesn't:
Code:
ls -ld /usr/local
[B]drwxr-xr-x 6 root wheel 204 Dec 28 16:25 /usr/local
[/B]And on one machine, I have no /usr/local at all. Why? Because I haven't created one there yet.
So? It's even more restrictive.
/usr/local/bin was the topic no? Perhaps there is no local either, or it's related to restricted permissions for the OP. hier mentions /usr/local/ but no more than that.
Copy and paste the exact commands you used, and post them.
Copy and paste the exact error message that resulted.
Accuracy is necessary.
There is a big difference between /usr/local/bin and usr/local/bin. The leading slash is crucial.
The red-hilited directory names are not identical. The first doesn't have a leading slash. The second does.
Accuracy is necessary.
Copy and paste the following command-line into a Terminal window.
Code:
ls -lde /usr /usr/local ; id
Last edited:
Which kind of defeats your earlier argument about my post.
Again, you just like to argue for arguments sake. Just drop it.
Which kind of defeats your earlier argument about my post.
It actually confirms my earlier argument, you could use a brute force method ant just sudo a directory in place, but never notice that you have a permissions related issue which permits the installation. Which was my point.
The default is an empty /usr/local
This is meant for executables and libs and so on that is not part of the OS.
It's the third time you bring that up, yet you keep quoting my posts.
Why do you keep being wrong about this ? I'm not the only stating one the obvious :
The default is no /usr/local, not an empty one. As such, the brute force method is best when broken installers fail to create it. No need to go all "nutty" trying to figure out stuff.
Real end of thread for me. Not to first time you've dragged things on and on.
/usr/local IS installed by default, but is empty. The directory that is not, and the topic of the thread is /usr/local/bin.
It doesn't exist on my work MBP running 10.6.8. I do have an /opt/local which MacPorts created for me.
B
You should qualify that by giving the OS version(s) where it is created by default (or where you believe it is created by default).
I assure you, I have standard Mac OS X installs which do not have /usr/local. The example I gave that lacks /usr/local started as a 10.4.10 install on a Core 2 Dup Mac mini and was upgraded several times. It's now at 10.6.5 (for testing reasons), but still lacks /usr/local.
I have other machines where I explicitly created /usr/local and /usr/local/bin, but they didn't have those dirs by default, either.
In any case, without knowing what permissions are on the user's actual dir, and what userid the user is actually running under, it's impossible to know what command is certain to work.
Furthermore, it's never necessary to issue multiple mkdir commands, as KnightWRX posts. The -p option will make intervening directories that don't exist. It also won't complain if it doesn't need to make directories. As I pointed out in post #14. However, as with all creation involving the file-system, permissions must allow the creation, and without knowing what all the actual permissions are (mode bits, ownership, ACLs, and file flags), no command-line can be written that is guaranteed to work in all circumstances.
Last edited:
root doesn't give a crap about ACLs/permissions :
Code:
$ mkdir local
$ chmod 000 local
$ ls -ald local
d--------- 2 user group 4096 Feb 8 15:21 local/
$ mkdir local/bin
mkdir: cannot create directory `local/bin': Permission denied
$ sudo mkdir local/bin
$ ls -ald local/bin
ls: cannot access local/bin: Permission denied
$ sudo ls -ald local/bin
drwxr-xr-x 2 root root 4096 Feb 8 15:21 local/binSo technically, a command line can be guaranteed to work when it comes to mkdir and when talking about permissions/ACLs.
(of course, I make no guarantees if we're talking about NFS volumes for which the root= option is not set for our particular client).Unless you've been naughty with the /etc/sudoers file to make mkdir run as an unpriviledge user, under OS X, a user typing "sudo mkdir" should run as root and bypass any permission/ACL problems.
You're right about the -p option though, simplifies things greatly :
Code:
$ sudo mkdir -p /usr/local/binThere's also the m switch that could make the dir writeable immediately for the group, without messing with the umask of root :
Code:
$ sudo mkdir -p -m 775 /usr/local/bin
Last edited:
True, as far as it goes.
True, as far as it goes.So technically, a command line can be guaranteed to work when it comes to mkdir and when talking about permissions/ACLs.
However, the lock flag will prevent even root from writing to a directory. It can be set or cleared with the 'chflags' command. The lock bit is also changed using the Finder's Get Info window, the Lock checkbox. Try it. See what happens.
See man 1 chflags, man 2 chflags, and the ls -O option.
True, as far as it goes.
However, we don't know with certainty that the logged-in userid is actually in sudoers. That's why the command-line I posted, for the user to paste into Terminal, contains the 'id' command. So we can actually see what userid is, and what groups it belongs to.
That would only solve the user's problem if the logged-in userid is a member of the group assigned to the dir. Again, we don't know if the userid is in that group or not, until we get the ouput that shows otherwise.
Found this thread looking for something similar, I have a clean install of Snow Leopard and am getting into development using XCode.
I'm advised that /usr/local is the most standard place to put 3rd-party code/libs for development, is that right?
I found/usr existed but not /usr/local, I created it but I'm getting sick of having to sudo everything. Can I make /usr/local act like a regular dir? Or is the fact it's protected a sign I should be putting code files elsewhere?
I'm advised that /usr/local is the most standard place to put 3rd-party code/libs for development, is that right?
I found/usr existed but not /usr/local, I created it but I'm getting sick of having to sudo everything. Can I make /usr/local act like a regular dir? Or is the fact it's protected a sign I should be putting code files elsewhere?
That's the 'unix way', but if you install a Mac library like Cocos2d it copies things like templates to folders like /Library/Application Support/Developer/ and then a project like SDL will install libraries and headers in a 'Framework bundle' in the location of /Library/Frameworks. That's the 'OS X way'
Copy and paste the following command-line into a Terminal window.
Code:
ls -lde /usr/local ; idWhy? To discover what the group ownership of /usr/local is, what its access permissions are, and to discover what your userid and its group membership is.
Why? Because if your userid is a member of the group assigned to the directory, and the directory has group-write permission, you'll be able to write to it. So will any other member of the same group, so it's not a one-size-fits-all solution. There are security implications.
I posted the same request to the thread starter in post #33, but never got an answer.
Sure, just change the permissions on that directory and the folders inside.
You'll want to brush up on user/group permissions:
http://www.dartmouth.edu/~rc/help/faq/permissions.html
The simple way to do it is 'chmod 777 /usr/local' but that isn't the correct way. That lets any user modify that directory.
Code:
ls -lde /usr/local ; id
drwxr-xr-x 3 root wheel 102 6 Apr 16:17 /usr/local
uid=501(MY-NAME) gid=20(staff) groups=20(staff),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),402(com.apple.sharepoint.group.1),401(com.apple.access_screensharing)I replace my actual username (uid 501) with MY-NAME, otherwise this is what I received. So I think I want to grant all permissions to MY-NAME on /usr/local? Is it also possible to make it non-hidden?
If you're sure that's exactly what you want:
Code:
sudo chown MY-NAME /usr/localThis command changes ownership of the directory. If that's not what you want, with all its consequences, then don't execute that command.
Non-hidden to what?
If you mean "visible in Finder", the answer is no, not without making everything else hidden visible.
I recommend the "Go to Folder..." menu item in Finder's Go menu. Tell it /usr, then in the window for /usr, make an alias for local. Move the alias to your desktop (or wherever you want it). When you want to see /usr/local, double-click the alias.