>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 199909201508.JAA14368 McIDAS-X documentation
Alan,
>I am setting up another terminal with mcidasx, using solaris for intel.
>The Solaris install went fine, and when creating the mcidas & mcadde
>accounts I noticed a few things that prompted questions.
>
>1. Following the web pages, I stumbled when trying to edit the .chsrc
> account as listed on the web. I assume there is a typo and it
> should read the .cshrc.
This is indeed a typo. I just fixed it.
>2. You will recall your helping us set up our ingest machine, waldo
> with solaris, ldm and mcidasx. I thought I could use waldo's
> .cshrc file as the pattern, but when I looked at it, I see it
> does not necessarily follow the instructions on your web pg.
>
> Specifically, the setenv PATH statement on web is not what is
> on waldo's .cshrc
The setting for PATH will depend on the system. PATH is designed to
be modified by the end user to match his/her setup.
>I have included waldo's .cshrc file below.
> I know some of the difference is required for the netcdf stuff,
> but not sure this explains why my PATH statement is different.
>
> Also, the web sheet tells me via a little table that for solaris2.x,
> I need to add two more directories, is a specific order. I do not
> see the directory /opt/SUNWspro/bin in waldo's .cshrc.
McIDAS was built using the gcc/f2c compiler combination on waldo. Since
you do not have the Sun compilers, you do not need the /opt/SUNWspro/bin
directory in your PATH (that is where the Sun compilers will be found).
>3. NEXT, in creating and editing the home/mcidas/.mcenv file, the 7th
> line, shows a statement PATH=${MCGUI}:... with a later instruction
> that the ... be replaced by directories from the PATH statement.
> When Waldo was set up, I believe you handled some problems for us
> including the .chsrc file. I assumed everything was fixed, it works
> fine.
> Anyway, waldo's .mcenv file still shows the ... , that is the
> directories from PATH do not appear to have been added, yet we do
> not seem to have problems. Can you explain? The .mcenv file is also
> provided below.
This was obviously a oversight on my part. Since I don't know apriori
how a user has his/her system setup, I can not completely specify a
PATH statement that will work for all users.
> The new machine will not be running an ldm, but I am not sure this
> is the reason for the difference (between web instruction page for
> .cshrc and waldo's .cshrc)
No, this is not the reason.
> Could you comment on whether I should stick to just the web example,
> or use the working model, waldo that I already have.
Either will work. Again, since I can't dictate how a site installs
packages, I can't include full, working PATHs. What I can do is give
examples that can be used as examples. An example of the extra verbage
that is needed in order to account for potential differences in
installation is my notes that I will assume that the HOME directory for
the user 'mcidas' will be /home/mcidas and that the user will need to
substitute the actual installation directory name on their system.
Over the years I have gotten a lot of flack for being overly verbose in
my documentation (by giving examples of several different ways of doing
things). As a result of the feedback, I have cut back on commentary so
that one way of doing things is outlined. I will, however, go back
through the web pages looking for ways that I can add a short comment
here or there that will help the user know when s/he needs to do
system-specific modifications.
I should add that some things really do need to be done verbatim. A
good example of this is the entries in .mcenv. A number of sites
have opted to read the docs and then enter the various definitions
"by hand". The most common mistake that is encountered when doing
this is adding a space between the equal signs and sorrounding text.
This is a big no-no since it is not allowed by the Bourne shell
in which the .mcenv file is used.
>Thanks
Thanks for the input. Your comments will help make the documentation
better.
Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.