I am running this command:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
and I'm get hte error:
HEAD is now at 79e8cdd Merge pull request #1253 from jawshooah/perf/relocate-text-files
/usr/local/bin/brew: /usr/local/bin/readlink: /bin/bash: bad interpreter: Operation not permitted
/usr/local/bin/brew: /usr/local/bin/readlink: /bin/bash: bad interpreter: Operation not permitted
/usr/local/bin/brew: line 47: /usr/local/Library/Homebrew/brew.sh: No such file or directory
Failed during: /usr/local/bin/brew update --force
Does any one know how to solve this?
It's maybe related to filesystem metadata (quarantine attribute), run:
ls -l /usr/local/bin
If you see a # character on some lines such as in -rwxr-xr-x#, you can remove the filesystem metadata with :
xattr -d com.apple.quarantine /usr/local/bin/readlink
Read this question for more information :
Mac OS: /usr/bin/env: bad interpreter: Operation not permitted
Just because I came across this answer in my search for how to fix this problem, and the accepted answer didn't work for me, I figured I would post my solution. After reinstalling brew a million different ways (which had issues due to the readlink problem), reinstalling ruby, xcode-tools, and every other piece of software on the planet, I had the "duhh" moment of trying to see what was wrong with readlink itself.
In the end, this is how I fixed it:
cd /usr/local/bin
rm readlink
Make a file called realpath (or whatever you want) with this content
here:
#!/usr/bin/env python
import os,sys
print os.path.realpath(sys.argv[1])
chmod +x realpath
ln -s realpath readlink
The above instructions can be found here. Essentially we're just replacing whatever readlink they had implemented originally with Python's implementation of the functionality, their os.path.realpath function.
Related
I opened terminal fresh and typed.
$ python3
Then I typed quit to get out of it.
$ quit()
I then typed:
$ pip3 install splinter requests bs4
After I typed:
$ cd supbot-tut
-bash: cd: supbot-tut: No such file or directory
When I typed that I got the error code: -bash: cd: supbot-tut: No such file or directory.
I tried this dozens of times and it won't work. I do not know how to fix this problem and I am a new coder so please send exact code I have to write to fix this problem. Thank you!
Check if you're in the correct directory using pwd and see if that directory contains supbot-tut that you're trying to get into with ls.
Or you can make a directory using mkdir supbot-tut then you will be able to cd into it.
That error occurs when you try to issue the cd command and you pass a directory (a folder) that doesn't exist. Can you type the command ls and see if you see that directory listed. You can easily check with your file explorer too. Create that directory and your issue should go away.
I just tried installing valet for a very long time, - and I couldn't find any help anywhere. No matter what I tried, then it kept saying:
Zsh: command not found: valet
I'm running Zshell (instead of Bash) and OSX. I've had Brew installed for quite a while.
I'll answer this myself, - so hopefully people in the same situation can find this in the future.
I had a very similar problem under Zsh, but my solution was easier. Rather than adding ~/.composer/vendor/bin to my $PATH, I needed to use the full directory name; i.e., /Users/[your-user-name]/.composer/vendor/bin.
Everywhere it says to 'Check that your path is right'. And yup - if you haven't done that, then you should start there. The easiest way is to go to your terminal and write:
echo $PATH
... And then you should see ~/.composer/vendor/bin in between two colons in there. If that isn't there, then you should go to your ~/.bashrc-file (or ~/.zshrc-file) and add this line:
export $PATH=~/.composer/vendor/bin:$PATH
And then it may be fixed.
My problem had deeper roots, though. Even though my path was right, then I still got the error:
Zsh: command not found: valet
And if I wrote: which valet - then it (obviously) just responded with valet not found.
Removal of Composer
What fixed it was to remove all my composer-installations. Composer can be located in several different locations (and installed by brew). So in order to remove it, then do this (inspired by this post, but it lacks a couple of steps):
Remove your composer- or -composer.phar-file. You can find them by running which composer and/or which composer.phar.
Remove your .composer-folder (usually located here: ~/.composer).
Then make sure that there isn't an installation done with Homebrew (this was what I think made the collision for me). You do it by running brew unlink composer followed by brew remove composer.
Then, - if you want to be 100% sure that it's all gone, then go to your root (cd /) and run this command: find ./* -name 'composer.phar' and this find ./* -name 'composer'. That should tell you of all the locations where the Composer-installation can be installed.
When all that's removed, then you should be rid of Composer (entirely).
... Then install it again, - and see if you can get valet to work (it did for me).
The solution was adding composer bin to the path. You can use the following commands
From the terminal
export PATH="$PATH:$HOME/.composer/vendor/bin"
echo 'export PATH="$PATH:$HOME/.composer/vendor/bin"' >> ~/.bash_profile
source ~/.bash_profile
valet install
Issue Ubuntu: no command valet
Valet on Ubuntu:
sudo apt install libnss3-tools jq xsel
composer global require cpriego/valet-linux
.composer/vendor/cpriego/valet-linux/valet install
Now command valet should work, but if still not:
sudo cp .composer/vendor/cpriego/valet-linux/valet /usr/local/bin/
I am trying to install ruby gems on my computer running Ubuntu 16.04. I use bash with the oh-my-zsh framework.
When I run the command:
curl -L https://get.rvm.io | bash -s stable --ruby
I get the error message:
mktemp: failed to create file via template '/usr/share/rvm/rvm-exec-test.XXXXXX': Permission denied
How do I set up the permissions for this to work properly?
You can use:
curl -L https://get.rvm.io | sudo bash -s stable --ruby
NOTE: Running a script as sudo can be very dangerous if you don't know what it is actually doing. Make sure to check the script and if possible give the appropriate permissions to the required files and or folders it needs to access. For some more info regarding why it can be dangerous see https://elementaryos.stackexchange.com/questions/448/why-is-running-commands-with-sudo-dangerous
Quick example with your particular use case, as can be seen in the link:
"...If a website is asking you to curl http://link/to/script | sudo bash, don't do that. Download the script, take a quick look, and after that, you can run it. Even if the original author did not intend to make the script malicious, someone might have compromised the original author's accounts and uploaded a new, "updated" script. You are the one responsible for your computer's integrity, and therefore you need to be familiar with your system's capabilities."
Make The directory as read and write ... cd dirname chmod 777
or
sudo gem install 'gem name','version'
I'm running into:
Error: parent directory is world writable but not sticky
While trying to do:
brew install yarn
Error: parent directory is world writable but not sticky
Please report this bug:
https://github.com/Linuxbrew/brew/blob/master/docs/Troubleshooting.md#troubleshooting
/var/lib/jenkins/.linuxbrew/Library/Homebrew/vendor/portable-ruby/2.0.0-p648/lib/ruby/2.0.0/tmpdir.rb:92:in `mktmpdir'
Does anybody know how to resolve this?
It is a permission problem, When I am trying to install brew install yarn --without-node, Got this error, on my Mac OSx Sierra
First, find out where is your tmp directory using ls -ld /tmp When I ran this command, got the output in following way,
ls -ld /tmp
lrwxr-xr-x# 1 root wheel 11 Jan 28 2017 /tmp -> private/tmp
which means tmp directory is using private/tmp So try giving the permission by using following command
sudo chmod +t /private/tmp
I had a similar error, but in my case the directory with bad permissions was ~/Library/Caches/Homebrew.
chmod +t ~/Library/Caches/Homebrew
fixed it.
Homebrew/Ruby wants to set sticky bit (+t) permission on /private/tmp folder. Set it explicitly using
sudo chmod +t /private/tmp
will solve the issue. Brew command should work fine after this.
I've tried installing GNU grep on OSX, and it seems to be installed, but I can't use it.. I've done so using homebrew, Macports is having some issues currently, so I can't use that.
To install: brew tap homebrew/dupes; brew install grep
Which returns: Warning: homebrew/dupes already tapped! Warning: homebrew/dupes/grep-2.21 already installed
Symlinking seems to work to /usr/local/bin/ggrep. When I add the alias alias grep="ggrep" and do grep --version, I get -bash: ggrep: command not found. Which is true, since there is no ggrep in the folder. I've tried installing with and without --with-default-names.
The folder /usr/local/Cellar/grep/2.21/bin/ contains the following:
-r-xr-xr-x 1 Wes admin 158 Oct 14 09:27 egrep
-r-xr-xr-x 1 Wes admin 158 Oct 14 09:27 fgrep
Which is strange to me, since the documentation implies that The command has been installed with the prefix "g".
I've seen the following post, but none of the solutions work for me. Updating grep for Mac OS 10.7
Does anyone have any solutions? I really want to use GNU grep.
Output of brew unlink grep && brew link grep -v:
Unlinking /usr/local/Cellar/grep/2.21...
6 symlinks removed
Linking /usr/local/Cellar/grep/2.21...
ln -s ../Cellar/grep/2.21/bin/egrep egrep
ln -s ../Cellar/grep/2.21/bin/fgrep fgrep
ln -s ../../Cellar/grep/2.21/share/info/grep.info grep.info info /usr/local/share/info/grep.info
ln -s ../../../Cellar/grep/2.21/share/man/man1/egrep.1 egrep.1
ln -s ../../../Cellar/grep/2.21/share/man/man1/fgrep.1 fgrep.1
ln -s ../../../Cellar/grep/2.21/share/man/man1/grep.1 grep.1
6 symlinks created`
New:
brew uninstall grep; brew install grep
$ which -a grep
/usr/bin/grep
$ which -a ggrep
/usr/local/bin/ggrep
$ echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
This time, it seems something is different. ggrep is finally installed! I think the unlink/link straightened some things out.
How can I set ggrep as the default? With alias?
To make GNU grep the default install it with --with-default-names:
$ brew install grep --with-default-names
If you already have it installed use reinstall instead of install.
Ensure that /usr/local/bin (the location of GNU grep) is before /usr/bin (the location of the BSD grep) in your $PATH; which seems to be the case here.
You might have to start a new shell session afterward because Bash caches the binaries paths for the current session. This means that the first time you use grep it’ll determine which binary it’ll use depending on your $PATH and cache it. The next time it’ll use the cached value so changing your $PATH won’t change anything until you reload the shell.
Offically out of date for the answer above.
As of Homebrew version 2.0.0 the --with-default-names flag is no longer available.
from the official documentation
--with-default-names is no longer supported. It is now installed into its own directory and you will need to adjust your PATH to use it.
What you need to do is to add this command to your shell
PATH="/usr/local/opt/grep/libexec/gnubin:$PATH"
As of Febuary 8, 2020, You could either prepend the PATH and MANPATH variables as eleijonmarck proposes, or use symbolic links to a path loaded early on the PATH. If you choose to use eleijonmarck's method, I would do it differently.
You need to know where Homebrew installs grep binaries.
PATH=/usr/local/opt/grep/bin:$PATH
as opposed to libexec. The Filesystem Hierarchy specifies that the libexec directory
includes internal binaries that are not intended to be executed directly by users or shell scripts.
Also, if you are doing that, then you might want the MAN pages too.
MANPATH=/usr/local/opt/grep/share/man:$MANPATH
The other option is to use symbolic links. You might think to do this:
ln -s /usr/local/opt/grep/bin/grep /usr/local/bin/
The thing is, this won't work, because MacOS has grep as a built-in. Instead, would need to remove or replace the built-in at /usr/bin. You could rename it mv /usr/bin/grep /usr/bin/bsdgrep. This effectively makes grep not findable at /usr/bin, but still usable as bsdgrep (advantage of this technique). Assuming you added grep to /usr/local/bin, you could test your change with:
which grep && grep -V # prove old grep found first
which grep && grep -V # prove new grep found first
The disadvantage of this technique is that you must add a symbolic link per binary.