It may be trivial question, but I'm looking over the internet and SO about namei in macos. I can't find it on Yosemite, also homebrew doesn't contains such package to install. From what I was searching, MacPorts doesn't have it neither. Could some pro developers from MacOs help me or suggest other command that will be able to check for ownership and permissions on a path?
I'm writing this as an answer vs. a comment although I will make a comment first and that is, this doesn't appear to be a question suited to this forum and you might want to ask elsewhere, e.g. Super User.
That said, namei is a part of the util-linux package and as such is not a command normally found under OS X. If it's even possible, you have to download the source code for util-linux and then selectively compile namei and then manually install namei by itself as you would not want to compile and install the entire util-linux package under OS X. I've done similar under OS X with individual utilities of the GNU Core Utilities package however not with the util-linux package.
Related
How in the world do I get rid of Lua on my Macbook Air?
I installed the programming language just to test it out and now I am not sure how to get rid of it.
I used the official Lua website <lua.org> to install it and followed the instructions on the download page using 'curl' or whatever it is.
I am a programming beginner. Other languages, like Java and Python, don't have this issue. Can someone please help me get rid of the annoying thing? I don't need it clogging up my computer.
Lua's Makefile has an uninstall target which should allow you to remove it from your system. cd to the Lua source directory (lua-5.4.3 for the current version) and type this command:
sudo make uninstall
The sudo is required if you need administrative privileges to remove software.
(I'm not familiar with MacOS, but from the comments, it seems to work the same way as it does on GNU systems.)
I have the next problem. I have a .pkg installation package which is quite all, at least older than El Capitan OS. The problem is (after looking on the internet) this .pkg writes some binaries to /usr/bin and that is something not permited in El Capitan OS anymore, it should be written to /usr/local/bin.
I have found two solutions on the internet (well actually three) which are:
-disabling SIP, which is not recomended.
-waiting for someone to redoo the .pkg (i do not want to wait)
-i was thinking in some simbolik link between /usr/bin and /usr/local/bin so when it tries to write to /usr/bin it really writes to /usr/local/bin
-Redoo the .pkg (no idea at all).
Thank for the answers.
You could use a tool like Pacifist to extract the files out of the pkg and copy them into /usr/local/bin yourself. Pacifist will also let you extract any preflight/postflight scripts that the pkg runs so you can run the equivalent setup commands yourself.
I'm learning Ada 95 in my programming class, and I would like to install the gnat compiler on my MacBook. I have no clue as to where to get a good gnat to compile my code, and how to install it.
I currently have gedit as my text editor, because that's what we're using in our lab environment. I'm new to the Mac world so any help would be greatly appreciated.
There's an excellent free Ada compiler for Mac OS X available from AdaCore.
You should be OK with the GNAT GPL edition. Follow the Download link - choose Free Software of Academic Development - at the bottom of the page, follow Build your Download Package.
Select your platform as x86_64-darwin, 2012. Click on GNAT 2012, then on gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz (this contains all you'll need for the moment).
You'll also need Xcode (free with Mac OS X). Pre-Lion, this was (I think) an optional install on the installation DVD. In Lion or ML, you need to get it from the App Store (in ML it's at Categories > Developer Tools > Xcode). In ML, you also need to install the command line tools: open Xcode, then Xcode > Preferences > Downloads > Components, select Install against the Command Line Tools.
I say to install Xcode first, because the GNAT install needs it (you can tell whether the command line tools are installed by saying which make: if the answer comes back blank, they aren't installed). Anyway, for the GNAT install,
$ cd
$ tar zxvf ~/Downloads/gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz
$ cd gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin
$ sudo ./doinstall
You don't need the installer after it's finished, so you can delete it.
The defaults install GNAT under /usr/local/gnat, and you'll need to make sure that /usr/local/gnat/bin is first on your path (at any rate, ahead of /usr/bin). I'd edit ~/.bash_profile_common to add
PATH=/usr/local/gnat/bin:$PATH
but I still have trouble knowing which of the ~/.bash* files do what!
I have OS X Yosemite 10.10.3, and I followed the following steps.
Download GNAT from this place http://libre.adacore.com/download/configurations. Choose Mac OS X as the platform.
Execute the following commands on the terminal:
Unzip or (tar the file downloaded from the previous step, for example, as follows:
tar zxvf gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz
Note: this assumes that you're in the same folder as the file you downloaded in step 1.
cd gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin
sudo ./doinstall
Edit your .bash_profile file under /Users/{YOUR_USER_NAME}/.bash_profile to also have the following line
export PATH=$PATH:/opt/local/bin:/usr/local/gnat/bin
Save the .bash_profile file.
Open a new terminal. You should now be able to execute gnatmake.
The answers here are quite old and are no longer the best options. Command-line only development is quite a pain, especially if you're just starting with the language. The alternative, GNAT Studio IDE, is no longer supported on MacOS X, but still supported on Linux and Windows. No big loss though, since its its a bit clunky, slow and poorly integrates with MacOS.
Fortunately, there's now a VSCode plugin enabling all the major features available in GNAT Studio, such as syntax coloring, debugging and IntelliSense, along with a better overall user interface:
https://marketplace.visualstudio.com/items?itemName=AdaCore.ada
Oddly enough, it's not as well promoted as GNAT Studio. In fact, I discovered this VSCode plugin on a whim after I having difficulty setting up my development environment. The instruction for setting up the plugin is simple. It also has the most succinct and comprehensive installation instructions for the toolchain.
So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.
I'm sure this is a newbie question, but every time I've compiled/dl'ed a new version of vim for os x, running vim on the command-line opens up the gvim app. I just want to upgrade the console version (so I can, for example, have python compiled in to use omnicomplete).
If I understsood the question correcty, here is another solution: check out http://www.andrewvos.com/2011/07/23/upgrading-vim-on-os-x-with-homebrew/
Really simple, fast, painless. It uses homebrew-alt and you also need to have mercurial installed (it will prompt you if not).
You can also use MacPorts to handle the installation for you. Once you've installed it, run the /opt/local/bin/vim binary. I place this in my PATH before the system binary dirs (although be aware that this may cause problems for cmdline tools that rely on the versions of tools shipped with OS X).
This may sound stupid, but are you copying the vim binary to /usr/bin? by default, the "vim" path is /usr/bin/vim. If you compile from source, you'll likely need to either copy the vim binary to /usr/bin/vim (thus overwriting the original vim), or launch the compiled version via absolute path (eg. ~/vim-checkout/build/vim).
that's just a guess, however. I can't see it being anything more than that.
With Homebrew:
brew install macvim
ln -s /usr/local/bin/mvim /usr/local/bin/vim
Can also symlink your new binary to /usr/local/bin/