/usr/bin/tar not found (brew install wont work)

Do "sudo ln -s /bin/tar /usr/bin/tar" to create a symlink.

idch said:

Actually, even sudo can't see /usr/bin/tar

Code:

sudo su
sh-3.2# /usr/bin/tar --version
sh: /usr/bin/tar: No such file or directory

Click to expand...

I'd reinstall the OS; who knows what else is missing.

chrfr said:

I'd reinstall the OS; who knows what else is missing.

Click to expand...

This.

Something is seriously messed up. I don't have tar in /bin, it's in /usr/bin. And /usr/bin should be in $PATH, so I have no idea why you're messing with symlinks.

It would probably be quicker to just re-install everything. Something somewhere has deleted or moved files around on your computer. The extent to which things have been scrambled is impossible to determine, unless you have backups you can compare to.

-SC

This is one reason I use Macports, everything in it's subdirectory is self contained and isolated from the rest of the OS.

Macports is just awful. While it may all be shoved off in its own directory, that makes for poor integration with the rest of the OS. homebrew at least tries to adhere to a BSD directory structure. The constant need to be a super user just to do anything with its odd port command is horrid. Then to uninstall it, you might as well wipe the system. Uninstalling homebrew is extremely easy. This problem wasn't caused by homebrew. To alter the tar binary like the OP's, super user permissions were required. Something homebrew refuses to work when evoked.

Intell said:

Macports is just awful. While it may all be shoved off in its own directory, that makes for poor integration with the rest of the OS. homebrew at least tries to adhere to a BSD directory structure.

Click to expand...

Excuse me? Macports closely mimics the BSD packet manager known as ports.

Intell said:

The constant need to be a super user just to do anything with its odd port command is horrid. Then to uninstall it, you might as well wipe the system. Uninstalling homebrew is extremely easy. This problem wasn't caused by homebrew. To alter the tar binary like the OP's, super user permissions were required. Something homebrew refuses to work when evoked.

Click to expand...

I'm sorry, but Macports would never touch or rely on anything that is used by the OS like /usr/bin. That's the point.

Homebrew is convenient I'll give you that, but there is a point behind the stuff you think is horrid.

Macports' implementation of its layout doesn't conform to Mac OS X branch of BSD very well and it bringing in duplicate binaries can cause problems with some shell scripts. It may be good for those the migrate to Mac OS X from UNIX or a UNIX like OS, but not for those that start out on Mac OS X with little to no prior UNIX experience. Macports in the past has completely dirtied up various /usr/ directories on multiple systems of mine. Mostly when trying to upgrade it or remove it. Something homebrew is not capable of due to its non-super user status.

Intell said:

Macports' implementation of its layout doesn't conform to Mac OS X branch of BSD very well and it bringing in duplicate binaries can cause problems with some shell scripts.

Click to expand...

Using /opt is a well established practice.

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

Intell said:

It may be good for those the migrate to Mac OS X from UNIX or a UNIX like OS, but not for those that start out on Mac OS X with little to no prior UNIX experience.

Click to expand...

Why do you say this? As I said, Homebrew is convenient, but there are reasons behind what you think is horrid. Requiring superuser status separates user privileges, it seems like an inane thing to whine about.

Anyway, let's not argue about this please, both alternatives are there to be used, pick your preferred one.

subsonix said:

Using /opt is a well established practice.

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

Anyway, let's not argue about this please, both alternatives are there to be used, pick your preferred one.

Click to expand...

One last thing. Using /opt is not established on Mac OS X's branch of BSD.

Intell said:

One last thing. Using /opt is not established on Mac OS X's branch of BSD.

Click to expand...

Of course it is, you add /opt if you install software packages! That is the point, it's not there, much like /usr/local is not there on a fresh install.

This is all decided on to get some consistency (losely) in the file hierarchy standard, it's years (decades) of experience and thought that has been put in to that.

To a Mac user, /opt is completely unknown. They install packages in /Applications via Installer. Just creating extra things at the root of the drive causes confusion to the end user. Thus why it isn't there. If UNIX packages are installed to a hidden by default directory, there is much less chance of the end user deleting the stray directory. Starting with 10.7, /usr/local is there on a fresh installation, just empty. It was also there for 10.0-10.2, but had some stuff in it.

Intell said:

To a Mac user, /opt is completely unknown. They install packages in /Applications via Installer. Just creating extra things at the root of the drive causes confusion to the end user. Thus why it isn't there. If UNIX packages are installed to a hidden by default directory, there is much less chance of the end user deleting the stray directory.

Click to expand...

Please, how is that different from Homebrew, if someone decides to install a package manager they surely are aware of the root directory.

Intell said:

Starting with 10.7, /usr/local is there on a fresh installation, just empty. It was also there for 10.0-10.2, but had some stuff in it.

Click to expand...

Doesn't make sense that it had stuff in it. But I remain skeptical that it's there by default now, we had a discussion about this in the programming forum a while back, and everyone seems to agree that it's not there on a fresh install. Anyway, moot point.

subsonix said:

Please, how is that different from Homebrew, if someone decides to install a package manager they surely are aware of the root directory.

Click to expand...

homebrew has its files in a hidden directory. Often people blindly follow instructions they found in the internet to get something working. If those instructions include installing Macports to get to something, the /opt directory would be created. Once they're done following the instructions, they'll likely see the new "mysterious" folder. To most unenlightened end users, they'll think it is something bad and remove it. Only removing it could break the end result of the instructions they were following. With homebrew, it's all hidden away from the unknowing end user.

Intell said:

homebrew has its files in a hidden directory. Often people blindly follow instructions they found in the internet to get something working. If those instructions include installing Macports to get to something, the /opt directory would be created. Once they're done following the instructions, they'll likely see the new "mysterious" folder. To most unenlightened end users, they'll think it is something bad and remove it. Only removing it could break the end result of the instructions they were following. With homebrew, it's all hidden away from the unknowing end user.

Click to expand...

Ridiculous, so your main objection now is that Macports doesn't use: chflags hidden /opt in the install script just to save the user from him/her self. Ok then.

Like I said this is a well established practice. And if you want to follow the Mac standard way so religiously why doesn't Homebrew install to /Applications.

I have other objections to it as well, but you've requested that we not discuss those.

Intell said:

I have other objections to it as well, but you've requested that we not discuss those.

Click to expand...

Well you are wrong! And btw, I politely requested that we should not discuss it period (to much of a Vi vs Emacs type of discussion), but you picked one last thing to go on about. I, unlike you, don't think about these things in absolute terms, that is, use what ever you prefer.

Well then, I very much dislike how it messes with my PATH variables. Often obliterating them. I don't like how it doesn't clean up after itself, but leaves garbage and broken symlinks throughout my /usr/ folders. I don't like how some of its binaries override the default ones. I don't like how it requires super user to simply search for available packages (they may have fixed this one). I don't like its lack of certain packages that homebrew and fink have or how they're often broken on 32-bit only Macs. I don't like how its binaries cannot be easily integrated with non-PATH shells things like Applescript. I don't like how tcsh doesn't work without spewing errors at every command once its installed.

I'm sorry man, but this hasn't been my experience. I'm also sorry for the OP who's suggested fix was to reinstall OS X.

Now, please let's end this. I'm sure nothing I say will change your mind.

Can we at least agree that fink is not the recommenced choice for obtaining UNIX and UNIX-like packages?

ScottishCaptain said:

This.

Something is seriously messed up. I don't have tar in /bin, it's in /usr/bin. And /usr/bin should be in $PATH, so I have no idea why you're messing with symlinks.

Click to expand...

By default in 10.8.x, /usr/bin/tar is a symlink to /usr/bin/bsdtar, not /usr/local/bin/bsdtar, nor is tar in /bin. Something changed that somewhere along the line in the OP's system. I'd still lean toward a reinstall (not a format and reinstall) as it'll probably be quicker than figuring out all of what else may have been changed and should fix this.