MacOS – Problems With Terminal (/usr/bin)

bashmacosterminal

I'm experimenting around with my computer and I realized that all the commands in the terminal that aren't bash builtins were stored in the /usr/bin. So I wanted to see (to confirm my realization) that they would not work in Terminal if they weren't there. So I copied bin to my desktop and deleted bin in usr. Sure enough, I was right. All the builtins still worked but things like 'say' didn't. Feeling content with myself for figuring out something about my computer, I promptly placed bin back in usr and check to see if 'say' was working to confirm no harm was done. It worked. Then some time later I need to use sudo for something and I get an error. I restarted my computer, hoping that would help. Now I can't even use Terminal anymore. When I boot it up it says:

Last login: Fri Jul 25 01:12:20 on console
login(529,0x7fff744b4310) malloc: *** error for object 0x7fcfa3600e20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

[Process completed]

Uh-oh, so how do I fix this? The only thing my non-educated brain can think of is a reinstall of OS X.

Best Answer

I figured it out by searching it myself (sorry for not thinking of that first). You just go to the disk utility and click 'Repair Disk Permissions'.

Related Solutions

MacOS – Executables in /bin and /usr/bin are not found in path

Terminal.app correctly starting the shell does’t mean much: it runs /usr/bin/login (with the full path) by default, which invokes your default shell (again: defined with a full path) as an interactive login shell (which will in turn read both .profile and .bashrc and leave you with a working $PATH). Your problem is non-interactive shells, which do neither, do not get any $PATH settings. That seems to point to OS X’ default path settings having somehow been clobbered.

To check this, run cat /etc/paths. The output should (at the very least) be

/usr/bin
/bin
/usr/sbin
/sbin

(these are the defaults on a pristine OS X install). If the first two are missing, you have your cause – and an easy solution:

mv /etc/paths /etc/paths.old # if you want to keep the current contents
def_paths=(/usr/bin /bin /usr/sbin /sbin)
for p in ${def_paths[@]}; do echo $p >> /etc/paths; done
cat /etc/paths.old >> /etc/paths # append previous contents

Note that as /etc/paths is owned by root, you will have to sudo su for this to work.

MacOS – Problem with Terminal after changed permission to /usr/bin

Given that you changed the read permissions on /usr/bin recursively, trying to restore the proper permissions through Terminal will not work - too many items in there have unique permissions. The best plan of action to remedy this I have is as follows.

Open Disk Utility and run Repair Permissions on your disk. This may restore the proper permissions on the files in /usr/bin.
Reboot into Recovery mode (hold the R key down during boot) and run Disk Utility there attempting the same Repair Permissions.
If you have a Time Machine backup, restore your system from a time prior to making the permissions change. This would be accessed through Recovery mode.

Takeaway from this is never change permissions recursively on a directory unless you specifically know what you're doing.

Related Question