I've been using homebrew for a while on OSX Mavericks, however I'm now dealing with needing to add files to folders of those same installed programs.
Here's the issue, when typing:
$ brew info ant
I get /usr/local/Cellar/ant...., as does any of my installed programs. The issue is that the Cellar doesn't seem to exist on my computer. When I search from Spotlight it finds no usr folder, with the exception of some nested within my Eclipse folder that hasn't been used for years. When I attempt to:
$ cd ~/usr/
it, too, doesn't exist. Also NO folder on my computer exists called Cellar (that Spotlight can find)
Does homebrew store this folder in some hidden way? (I'm hesitant to think this is the case, since I have all hidden files shown)
While in the Finder, enter Cmd+Shift+G and enter /usr/local/Cellar in the dialog that pops up.
Alternately, in Terminal.app (or whatever terminal program you're using), enter open /usr/local/Cellar at a prompt.
Both will open up a new Finder window to the homebrew Cellar directory.
You can verify that the Cellar directory is in the default location with brew --cellar in the terminal.
I found my Cellar folder on:
/opt/homebrew/Cellar
But the best trick is run the command brew --cellar
Re-installing the homebrew solved the issue for me.
It looks like the issue after upgrading to Mavericks.
See https://brew.sh/ run the install again.
You need to type
cd /usr
not
cd ~/usr
/usr is at the top of the file directory for unix based systems, its not something in your home folder (~ = /Users/yourname )
to get spotlight to see the folder you will have to make a symlink to it somewhere outside of /usr.
This post covers a similar problem and has a suggested solution using Automomator to prevent any issues with any apps installed with homebrew: https://apple.stackexchange.com/questions/23653/can-i-make-a-symlink-to-a-app-folder-in-applications-directory-show-up-in-spo
Related
I have some Unix Executable Files in a paticular directory, say /Users/myUserName/Developer/sdcc/bin/.
I find I must get into this directory using cd before running that command, or it complains zsh: command not found.
But it can be of inconvenience. I know the commands can be used in any directory if it's installed by Homebrew. How can I do the same thing?
Homebrew usually links the necessary executables to /usr/local/bin directory, which should be in your $PATH. Thus, when you execute a command like sdcc, your shell will seek through the $PATH directories, and when it looks at /usr/local/bin, it will find sdcc, follow the link and execute it.
Some packages do not perform this linking, which means you cannot execute them without knowing where they are. You can ask Homebrew to tell you where a package is installed: brew --prefix <formula>, where <formula> is the package name (e.g. brew --prefix sdcc). The executable files will normally be under a bin subdirectory. For example, brew --prefix sdcc would likely tell you something like /usr/local/opt/sdcc; then you can invoke sdcc using /usr/local/opt/sdcc/bin/sdcc, without having to cd there. You could also put /usr/local/opt/sdcc/bin into your $PATH directly, though I do not recommend it. Another alternative is to create your own bin (mine is in $HOME/.local/bin), put it in $PATH, and link there (ln -s <source> $HOME/.local/bin/) any executables you wish your shell to easily find.
However, with Homebrew packages, I strongly suggest you do not try to imitate Homebrew by yourself, by installing things in Homebrew's domain. You can confuse Homebrew and create problems. Instead, let Homebrew do it.
If you need to install a package on a different OS than the one you are downloading at, you may need to first find out the bottle tag for the target (installation) computer. For example, for Big Sur, it is big_sur. See brew info --json <formula>, under bottle.stable.files you should find the bottle tags. Use --bottle-tag <tag> in step 1 and 2 to select the right OS.
Use brew fetch --deps <formula> to download (but not install) a package, including its dependencies. If you use the --verbose flag, Homebrew will tell you where it downloaded each of the files.
If you haven't used --verbose and still want to know where the downloaded files are: brew deps <formula> will list all the packages it depends on. If a package needs to be compiled, you may need to also use the --include-build option. brew --cache <formula> will show you where a package file is downloaded.
If you need to copy a package file to another computer, you should find out where the Homebrew would expect to find it: use brew --cache --force-bottle <formula> on the target computer, and copy the package file there. Don't forget to do that for each dependency package as well.
After that, brew install <formula> will install from cache.
The only part of this process that needs internet connection is the first step, brew fetch.
For Unix (which MacOS is a family member) and Unix-like (eg. Linux) operating systems the thing that controls this feature is the PATH environment variable.
To know which folders allow you to run programs without cd-ing into them or prefix ./ to your program name you can print out the value of PATH:
echo $PATH
On my machine it prints out:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/slebetman/bin:/opt/homebrew/bin
There are two things to notice:
The string is a list of folder paths separated by :
There is a path listed as /opt/homebrew. Presumably this is where homebrew installs command-line programs.
Copying your program/script into any of the folders listed in PATH will allow you to use it like any installed/built-in command. This is what it means to install command-line programs on Unix. It's that simple.
There is another thing to notice: I have in my PATH the folder /Users/slebetman/bin. This is my own personal standard - probably not invented by me but one I adopted from my college days - for installing my own programs. I have this ~/bin folder on all my Unix and Linux machines. It is where I keep my personal collection of scripts that I've written or collected over a lifetime.
Having a personal ~/bin folder is nice because you don't need sudo permission to write to it. Also, if you buy a new PC/Mac you can just copy the folder to your new machine and all the scripts you've gotten used to now exist on the new machine. Better yet, you can manage the folder with git and sync it with github/gitlab/bitbucket to make it easy to keep all your computers updated.
Since PATH is a standard environment variable you can easily modify it to add your own folder. Just add the following in your .profile or .zshrc or .bashrc file (depending on your shell) to add your own bin folder to PATH:
export PATH=$PATH:$HOME/bin
The command above simply says add $HOME/bin to PATH and export it so that other programs will inherit the new PATH variable.
In your case you can even do something like:
export PATH=$PATH:/path/to/your/sdcc/bin
to have all your SDCC commands work like regular commands.
I previously had Conda running smoothly on Mojave, but I've found that the upgrade to Catalina moves the "anaconda3" folder to your Desktop > Relocated Items > Security > anaconda3. It seems Catalina's security settings may not allow applications to install directly under the user directory anymore.
I tried the suggestion here, written below:
Hi, I might have a solution
Copy the folder anaconda3 located in Relocated Items to /Users/myname/
Open Terminal
Enter: export PATH=''/Users/myname/anaconda3/bin:$PATH"
Enter: conda init zsh
It worked! Good luck!
But this doesn't work for me. After conda init zsh I get:
-bash: /Users/USER/anaconda3/bin/conda: /anaconda3/bin/python: bad interpreter: No such file or directory
How can I get Conda up and running again without losing all my virtual environments? Thanks!
Update
I got Conda to work following #Ted Shaowang's suggestion. This means that conda env list shows all the virtual environments created via Conda.
However I am still experiencing an issue with virtualenv as since I changed the default anaconda3 file locations, python cannot be found.
The python executable located at .virtualenvs/env/bin/python cannot be found. Do I need to make further changes in order for python to work from virtualenv too?
I have the exact same problem and this works for me:
After you move anaconda from "Relocated Items" to ~/anaconda3, edit the first line of ~/anaconda3/bin/conda file from #!/anaconda3/bin/python to #!/Users/USERNAME/anaconda3/bin/python to reflect the change.
I would probably abstain from using the above solution. That ~/anaconda3/bin directory has lots of runnables (not just the conda one) that would need to be altered in this manual way. For example, unless you make the same change you cannot run jupyter notebook either, neither from base nor from other envs you might have.
My tip: Try getting a requirements file for your virtual envs, and do a fresh installation. You could use pipreqs to get the requirements used for individual projects: https://www.idiotinside.com/2015/05/10/python-auto-generate-requirements-txt/
No solution will be completely working without fixing the baked-in hard-coded prefix entries in files. There's a longer description and a recommended fix at https://www.anaconda.com/how-to-restore-anaconda-after-macos-catalina-update/
Technically this is reinstalling anaconda, however, I restored all my conda envs so, hopefully this is an acceptable solution!
Here is how I got it working on Catalina as of a few minutes ago (now using z-shell):
- Verified the existence of "Relocated Items" directory on my desktop and the "anaconda3" directory and its contents inside
- Navigated into the envs directory under "anaconda3" and left the finder window open (see screenshot)
THEN:
opened new Terminal (z-shell)
ran (this installed to /usr/local/anaconda3):
brew cask install anaconda
after installation was successful I opened my ~/.zshrc file (for my z-shell aliases) and added the following line:
export PATH="/usr/local/anaconda3/bin:$PATH"
saved my ~/.zshrc file, then reloaded with:
source ~/.zshrc
to verify conda command works now, I ran:
conda env list
for me, this showed a base env and that was it
then open Finder to the new envs location:
open /usr/local/anaconda3/envs/.
I dragged (moved) all my old envs into the new envs folder, and then ran:
conda env list
And all my old envs are back! :)
updated my PyCharm interpreter / env paths to reflect the new locations of these envs (had to restart PyCharm after, but now it works!)
DONE
Unsure whether this is considered a comment or at least a temporary answer, but I would refrain from attempting to fix any Catalina compatibility issues with Anaconda for now. See this GitHub issue.
I have the same problem, and this work for me :
My solution:
Copy your anaconda3 from Relocated Items folder
Paste in User/YourUserName
Open conda file in anaconda3/bin with the editor and edit the first line #!/anaconda3/bin/python to #!/Users/YourUserName/anaconda3/bin/python
Save it and run conda file
Open Terminal
Run this : export PATH=''/Users/YourUserName/anaconda3/bin:$PATH"
Run conda init zsh
I had incurred the same issue, and the following solution worked for me, and this is the easiest solution:
Instead of messing around copying the anaconda3 file from relocated items into User/USERNAME directory, better would be just to reinstall anaconda navigator's latest version from its official website : https://www.anaconda.com/distribution/#macos
While installation, it will ask you some permissions which are a result of new Apple Security Policies, just grant them, and it works just the way it should after this fresh installation!
This is what worked for me.
These are my header files (Catalina 10.15):
/Library/Developer/CommandLineTools/usr/include/c++/v1/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/stdio.h
Run sudo find /Library -name stdio.h to see where yours are located.
Mojave 10.14 header files:
$ sudo find /Library -name stdio.h
/Library/Developer/CommandLineTools/usr/include/c++/v1/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/stdio.h
As can be seen the SDKs are now split into MACOSX10.14 and 10.15 unlike in Mojave.
TLDR
So, these were my SDK folders on Catalina:
Rename MacOSX.sdk to MacOSX_orig.sdk
Right click on MacOSX10.14.sdk
Duplicate
Rename duplicate folder to MacOSX.sdk
Your folder structure should now look like this:
Like this we are basically using the previous version's OSX sdk as sysroot. Hope this helps.
After I use :
brew install go
Installed my Go in my mac, and it give a Summary:
==> Summary
🍺 /usr/local/Cellar/go/1.8.1: 7,030 files, 281.8MB
But in my finder I can not find the local directory.
How to find my installed Go library in my mac?
All threads like this one point out that:
This directory is hidden as it's a system directory and users have no need to change anything in it.
To expose it in finder enter commandshiftg in finder and in the resulting popup enter
/usr/local
You can get the prefix of any Homebrew formula with brew --prefix <formula>. Even if the formula isn’t installed it’ll show where it’d be if it were.
$ brew --prefix go
/usr/local/opt/go
You can open any directory in the Finder from your terminal using open, so all you have to do is:
open $(brew --prefix go)
Please look at this https://discussions.apple.com/thread/5418731?tstart=0
Choose Go to Folder from the Finder's Go menu and provide /usr/local/ as the path.
One thing that should be noted is that, based on the attached image, you were looking in your /User folder which is not the same as /usr.
After updating to mac os x sierra my cvs (yes I am still using cvs) repository is no longer accessible from remote computer. I can still access the cvs commands on local machine using terminal window, using:
CVSROOT=/usr/local/cvsrep
although if I define the cvs variables with
export CVS_RSH=ssh
export CVSROOT=:ext:twarren#tw-imac.local/usr/local/cvsrep
it also does not work, giving error message:
tw-imac:testcvs twarren$ cvs version
Client: Concurrent Versions System (CVS) 1.12.13 (client/server)
Password:
bash: cvs: command not found
The cvs program is installed in /usr/local/bin (which is on the PATH). It is the old version of cvs that used to come with mac os x and has worked fine with newer versions of mac os x until sierra.
I've just faced this same issue.
ie, remote cvs checkouts don't work.
ie, cvs -z3 -d:ext:<user>#<cvs-server-ip>:<CVSROOT> co -P -r <REVISION> <MODULE> results in cvs: bad command
There are three problems,
cvs was removed back in 10.9
cvs over ssh relies on the sshd PATH support, which is hard-coded
/usr/bin is rootless, ie read-only.
You solve the first problem by installing cvs with homebrew
Install homebrew see: https://brew.sh
then brew install cvs
The next problem, is that when you try to run cvs:ext, you find the PATH is not right, this can be tested like so:
ssh <user>#cvs-sever-ip env | grep PATH
You will see, PATH=/usr/bin:/bin:/usr/sbin:/sbin, which is the sshd non-interactive hard-coded path. For non-interactive ssh, as used by CVS to access the homebrew cvs install (installed into `/usr/local/bin/cvs) you need to add /usr/local/bin to the sshd path. AFAICT this can't be done... non-trivially... as such, the best solution is to make a sybolic link in the /usr/bin directory.
sudo ln -s /usr/local/bin/cvs /usr/bin/cvs
Which leads to the third problem. It doesn't work, because /usr/bin is rootless... and thus read-only.
You could disable rootless mode in recovery mode... and then do it, and then re-enable it.
But the simplest solution is to reboot into Recovery mode, enter the terminal, then cd /Volumes, then navigate to the the /usr/bin directory on your boot volume, ie cd /Volumes/<bootvolume>/usr/bin
then run the command:
ln -s /usr/local/bin/cvs cvs
This will create a symbolic link from /usr/bin/cvs -> /usr/local/bin/cvs
Reboot back to your OS, and that should fix it.
You can verify this with
ssh <user>#<cvs-server-ip> which cvs
which should return :
/usr/bin/cvs
And now your remote cvs checkouts should work...
so I found a way to get cvs to work on sierra. The problem seemed to be that the /usr/local/bin directory was no longer on the path of the shell started by ssh. So the solution consisted of copying the cvs executable to /usr/bin
However, in order to accomplish this on Sierra I had to temporarily disable SIP. This was done by:
reboot with recovery mode
run terminal utility
execute: csrutil disable
reboot
Then I could copy the cvs program. After verifying that it worked properly, I repeated the steps 1-4, except using: csrutil enable in step 3.
NOTE: there will probably be cases where updates to Sierra might replace /usr/bin contents, so it's possible that this process will need to be repeated after updates. To aid in this, I copied the cvs module rather than moving it, so it will still be available in its old location.
NOTE 2: I agree with those who recommend using git rather than cvs and will do that with all new projects. In addition I will eventually also convert existing projects to git where feasible, but am glad that I can still use cvs as before Sierra.
I have MacVim installed and I am trying to set it up as the editor for Git (version control), but I can't run 'mvim' from the command line as it isn't recognised. How do I setup mvim so I can run it from Terminal?
I don't think I'd to add anything to the path, did
brew install macvim
mvim -v
should then open macvim in the terminal, you can also go ahead and alias that
alias vim='mvim -v'
There should be a script named mvim in the root of the .bz2 file. Copy this somewhere into your $PATH ( /usr/local/bin would be good ) and you should be sorted.
If you go the brew route, the best way to install would be:
brew install macvim --with-override-system-vim
That will provide mvim, vim, vi, view, etc. in /usr/local/bin (all symlinked to the copy in the Cellar). This also removes the need to create any aliases and also changes your vi, vim, etc. to all use the same Vim distribution as your MacVim.
In addition, if you want to use MacVim (or GVim) as $VISUAL or $EDITOR, you should be aware that by default MacVim will fork a new process from the parent, resulting in the MacVim return value not reaching the parent process. This may confuse other applications, but Git seems to check the status of a temporary commit message file, which bypasses this limitation. In general, it is a good practice to export VISUAL='mvim -f' to ensure MacVim will not fork a new process when called, which should give you what you want when using it with your shell environment.
If you already have macVim installed: /Applications/MacVim.app/Contents/MacOS/Vim -g will give you macVim GUI.
just add an alias.
i use gvim because that is what i use on linux for gnome-vim.
alias gvim='/Applications/MacVim.app/Contents/MacOS/Vim -g'
Assume MacVim is installed in the Application folder.
Instead of adding MacVim path to your environment, create a link by typing this in terminal:
sudo ln -s /Applications/MacVim.app/Contents/bin/mvim /usr/local/bin/mvim
Then, open a new terminal window/tab and type mvim.
If you have homeBrew installed, this is all you have to do:
brew install macvim
brew linkapps
Then type mvim in your terminal to run MacVim.
Here's what I did:
After building Macvim I copied mvim to one of my $PATH destinations (In this case I chose /usr/local/bin)
cp -v [MacVim_source_folder]/src/MacVim/mvim /usr/local/bin
Then when you invoke mvim it is now recognised but there is an annoying thing. It opens the visual MacVim window, not the one in terminal. To do that, you have to invoke
mvim -v
To make sure every time you call mvim you don't have to remember to add the '-v' you can create an alias:
alias mvim='mvim -v'
However, this alias will only persist for this session of the Terminal. To have this alias executed every time you open a Terminal window, you have to include it in your .profile
The .profile should be in your home directory. If it's not, create it.
cd ~
mvim -v .profile
include the alias command in there and save it.
That's it.
I'm adding Bard Park's comment here for that was the real answer for me:
Since mvim is simply a shell script, you can download it directly from the MacVim source at GitHub here: http://raw.github.com/b4winckler/macvim/master/src/MacVim/mvim
I'd seriously recommend installing MacVim via MacPorts (sudo port install MacVim).
When installed, MacPorts automatically updates your profile to include /opt/local/bin in your path, and so when mvim is installed as /opt/local/bin/mvim during the install of MacVim you'll find it ready to use straight away.
When you install the MacVim port the MacVim.app bundle is installed in /Applications/MacPorts for you too.
A good thing about going the MacPorts route is that you'll also be able to install git too (sudo port install git-core) and many many other ports. Highly recommended.
This works for me:
λ brew link --overwrite macvim
Linking /usr/local/Cellar/macvim/8.0-146_1... 12 symlinks created
For Mac .app bundles, you should install them via cask, if available, as using symlinks can cause issues. You may even get the following warning if you brew linkapps:
Unfortunately brew linkapps cannot behave nicely with e.g. Spotlight using
either aliases or symlinks and Homebrew formulae do not build "proper" .app
bundles that can be relocated. Instead, please consider using brew cask and
migrate formulae using .apps to casks.
For MacVim, you can install with:
brew cask install macvim
You should then be able to launch MacVim like you do any other macOS app, including mvim or open -a MacVim from a terminal session.
UPDATE: A bit of clarification about brew and brew cask. In a nutshell, brew handles software at the unix level, whereas brew cask extends the functionality of brew into the macOS domain for additional functionality such as handling the location of macOS app bundles. Remember that brew is also implemented on Linux so it makes sense to have this division. There are other resources that explain the difference in more detail, such as What is the difference between brew and brew cask?
so I won't say much more here.