As an example, Safari was able to stream videos through AirPlay with Apple TV without showing the entire web page on the TV screen. Then when prompted whether the copy of IRAF if to be installed as the "root user", type "no" as opposed to the default setting.The original release of El Capitan through Mac Apps Store already had the new features of Notes, Spotlight, Photos, and Safari compared to the last OS X version Yosemite. So if one follows the installation instructions on the IAC webpage at the URL:, the only departure from the stated that needs to be effected comes in the second bullet point where the option "-system" should be intentionally omitted, so that the desired command now reads "sudo /iraf/iraf/install". This is because as long as the package is unpacked at root while the IRAF is installed for only the current Mac user and not at the root level, the install script would not run into the missing "iraf.h" issue. There is no need to use drastic means and resort to turn off SIP altogether. I worked around this IRAF Mac-OS-specific legacy problem surrounding Apple Inc.'s so-called "rootless" feature, or more properly the System Integrity Protection (SIP), for post El Capitan or 10.11+ OS systems for Mac using user "forgetting_iraf"'s method with macOS Sierra running on my laptop as well. I could then 'mkiraf' and run 'cl' without a problem. At that point the installation program decided to put the copy of iraf in my home directory, and I didn't run into the problems with /usr/include. When it asked me if I was running it as a superuser, I answered 'no', even if I had used the 'sudo' command. I ran 'sudo /iraf/iraf/install' without the -system option. * I used to use 0圎D but it doesn't appear to work properly in El Cap. I've only run it so far with stsdas, onesdspec, and splot so it is quite possible there are other hard coded links in vocl.e that need hacking. The next step was to do a similar thing to the executable vocl.e, located in /iraf/iraf/bin.macintel/ Here I needed to change the link to iraf.h from '/usr/include/iraf.h' to '/opt/include/iraf.h' This then needed a 'sudo mkdir /opt/include/' and a symbolic link in the new directory to the actual file: 'sudo ln -sf /iraf/iraf/unic/hlib/libc/iraf.h'Īfter running mkiraf as per the instructions, running 'cl', IRAF runs nicely. The triple slashes are to pad the link length to the original link in case the compiled code looks at a particular file address. An alternative would be to change the link to '///opt/X11' which is where the X11 folder was located from before. The X11 link had been left after the El Cap upgrade. It has about 6 links pointing to /usr/X11R6 After fixing the write permissions (sudo chmod.), I opened the xgterm executable in Hexfiend.app*, and changed all the '/usr/X11R6' to '///usr/X11'. The first was in xgterm, located in /iraf/iraf/vendor/x11iraf/bin.macintel/. I followed the install instructions on, and got error messages pointing to files in illegal locations in El Capitan. I tried changing the permissions of /usr/include using chmod to 777 and then reinstalling, but that still didn't work, as I got the same error message. ln: /usr/include/iraf.h: Operation not permitted This seems to be the only error, since during the installation:Ĭreating symlink. I checked and there is no file called "iraf.h" located inside of /usr/include. Os.zgtenv: cannot open `/usr/include/iraf.h' But when I get to the end and type "cl" to launch IRAF, I receive the following error message: Since those were the only directions that I could understand (and worked for 10.10) the others confused me. I tried to reinstall IRAF following the directions located at: I am in the process of troubleshooting why it's not working. I am in the process of having to reinstall IRAF since upgrading to 10.11 (currently at beta 6) broke my copy of IRAF.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |