ptools broken (after rhel update?)
antares wrote on May 19, 2010
When I try to load ptools, I get the error: "ERROR on line 17: task `tables' has no param file"
Loading tables alone yields the same error.
This is new, I did not change anything in my installation ( NOAO PC-IRAF Revision 2.12.2-EXPORT on a RHEL 5.5 Tikanga). And it worked before that. I even have ptools inside my login.cl.
Could an update have broken this, or do I just not remember any packet dependencies correctly?
(I am pretty new to IRAF and use it only ocassionally.)
Thanks, for any help!
Loading tables alone yields the same error.
This is new, I did not change anything in my installation ( NOAO PC-IRAF Revision 2.12.2-EXPORT on a RHEL 5.5 Tikanga). And it worked before that. I even have ptools inside my login.cl.
Could an update have broken this, or do I just not remember any packet dependencies correctly?
(I am pretty new to IRAF and use it only ocassionally.)
Thanks, for any help!
Mike Fitzpatrick wrote on May 19, 2010
Upgrading the OS would remove any /iraf symlink that might have been created before, and if the path to the TABLES package was /iraf/extern/tables then it may no longer be valid. Regardless, after an upgrade you should re-run the IRAF install script, i.e.
Otherwise, the error means that either the tables source tree does exist, or the path to it is somehow invalid.
% su # become root
# cd /iraf/iraf/unix/hlib # adjust path for your machine
# csh # start a C-shell
# setenv iraf /iraf/iraf/ # set the iraf path in your environment
# ./install # run the script
Otherwise, the error means that either the tables source tree does exist, or the path to it is somehow invalid.
antares wrote on May 19, 2010
Well, it seems like the IT admin who installed iraf on my computer did not a good job and probably either copied it from one host to another or he ignored some serious warnings. I am honestly surprised that I worked so far at all. The install script issued two major warnings and I am trying to troubleshoot them:
1)
no iraf user present -> I created
according to the PC-IRAF V2.12 Installation Guide
2)
File ownership: root dir owned by root, iraf files owned by root
I followed the instructions to correct it. As root, I did
and now I have troubles with the next three steps:
I know that I should have followed: "login as root, set the iraf environment..." but at the moment I am unsure how many environment variables would be needed and with what content (I will read more into the complete installation after I posted this).
If I got it right, the $hbin should be the bin directory in /iraf/iraf/unix.
I find 2 symbolic links there:
which are both pointing to non existent directories!
Is there an easy fix to this?
e.g. I could recreate the symbolic links and point to as.redhat and bin.redhat
and then run the script again. Will that suffice or do I have to start earlier (e.g. redoing the whole installation?)
Well and there is always the chance, that running the install script will acually fix all the symbolic links (is that what you tried to tell me in you post :oops: ?)
1)
no iraf user present -> I created
iraf:x:507:500:IRAF system login:/iraf/iraf/local:/bin/cshaccording to the PC-IRAF V2.12 Installation Guide
2)
File ownership: root dir owned by root, iraf files owned by root
I followed the instructions to correct it. As root, I did
cd /iraf
chown -R iraf.usersand now I have troubles with the next three steps:
cd $hbin # go to HSI bin dir
chown 0 alloc.e # fix alloc.e ownership
chmod 4755 alloc.e # fix permissionsI know that I should have followed: "login as root, set the iraf environment..." but at the moment I am unsure how many environment variables would be needed and with what content (I will read more into the complete installation after I posted this).
If I got it right, the $hbin should be the bin directory in /iraf/iraf/unix.
I find 2 symbolic links there:
lrwxrwxrwx 1 iraf users 10 Dec 16 16:52 as -> as.generic
lrwxrwxrwx 1 iraf users 11 Dec 16 16:52 bin -> bin.genericwhich are both pointing to non existent directories!
Is there an easy fix to this?
e.g. I could recreate the symbolic links and point to as.redhat and bin.redhat
and then run the script again. Will that suffice or do I have to start earlier (e.g. redoing the whole installation?)
Well and there is always the chance, that running the install script will acually fix all the symbolic links (is that what you tried to tell me in you post :oops: ?)
Mike Fitzpatrick wrote on May 19, 2010
The 'iraf' user is not strictly required and in the final v2.15 release will be eliminated. The error messages from the install script shouldn't be fatal (but I think they stop the script in v2.12). In any case, the system links are configured to point to bin.generic by default, the alloc.e is only needed for magtape access so you can ignore it or else explicitly go to the $iraf/unix/bin.redhat directory.
Simply running the install script (as root!) should fix your links, you might try running 'install.old' in the hlib directory to avoid the checks. Be sure though that even after you run it, whatever path you specify to the tables directory is valid on the system, I can't remember e.g. whether install.old creates a default /iraf link, if not you can make it by hand.
Simply running the install script (as root!) should fix your links, you might try running 'install.old' in the hlib directory to avoid the checks. Be sure though that even after you run it, whatever path you specify to the tables directory is valid on the system, I can't remember e.g. whether install.old creates a default /iraf link, if not you can make it by hand.
antares wrote on May 19, 2010
========================================================================
================ Installation Completed With No Errors ===============
========================================================================
which was a good exercise for me, but unfortunately it did not solve the original problem.
I may have looked in the wrong place:
I think TABLES may have never been installed on my system.
And just now (well better late than never) I kind of remember a warning which was pasted in iraf when loading ptools, something about missing tables, but it never prevented ptools from running. So the question is, why now and how to fix it.
================ Installation Completed With No Errors ===============
========================================================================
which was a good exercise for me, but unfortunately it did not solve the original problem.
I may have looked in the wrong place:
and if the path to the TABLES package was /iraf/extern/tables then it may no longer be valid.
ls -l /iraf/extern
drwxr-xr-x 11 iraf users 4096 Apr 2 2007 bck
drwxr-xr-x 18 iraf users 4096 Apr 2 2007 geminiI think TABLES may have never been installed on my system.
And just now (well better late than never) I kind of remember a warning which was pasted in iraf when loading ptools, something about missing tables, but it never prevented ptools from running. So the question is, why now and how to fix it.
Mike Fitzpatrick wrote on May 19, 2010
PTOOLS is in the DIGIPHOT package which has to be manually loaded before it can be used, doing that checks for the TABLES package and prints a warning before continuing. It shouldn't prevent the package from loading if you don't have it, *so long as you don't define TABLES*. Note some tasks may not run, but simply commenting out the TABLES declaration from the hlib$extern.pkg should let it load.
antares wrote on May 19, 2010
I am loading digiphot before that:
I just don't get why it would warn but load ptools the other day, and without intervention stop to work now. The update I did was not even a dist upgrade but only the normal security updates which come normally.
I put # in front of the 2 lines in question and yay, it works again.
To me it seems that human intervention led us there: The lines were clearly commented out by default, later cloned and commented in by someone. Since two more scientists have root access to 'my' machine I can only blame them (or me having amnesia?).
I guess this resolves the issue!
Please excuse my ignorance, but I am still unsure whether my installation is okay.
Some basic information about what I find where, please let me know if something is utterly weird!
irafbin holds 2 dirs (both non empty): bin.redhat and noao.bin.redhat
And thank you very much for all your effort! Is was very helpful and is much appreciated!
# List any packages you want loaded at login time, ONE PER LINE.
images # general image operators
plot # graphics tasks
dataio # data conversions, import export
lists # list processing
# The if(deftask...) is needed for V2.9 compatibility.
if (deftask ("proto"))
proto # prototype or ad hoc tasks
tv # image display
utilities # miscellaneous utilities
noao # optical astronomy packages
digiphot # added by me
apphot # added by me
imred # added by me
ccdred # added by me
nproto # added by me
crutil # added by me
#ptools # added by me, stopped working, reason unclearI just don't get why it would warn but load ptools the other day, and without intervention stop to work now. The update I did was not even a dist upgrade but only the normal security updates which come normally.
*so long as you don't define TABLES* (...) simply commenting out the TABLES declaration from the hlib$extern.pkg
locate extern.pkg
/usr/local/IRAF/iraf/unix/hlib/extern.pkg
/usr/local/IRAF/iraf/unix/hlib/extern.pkg.NOAO
/usr/local/IRAF/iraf/unix/hlib/extern.pkg.bad
/usr/local.old/IRAF/iraf/unix/hlib/extern.pkg
/usr/local.old/IRAF/iraf/unix/hlib/extern.pkg.NOAO
/usr/local.old/IRAF/iraf/unix/hlib/extern.pkg.bad
less /usr/local/IRAF/iraf/unix/hlib/extern.pkg:
# External (non core-system) packages. To install a new package, add the
# two statements to define the package root directory and package task,
# then add the package helpdb to the `helpdb' list.
reset noao = iraf$noao/
task noao.pkg = noao$noao.cl
#reset tables = /iraf/extern/tables/
#task tables.pkg = tables$tables.cl
reset tables = /usr/local/tables/
task tables.pkg = tables$tables.cl
reset stsdas = /usr/local/stsdas/
task stsdas.pkg = stsdas$stsdas.cl
reset rvsao = /usr/local/rvsao/
task rvsao.pkg = rvsao$rvsao.cl
reset gemini = /usr/local/IRAF/extern/gemini/
task gemini.pkg = gemini$gemini.cl
reset helpdb = "lib$helpdb.mip\
,noao$lib/helpdb.mip\
,tables$lib/helpdb.mip\
,stsdas$lib/helpdb.mip\
,rvsao$lib/helpdb.mip\
,gemini$lib/helpdb.mip\
"
keepI put # in front of the 2 lines in question and yay, it works again.
To me it seems that human intervention led us there: The lines were clearly commented out by default, later cloned and commented in by someone. Since two more scientists have root access to 'my' machine I can only blame them (or me having amnesia?).
I guess this resolves the issue!
Please excuse my ignorance, but I am still unsure whether my installation is okay.
Some basic information about what I find where, please let me know if something is utterly weird!
cd /
ls -l iraf:
lrwxrwxrwx 1 root root 15 Dec 16 17:03 iraf -> /usr/local/IRAF
ls-l /usr/local/IRAF:
drwxr-xr-x 4 iraf users 4096 Apr 2 2007 extern
-rw-r--r-- 1 iraf users 35041280 Apr 2 2007 gemini_v19.tar
drwxr-xr-x 13 iraf users 4096 May 19 17:58 iraf
drwxr-xr-x 4 iraf users 4096 Sep 12 2006 irafbinirafbin holds 2 dirs (both non empty): bin.redhat and noao.bin.redhat
cd /usr/local/IRAF/iraf
ls -l:
lrwxrwxrwx 1 iraf users 11 Dec 16 16:52 bin -> bin.generic
lrwxrwxrwx 1 iraf users 22 Dec 16 16:52 bin.freebsd -> ../irafbin/bin.freebsd
drwxr-xr-x 2 iraf users 4096 Sep 12 2006 bin.generic (is empty)
lrwxrwxrwx 1 iraf users 20 Dec 16 16:52 bin.linux -> ../irafbin/bin.linux
lrwxrwxrwx 1 iraf users 23 Dec 16 16:52 bin.linuxppc -> ../irafbin/bin.linuxppc
lrwxrwxrwx 1 iraf users 21 Dec 16 16:52 bin.macosx -> ../irafbin/bin.macosx
lrwxrwxrwx 1 iraf users 21 Dec 16 16:52 bin.redhat -> ../irafbin/bin.redhat
lrwxrwxrwx 1 iraf users 20 Dec 16 16:52 bin.sunos -> ../irafbin/bin.sunos
lrwxrwxrwx 1 iraf users 19 Dec 16 16:52 bin.suse -> ../irafbin/bin.suse
drwxr-xr-x 2 iraf users 4096 Dec 16 17:03 dev
drwxr-xr-x 3 iraf users 4096 Sep 12 2006 doc
-rw-r--r-- 1 iraf users 0 Jul 22 1995 HS.PCIX.GEN
drwxrwxrwx 3 iraf users 4096 Sep 12 2006 imdirs
-rw-r--r-- 1 iraf users 0 Jul 14 2002 IS.PORT.GEN
drwxr-xr-x 5 iraf users 4096 Dec 4 2006 lib
drwx------ 11 iraf users 4096 Sep 12 2006 local
drwxr-xr-x 14 iraf users 4096 Sep 12 2006 math
-rw-r--r-- 1 iraf users 7373 Feb 2 2004 mkpkg
drwxr-xr-x 20 iraf users 4096 Sep 12 2006 noao
drwxr-xr-x 16 iraf users 4096 Oct 11 2006 pkg
drwxr-xr-x 26 iraf users 4096 Dec 4 2006 sys
-rw-r--r-- 1 iraf users 198289 Jan 19 1995 tags
drwxr-xr-x 34 iraf users 4096 Sep 12 2006 unixAnd thank you very much for all your effort! Is was very helpful and is much appreciated!
Mike Fitzpatrick wrote on May 19, 2010
The information about your installation all looks fine, you just need to sort out whether TABLES (if it exists) is in /iraf/extern/tables or /usr/local/tables
antares wrote on May 19, 2010
It is not installed and I think that's okay for now as I need ptools mainly for 'txdump'-ing information.
I will probably soon look into installing a more recent version of IRAF (since I read most of the install guides by now) and hope to get maybe around issues like non working backspace key 8). But there is no rush, and if you tell me, that RHEL 5.5 goes better with 2.12 than any newer version, I would not consider to change then. (How stable is the alpha release?)
BTW: Can two installation in two different roots coexist?
I will probably soon look into installing a more recent version of IRAF (since I read most of the install guides by now) and hope to get maybe around issues like non working backspace key 8). But there is no rush, and if you tell me, that RHEL 5.5 goes better with 2.12 than any newer version, I would not consider to change then. (How stable is the alpha release?)
BTW: Can two installation in two different roots coexist?
Mike Fitzpatrick wrote on May 19, 2010
IRAF V2.13 set the ECL as the default, this is an enhanced CL that will 'fix' your backspace issue (and up-arrow history, and error-trapping in the CL). In v2.12 you can install ECL as an add-on but I'd suggest upgrading instead.
The v2.15 release is actually pretty stable for an 'alpha' release, if you want solid then the v2.14 is recommended. Multiple version can co-exist but you have to play games with paths or environment variables so the 'cl' command brings up the desired version, or that you compile external packages against a specific version. It's not really a newbie thing but it can be done.
The v2.15 release is actually pretty stable for an 'alpha' release, if you want solid then the v2.14 is recommended. Multiple version can co-exist but you have to play games with paths or environment variables so the 'cl' command brings up the desired version, or that you compile external packages against a specific version. It's not really a newbie thing but it can be done.
Last post on May 19, 2010