Re: [foxboro] Unix script question

Why, yes there was a reason I didn't use uname -n.  That reason is
ignorance.  My knowledge of Unix and I/A most closely resembles a
lattice like chicken wire as opposed to a wall of brick - ouch! (It has
been said the confession is good for the soul).

I looked for a terminal variable that I could use by invoking the set
command and GCLBUG came up.  I was a little suspicious when I rlogin'd
to other WPs and could not see the value there.

Anyway, I used the line recommended below and all works as desired.
Thanks to Kevin, William (Bill?), and Jack (forgive me if I am being too
informal) for their helpful and educational information.

Regards to all,

Matt

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Fitzgerrell, Kevin
Sent: Tuesday, May 19, 2009 6:26 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Unix script question

Matt,

While this doesn't answer your question about GCLBUG, is there a reason
you're not using `uname -n` instead?  The name of the computer is
available in many more conditions than a human interface variable.

So, BIT_NO=`uname -n | tr WP BI` will give you the same results, but
work in all shells and environments.

GCLBUG is a human interface variable defined during IA system startup -
you should see it in /usr/fox/wp/data/hiinit.log file.  It is not be
available in all shells and environments unless you've made it available
in a .profile or .cshrc file.  

Regards,

Kevin

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Gunter, Matt
Sent: Wednesday, May 20, 2009 8:48 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Unix script question

I did a search of the Free List archives for GCLBUG for an answer to the
problem below and though I found some entries from 2002 & 2006, they
didn't really get at the dilemma.
 

This is, no doubt, more of a Unix shell question than it is an I/A
question, but since most of our boxes are Solaris the two topics are
integrally tied together.  So, here goes ...

 

I am trying to use the GCLBUG value in a script to identify the machine
that is running the script.  The line in the script where I obtain the
value is as follows:

 

# establish the correct bit number based upon the wp number

BIT_NO=`echo $GCLBUG | tr WP BI`

 

Note that the actual station number is WP00XX.  The above command
returns a bit label of BI00XX.

 

So, if I start a shell (VT100) and run my script, the log file I get
shows that the script worked properly ...

 

+ echo WP0013 

+ tr WP BI 

BIT_NO=BI0013

 

But, whenever I run the script using cpShell or cron, the $GCLBUG value
is not available and I get the following in the log file ...

 

+ echo 

+ tr WP BI 

BIT_NO
 

Since I want to use the returned label to set a Boolean input on a block
in a compound, you can see that I have a problem.

 

I thought that perhaps the problem was one of timing when I was running
the script in a shell started at boot up using cpShell so I tried cron,
thinking it would be immune to any timing issues.  But, as indicated
above, the results are the same.  So, What do I need to do differently
so that the $GCLBUG value is available for my script?

 

Thanks

Matt Gunter

ATK Space Systems


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: