Do people have directories like /usr/bin or /usr/local/bin be in $PATH since it is usually used when installing new packages through pip and stuff?
I was wondering if it is a good practice to include this to avoid future problems.
Yes, of course, people put /usr/local/bin in PATH. Especially since most macOS users who work from a shell CLI are likely to be using HomeBrew to install things and it's default location is /usr/local/bin. I can't help but wonder if you meant to ask something else.
Related
I've read earlier threads with seemingly related errors, although I'm somewhat skittish about making changes based on what I see here and here, mainly because I'm afraid of breaking things.
I use conda to manage environments on my Mac but there are some packages that aren't available on conda-forge etc., which is why I've had to use Homebrew.
Running brew doctor gives me the errors below, even after brew update. I'm running zsh if it matters, and here's what my $PATH looks like. Any help would be much appreciated.
echo $PATH |tr : '\n'
/usr/local/anaconda3/bin
/usr/local/anaconda3/condabin
/usr/local/anaconda3/bin
/usr/local/anaconda3/bin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
Here's what brew doctor yields:
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
/usr/local/anaconda3/bin/icu-config
/usr/local/anaconda3/bin/krb5-config
/usr/local/anaconda3/bin/freetype-config
/usr/local/anaconda3/bin/xslt-config
/usr/local/anaconda3/bin/libpng16-config
/usr/local/anaconda3/bin/python3.7-config
/usr/local/anaconda3/bin/libpng-config
/usr/local/anaconda3/bin/xml2-config
/usr/local/anaconda3/bin/python3.7m-config
/usr/local/anaconda3/bin/python3-config
/usr/local/anaconda3/bin/curl-config
/usr/local/anaconda3/bin/ncursesw6-config
/usr/local/anaconda3/bin/pcre-config
/usr/local/anaconda3/bin/nspr-config
/usr/local/anaconda3/bin/ncurses6-config
/usr/local/anaconda3/bin/nss-config
These messages are completely normal. They haven't caused any problems for me so far. I suggest you just ignore them. brew doctor is more of a verbose log than urgent issues with your environment.
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/
When I type in echo $PATH I get
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin
That looks crazy redundant. Is this okay/is it going to cause any problems? If not how do I fix it?
Thanks!
This isn't unusual, and it isn't redundant. Unix-like systems split the path on :, so your path contains the following directories:
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
/usr/local/sbin
Different kinds of binaries live in each of these locations. You don't specify your operating system, but this FreeBSD manpage gives an overview of how it treats these directories.
Various Linux distributions treat these directories a little differently, but the principle still holds.
This is totally normal.
If you try to run a application it will search the left most path first for the executable.
Succumbing to pressure, I've installed Homebrew and given it a whirl. But I'm surprised at the experience so far. My impression of Homebrew is that it serves as an easy to use, safe, and self-contained package manager for OS X. But this has not been my experience.
(1) The first thing it does is change a bunch of permissions on a number of scary looking directories:
==> The following directories will be made group writable:
/usr/local/.
/usr/local/bin
/usr/local/include
/usr/local/lib
/usr/local/lib/pkgconfig
/usr/local/share
/usr/local/share/man
/usr/local/share/man/man1
/usr/local/share/man/man3
/usr/local/share/man/man7
/usr/local/share/info
/usr/local/share/doc
==> The following directories will have their group set to admin:
/usr/local/.
/usr/local/bin
/usr/local/include
/usr/local/lib
/usr/local/lib/pkgconfig
/usr/local/share
/usr/local/share/man
/usr/local/share/man/man1
/usr/local/share/man/man3
/usr/local/share/man/man7
/usr/local/share/info
/usr/local/share/doc
(2) The next thing it does (following the recommended procedure to run brew doctor) is ask me to delete a whole bunch of scary looking files:
Warning: Some directories in /usr/local/share/man aren't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew. If a brew tries to add locale information to one of these
directories, then the install will fail during the link step.
You should probably `chown` them:
/usr/local/share/man/de
/usr/local/share/man/de/man1
/usr/local/share/man/mann
Warning: Broken symlinks were found. Remove them with `brew prune`:
/usr/local/share/ghostscript/9.05/Resource/Font/blex.pfb
[hundreds...]
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libasan.1.dylib
/usr/local/lib/libasan.2.dylib
/usr/local/lib/libatomic.1.dylib
/usr/local/lib/libcdt.5.dylib
/usr/local/lib/libcgraph.6.dylib
/usr/local/lib/libcilkrts.5.dylib
/usr/local/lib/libgcc_ext.10.4.dylib
/usr/local/lib/libgcc_ext.10.5.dylib
/usr/local/lib/libgcc_s.1.dylib
/usr/local/lib/libgcc_s.10.4.dylib
/usr/local/lib/libgcc_s.10.5.dylib
/usr/local/lib/libgfortran.2.0.0.dylib
/usr/local/lib/libgfortran.3.dylib
/usr/local/lib/libgmp.10.dylib
/usr/local/lib/libgmpxx.4.dylib
/usr/local/lib/libgomp.1.dylib
/usr/local/lib/libgvc.6.dylib
/usr/local/lib/libgvpr.2.dylib
/usr/local/lib/libitm.1.dylib
/usr/local/lib/liblkdynam.dylib
/usr/local/lib/liblkrealt.dylib
/usr/local/lib/liblksec.dylib
/usr/local/lib/liblksock.dylib
/usr/local/lib/libmpc.3.dylib
/usr/local/lib/libmpfr.4.dylib
/usr/local/lib/libpathplan.4.dylib
/usr/local/lib/libquadmath.0.dylib
/usr/local/lib/libssp.0.dylib
/usr/local/lib/libstdc++.6.dylib
/usr/local/lib/libtcl8.6.dylib
/usr/local/lib/libtk8.6.dylib
/usr/local/lib/libubsan.0.dylib
/usr/local/lib/libxdot.4.dylib
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/c++/5.0.0/backward/auto_ptr.h
[hundreds...]
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libasan.la
/usr/local/lib/libatomic.la
/usr/local/lib/libcilkrts.la
/usr/local/lib/libgfortran.la
/usr/local/lib/libgmp.la
/usr/local/lib/libgmpxx.la
/usr/local/lib/libgomp.la
/usr/local/lib/libitm.la
/usr/local/lib/libmpc.la
/usr/local/lib/libmpfr.la
/usr/local/lib/libquadmath.la
/usr/local/lib/libssp.la
/usr/local/lib/libssp_nonshared.la
/usr/local/lib/libstdc++.la
/usr/local/lib/libsupc++.la
/usr/local/lib/libubsan.la
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/libcdt.pc
/usr/local/lib/pkgconfig/libcgraph.pc
/usr/local/lib/pkgconfig/libgvc.pc
/usr/local/lib/pkgconfig/libgvpr.pc
/usr/local/lib/pkgconfig/libpathplan.pc
/usr/local/lib/pkgconfig/libxdot.pc
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libatomic.a
/usr/local/lib/libcilkrts.a
/usr/local/lib/libgfortran.a
/usr/local/lib/libgmp.a
/usr/local/lib/libgmpxx.a
/usr/local/lib/libgomp.a
/usr/local/lib/libitm.a
/usr/local/lib/libmpc.a
/usr/local/lib/libmpfr.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libssp.a
/usr/local/lib/libssp_nonshared.a
/usr/local/lib/libstdc++.a
/usr/local/lib/libsupc++.a
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
(3) It fails to install, for example, attempting to install matplotlib-basemap gives me
==> Installing matplotlib-basemap from homebrew/homebrew-python
==> Installing dependencies for matplotlib-basemap: numpy, pkg-config, libpng, freetype, matplotlib, jpeg, libtiff, little-cms2, webp, pillow
==> Installing matplotlib-basemap dependency: numpy
==> Using Homebrew-provided fortran compiler.
This may be changed by setting the FC environment variable.
==> Downloading https://downloads.sourceforge.net/project/numpy/NumPy/1.9.1/numpy-1.9.1.tar.gz
Already downloaded: /Library/Caches/Homebrew/numpy-1.9.1.tar.gz
==> Patching
==> python setup.py build --fcompiler=gnu95 install --prefix=/usr/local/Cellar/numpy/1.9.1
File "/private/tmp/numpy-PSE07t/numpy-1.9.1/numpy/distutils/fcompiler/gnu.py", line 197, in get_flags_opt
v = self.get_version()
File "/private/tmp/numpy-PSE07t/numpy-1.9.1/numpy/distutils/fcompiler/__init__.py", line 434, in get_version
raise CompilerNotFound()
numpy.distutils.fcompiler.CompilerNotFound
couldn't understand kern.osversion `14.0.0'
even though I have the ScyPy stack and gfortran already installed and working fine.
Is there a way out of this mess? How do I get from a working configuration (Xcode, Python, Python packages maintained in site-packages with pip, etc.) to one that also uses Homebrew (and continues to work)? Do I really need to follow all of the Doctor's recommendations and delete all those files in order to proceed; is it safe to do so?
The issues you show aren't indicative of a general problem.
The fact that Homebrew "takes over" /usr/local/ is a well-documented design decision. It might be "scary" at first, but it works that way for everybody. It is possible to install Homebrew into a different directory, if you really want to do that.
brew doctor warnings are also normal if you have existing non-brewed software installed under /usr/local/. Note that these are warnings that say something to the effect of, if you are having problems, these could be causes. It doesn't say, delete all of these files before doing anything else. (plenty of questions on SO on this issue)
and 4. are just bad luck AFAICT. These are somewhat off-the-beaten-path packages, so they might be having some issues right now.
If you can install mainstream packages like, I don't know, git or make or lynx, then everything is probably fine and you just need to work out the issues with the individual packages.
/usr/local is yours — I mean — it's not a system location, though it is specific to your system. Of f**k. Lemme start over.
The reason of Homebrew being in /usr/local is because that place is reserved for modifications that shouldn't be touched by macOS updates.
As for the permissions, just claim the whole thing (/usr/local) to yourself (you are an admin, right?). In your account, in Bash, not elevated (prompt $ not #), do:
sudo chown -fR "$(id -u):$(id -g)" /usr/local
Maybe try lowering its permissions to a common group. If you pay attention to the commands Homebrew tells you to run to fix permissions, they all specify a username, it's not great in machines with multiple users, regardless if all of them are you. If you have multiple accounts in the system you have to make sure they all share access to Homebrew's directories under /usr/local. In this case not the whole /usr/local (unless, again, all users are yours).
Add yourself to the admin groups (works for Active Directory accounts too, though dsconfigad is supposed to do that for you):
sudo dscl . -append /groups/wheel GroupMembership $USER
sudo dscl . -append /groups/admin GroupMembership $USER
If $USER (the command dscl requires elevation so to check elevation is needed too: sudo echo $USER) somehow doesn't match your account, id -u(n) is evaluated on the spot.
sudo dscl . -append /groups/wheel GroupMembership "$(id -u)"
sudo dscl . -append /groups/admin GroupMembership "$(id -u)"
When problems start appearing about Homebrew not being able to delete thing it's always about permissions. Check your file structure. Homebrew has a caching location in your home Library ($HOME/Library/Caches/Homebrew), if you're not running, Docker, Spotify or iCloud, this should be one of the biggest folders there.
You can just nuke it if you're not in the mood, things will be downloaded again. ~/Library is a heavily accessed place, it is the reason why Macs can't use networked home directories anymore. It is prone to corruption specially when the system is busy, despite Apple's APFS claims of being on top of things.
It wouldn't hurt to be more aggressive with things, delete whole structures, break things. It's your system*! Make it your b****. You'll learn a lot. As long as you keep backups, the worst that can happen is you waste an hour reinstalling macOS.
*: If you're using anything past Mojave, then forget it. Apple owns your system.
Trying to get a rails server running nicely.
downloaded ruby 1.8.7 using link from rails page.
did ./configure/make/install, installed it fine.
tried ruby -v , got nothing.
tried ./ruby -v from the folder and it worked.
I feel like i've gone from understanding something about unix, to completely lost. Clearly ruby is working as a 'daemon', but not running as it should. Any help would be MUCH appreciated. Losing too much hair through this process :(
J.
can you see where make install put the ruby executeable?
if you do, check if this dir is in your $PATH by
echo $PATH
In general, unix needs to know where to find the executable file to be able to run it. It uses $PATH to find this executable file.
So if you type "ruby" it will go look at you $PATH and then look in each of those directories for a file named "ruby". If it can't find it in any of those directories it should then also look in the current directory.
So, this whole process will fail if:
a) the directory that contains the executable ruby file is not in any of the directories in $PATH AND
b) the executable is not in the current directory
... one more alternative is that is is available in one of these directories... but is not actually marked as being executable by you. You can check this by making sure you're int e directory with the ruby file and typing "ls -l ./ruby"
That will list the ruby file along with all its permissions and who owns it.
It should be something like:
lrwxrwxrwx 1 root root 7 2010-02-14 10:45 ./ruby
Notice the rwx. If your ruby doesn't have x then you'll need to add executable permission using chmod eg: "chmod 755 ./ruby"
Also note the "root root" - that means it's owned by root - in general, this means that only root can run it. In this particular example it has eXecute permission for everyone so everybody can run it, but if you do not have execute permission set like this, then it means that if you are trying to run it as yourself, you won't have permission, and you should either add full permissions or try running it using: "sudo ruby"
However - by the sounds of it - the most likely problem is that you just don't have the ruby executable's directory in your $PATH. You will need to fix this even if you get it running right now - because, in future, you will need to run ruby from directories other than the current one.
You will need to google for instructions on adding things to your $PATH - because it differs depending on your version of linux and your current shell, but it's not very difficult.
Which shell are you running? If tcsh, you may need a "rehash". Otherwise, as leifg says, add the directory containing the ruby executable to your path.