I want to use sqlite with the json extension so I've installed it with homebrew. When I run which sqlite though, the one that is being used is the anaconda install. If I try and use pythons sqlite library I have the same issue. It's linked to the Anaconda version and the JSON functions aren't available. How do I replace this with the brew version? Brew provided some values when I installed sqlite but I don't know if I need them or how they are used.
LDFLAGS: -L/usr/local/opt/sqlite/lib
CPPFLAGS: -I/usr/local/opt/sqlite/include
PKG_CONFIG_PATH: /usr/local/opt/sqlite/lib/pkgconfig
Sqlite installed by Homebrew is keg-only, which is not linked to /usr/local/... .
This is because system already have older version of sqlite3.
If you really want to invoke Homebrew's sqlite binary, specify full path as below.
$ /usr/local/opt/sqlite/bin/sqlite3
(All Homebrew package is symlinked under /usr/local/opt)
I'm not so familiar with python, but AFAIK sqlite is statically linked to python executable.
In other words, maybe you have to build python from source to use with Homebrew's sqlite.
The answer by equal-l2 is correct. Also, the comment under it by Keith John Hutchison.
But, since they are from quite a few years ago and there is not an officially accepted answer still, here you go as this still catches you off-guard in 2022.
To fix, add this to your ~/.zshrc file and you should be good:
export PATH=/usr/local/opt/sqlite/bin:$PATH
Remember to have $PATH at the end like the above and not at the beginning like so:
export PATH=$PATH:/usr/local/opt/sqlite/bin
as the shell traverses your $PATH for command completion left to right and stops at the first instance found and obviously you want your desired path to be considered first.
Also, you might need to run source ~/.zshrc and rehash if you want it to just start working in the same terminal session.
Related
I am trying to run the metal executable from my zsh terminal in order to meta-analyze GWAS data. I have the executable in the correct directory and have checked that it is not 0MB due to truncation.
Reproducible:
Download the Linux file from http://csg.sph.umich.edu/abecasis/metal/download/
In terminal:
PATH TO EXECUTABLE ./metal
zsh: exec format error: ./metal
You probably install wrong OS of go, for example, you might install go for MacOS in Linux
I solve this problem by installing go for correct OS
The executable has been pre-compiled on a certain distribution with libraries at a certain places at certain versions.
If you have a different distribution, libraries versions, it won't work and you better compile from the source.
Basically what you have to do is to download and extract the sources, go in the folder and execute make. (You will have probably to install make first.)
I think that's not your job at all so maybe you can find a geeky person to help you, because you may stumble upon problems, libraries to install, old versions not supported anymore, new versions not supported yet...
It happened to me when I emptied an executable by mistake.
~>true > a
~>wc -c a
0 a
~>./a
zsh: exec format error: ./a
I've searched the web, and I'm still unclear on how to run R from the Mac terminal. I have Rstudio and the standalone R app installed. I thought I could just type "R" from the command line as I do with "python", but that doesn't work. Is it necessary to edit the PATH in my bash profile? If so, how do I give the correct location of R?
Thanks for any help
Edits after receiving comments
So, I'm running Sierra, and when I type "r" or "R" at the terminal, I get "-bash: R: command not found." If I type, "which R" in the terminal I do not get any output.
Here is the output from "echo $PATH": /usr/local/heroku/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Users/samuelcolon/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/samuelcolon/.rvm/gems/ruby-2.1.0/bin:/Users/samuelcolon/.rvm/gems/ruby-2.1.0#global/bin:/Users/samuelcolon/.rvm/rubies/ruby-2.1.0/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/samuelcolon/.rvm/bin:/Users/samuelcolon/.rvm/bin
As for the installation, I believe I downloaded it directly from cran.r-project.org a while ago. I can locate the GUI in my applications and open it--
I have version 3.13. Is it possible, I only have R.app installed but not R? Perhaps that's the reason I'm getting the 'command not found' when typing "R" into the terminal?
Generally, I've been working in RStudio, but I'd still like to access R from the terminal and also to find where things are located. I'm fine with removing and re-installing R if it's easiest to start from square one. I hope the extra detail helps, and I appreciate the responses.
An answer for those not that familiar with Terminal and Bash.
I have done a fresh update install of R from the R.org cran site as part of seeking an answer to your question.
I found this latest install version 3.4.0 installs R for access in Terminal, and also installs R.app as part of the package.
To my understanding, reading support docs, if you have an older version of R it will update that. However it will not update an installation of R installed by the anaconda package.
Where are the R files stored?
I can only assume that with a fresh install of the latest R, R will work for you in Terminal.
To learn where the R files are that are being accessed - in Terminal after starting R, and in R.app, type:
>R.home()
In my case as example:
In R.app - the R version 3.4.0 is accessed in the top directory (not my user folder):
R.home()
[1] "/Library/Frameworks/R.framework/Resources"
In Terminal - the R version 3.3.2 is accessed in the Anaconda package, again in the top level directory.
R.home()
[1] "/anaconda/lib/R"
So I have two different versions of R, and Terminal accesses a different version to R.app.
How can I ensure I access the same version in Terminal as I do in the R.app?
For someone familiar with bash, and how the whole bash command system works I am sure there is a well constructed command. All the same here are some novice solutions.
-
• First Solution:
I could update the anaconda version, however, I would prefer not to as as other elements of the anaconda package my depend on this older version of R. For those not yet familiar with Terminal and bash, not such a novice solution.
-
• Second Solution:
This solution came from mko. It provides a single use solution. From the result above, and checking the directory structure a little further to find this R file.
Finding the significant R file enables me to edit an extension of the above path shown in the R.app. So add /bin/R to enter
/Library/Frameworks/R.framework/Resources/bin/R
Entering and pressing return will start R from this version.
Alternatively, one can find this file and icon in the GUI Finder, lead by the above result, and just double click on it, and it will open Terminal and a session with R running for you. Easy!
One could also make an alias of it and put it on your desktop for easy future starts.
-
• Third Solution:
My last solution I think may be best, adding to mko's solution. Make an alias.
Being in my home directory in Terminal I open .bash_profile using the nano text editor. (If you do not already know how to do this, then best not use this solution.)
I then add the line in this env file.
alias Rv340='/Library/Frameworks/R.framework/Resources/bin/R'
I then save the changes and exit this terminal session. I then open a new Terminal window. (This is so the changes to the env above are incorporated in the new terminal session).
Then when I enter the alias:
Rv340
The version of R I want opens.
You can choose a different alias name to "Rv340".
-
• Fourth Solution:
A second more permanent solution for opening the same version of R in Terminal is as follows.
Copy the path as showing in R.app in response to the R.home() command above, and add that path to PATH in your .bash_profile. (If you do not know already how to do this, then ignore this solution.) Do so as follows.
export PATH="/Library/Frameworks/R.framework/Resources:$PATH"
To my understanding, this ensures that bash looks here for R (and anything else), then moves on to the other paths in PATH. Since this adds this path to the beginning of $PATH, an env variable, bash looks here first where it finds the newer version first, and stops looking.
When it comes to understanding PATH in the env set up in .bash_profile the following two links were helpful.
About PATH.
How to correctly add a path to PATH.
This solution may muck with anaconda's invocation of R. I have yet to check this.
First of all, you have to start terminal application. You can use either built in Terminal.app, or you can use replacement. My favorite one is iTerm2
https://www.iterm2.com
Then, you simply open terminal window and run R. Just like shown below:
Have fun with R!
Just ran into the same issue when installing R-4.0.3.pkg on my MacBook (MacOS BigSur). Can open R.app to the clunky R GUI, but typing in 'R' in terminal doesn't work.
Turns out, an R executable lives here: /Library/Frameworks/R.framework/Versions/4.0/Resources/bin/R
So I added this alias to my newly created .zshrc script:
alias R '/Library/Frameworks/R.framework/Versions/4.0/Resources/bin/R'
Now when I type in R, it opens... I swear this all happened seamlessly in earlier versions.
There is currently a bug in CRAN's R installation package that results in it not correctly installing symbolic links to R and Rscript for commandline use. I've just verified this by inspecting the postflight script in their 4.0.5 installation package. This only impacts MacOS system releases of 20 and above (you can check with uname -r).
I've included more info here, along with what the "correct" fix should be: manually creating symbolic links to /usr/local/bin that point to the R and Rscript binaries themselves. If this is the current challenge, then this would be a far better solution to creating aliases or manipulating PATH in various ways, since it's what the installation package intended to do (and presumably will again soon).
R: command not found
In short, if this is the problem, then Ashkan Mirzaee's answer (https://stackoverflow.com/a/67202173/2093929) to create the symbolic links directly is correct in form, but might not have the right link command. The 4.0.5 package intends instead to use:
mkdir -p /usr/local/bin
cd /usr/local/bin
rm -f R Rscript
ln -s /Library/Frameworks/R.framework/Resources/bin/R .
ln -s /Library/Frameworks/R.framework/Resources/bin/Rscript .
You can create a symbolic link from R and Rscript binaries to /usr/local/bin to add them to the PATH:
sudo ln -s /Library/Frameworks/R.framework/Versions/Current/Resources/bin/R /usr/local/bin
sudo ln -s /Library/Frameworks/R.framework/Versions/Current/Resources/bin/Rscript /usr/local/bin
Now which R should return /usr/local/bin/R and you can use R.
An easy way to open RStudio with admin privilege on macOS:
Go to Applications, then right click on RStudio
Select "Show Package Contents"
Go to Contents/MacOS
Now open terminal(in bash mode). Type sudo and drag the RStudio.exec into terminal and press on ENTER
Now RStudio will have admin access!
I have downloaded and installed R.
I see it here in Applications folder (I am on a Mac with Yosemite):
Fine. I can launch R.app and indeed, yes, I am running the version I want, which is 3.2.2:
So far so good. I can even open up RStudio and see that I am indeed running 3.2.2!
So after all this, I simply go to my terminal, type
r
and turns out I am running 3.1.1!
I understand the old user of my work computer probably had installed this older version.
So here's what I'm wondering:
If I just installed R.app correctly, WHY is this old version still living on my computer, and how do I get rid of it?
If this is some sort of $PATH thing, WHY doesn't the most obvious location for an app, the Applications folder, get checked for the existence of R?
Thanks.
UPDATE
Turns out the old version of R has been installed by homebrew.
Typing which r in your terminal will give you where the shell thinks R is. Then, you need only uninstall it from that location.
Since we've determined it's homebrew, all you need to do now is brew unlink r; rm -Rf /usr/local/Cellar/r/3.1.1 and you should be golden after you rehash in your shell.
It worked because you installed it using homebrew. To remove it from the system, you must first unlink it and then remove it from the system.
I downloaded GNAT ADA GPL 2014 and now trying to install on my Mac.
The directions below are the ones I am following, but I do not know where to look to find the file called doinstall. I might still need some help after finding it, but can anyone help me out here?
Navigate to the directory that contains a file called: doinstall
Enter: sudo mkdir /usr/local/gnat
Enter: sudo ./doinstall
Update your path as needed for your shell
You should have downloaded gnat-gpl-2014-x86_64-darwin-bin.tar.gz.
Go to some temporary directory (I use ~/tmp):
cd ~/tmp
Unpack the download, which creates a directory gnat-gpl-2014-x86_64-darwin-bin containing the binary distribution to be installed:
tar zxvf ~/Downloads/gnat-gpl-2014-x86_64-darwin-bin.tar.gz
Enter that directory, which contains (amongst others) doinstall:
cd gnat-gpl-2014-x86_64-darwin-bin
Execute doinstall to enter the installation dialog:
sudo ./doinstall
Remove the unpacked download:
cd ..
rm -rf gnat-gpl-2014-x86_64-darwin-bin
Now you can update PATH as needed for your shell.
What Simon Wright said is correct, but if you're running on Yosemite there's an extra problem: for some obscure reason, Adacore GNAT is broken on Yosemite. You have to make it think it's compiling for Mavericks:
export MACOSX_DEPLOYMENT_TARGET=10.9 # Yosemite workaround
That can go in a few different places, but I put it near the top of the /usr/local/gnat/bin/gps script so it doesn't interfere with the xcodebuild environment.
Also, I found GTKAda to be nearly impossible to install from source; if you download the XNAdaLib-GPL package from http://sourceforge.net/projects/gnuada/ you can install that and get everything you need without having to wade through Adacore's mess. (You may want to use the Adacore version of Glade for GUI design though; for some reason the Sourceforge package's version is localized in French and I'm not sure if it can be switched to English.)
Finally, since this is a bit duct-tape-and-baling-wire, I would recommend not shipping any production mission-critical code with this environment; either roll back to Mavericks or wait for GNAT 2015.
I'm trying to use the SOUNDEX function with SQLite. Can I install this with homebrew, or do I need to compile from source?
I've tried
brew install --fresh sqlite --with-functions
which seems to install extension functions, but I still get Error: no such function: SOUNDEX messages on my queries.
I also tried to modify the sqlite formula, adding the following compile option
ENV.append 'CPPFLAGS', "-DSQLITE_SOUNDEX"
based on http://www.sqlite.org/lang_corefunc.html, but this still fails.
Ideally I'd like to avoid compiling SQLite manually from source, even if that means I need to write a custom homebrew formula.
That's the right flag, but you might not be running the right sqlite.
Your approach is correct. Adding that ENV.append 'CPPFLAGS', "-DSQLITE_SOUNDEX" will compile it with soundex. I just tested it with SQLite 3.7.16.2 and homebrew on my OS X 10.8.3 system. Or, for more control, like this.
option 'with-soundex', 'Enable the SOUNDEX function'
def install
[ ... ]
ENV.append 'CPPFLAGS', "-DSQLITE_SOUNDEX" if build.include? "with-soundex"
Are you sure you're calling the right sqlite3 program once it's installed? SQLite is a "keg-only" formula; that is, unlike most homebrew formulas, it does not get linked in to /usr/local/bin, to avoid conflicting with the sqlite supplied with OS X. You need to call the homebrew one with the full path, like /usr/local/Cellar/sqlite/3.7.16.2/bin/sqlite3.
$ /usr/local/Cellar/sqlite/3.7.16.2/bin/sqlite3
SQLite version 3.7.16.2 2013-04-12 11:52:43
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select soundex('Hello, world!');
H464
It would be easy to add a --with-soundex option to the main homebrew sqlite formula, so you don't have to maintain a separate formula. If you think enough people would use it, head on over to the Homebrew issue tracker on GitHub and put in a request for it.