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

[idch]

I wanted to brew install nginx and got error

Error: Failure while executing: tar xf /Library/Caches/Homebrew/pcre-8.32.tar.bz2

So I checked my /usr/bin/tar - and got not found

But!

ln -s /usr/bin/tar /bin/tar
ln: /bin/tar: File exists

and

ls -ld /usr/bin/tar
lrwxr-xr-x  1 root  wheel  21  5 июн 15:22 /usr/bin/tar -> /usr/local/bin/bsdtar

Can you please help me? How could I fix this?

 

[Intell]

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

 

[idch]

I got answer:

sudo ln -s /bin/tar /usr/bin/tar
Password:
ln: /usr/bin/tar: File exists

But

/usr/bin/tar --version
-bash: /usr/bin/tar: No such file or directory

And brew install still gives the same error:

brew install nginx
==> Installing nginx dependency: pcre
==> Downloading ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.32.tar.bz2
Already downloaded: /Library/Caches/Homebrew/pcre-8.32.tar.bz2
Error: Failure while executing: tar xf /Library/Caches/Homebrew/pcre-8.32.tar.bz2

 

[idch]

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

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

 

[chrfr]

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

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

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

 

[idch]

I suppose there is no way to reinstall tar?

Google gave me nothing. Apparently I did something with tar when installing homebrew and rails earlier (when I wasn't aware of problems of some commands in terminal).

 

[ScottishCaptain]

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

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

 

[subsonix]

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

 

[Intell]

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.

 

[subsonix]

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.

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

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.

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.

 

[Intell]

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.

 

[subsonix]

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.

Using /opt is a well established practice.

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

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.

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.

 

[Intell]

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.

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

 

[subsonix]

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

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.

 

[Intell]

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.

 

[subsonix]

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.

Please, how is that different from Homebrew, if someone decides to install a package manager they surely are aware of the root 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.

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.

 

[Intell]

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

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.

 

[subsonix]

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.

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.

 

[Intell]

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

 

[subsonix]

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

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.

 

[Intell]

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.

 

[subsonix]

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.

 

[Intell]

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

 

[chrfr]

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.

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.