[comp.sys.apollo] TERM Variable at 10.3

rfh3273@galileo.rtn.ca.boeing.com (Dick Harrigill) (01/31/91)

If you are making use of the environmental variable TERM, beware.

At 10.3 this variable is always "apollo".  It is no longer set
to a function of the screen type (e.g. apollo_1280_bw).

If you use TERM, I suggest initializing it yourself in the
system startup scripts or RC files.

This bothers me.  Sure there are preferred ways to find out what
type of screen you are using; but like it or not there are many
scripts and programs that look at this variable.  This is another
case of HPs continued lack of compatibility between OS releases.

-----------------------------------------------------------------

-- 
Dick Harrigill, an independent voice from:     Boeing Commercial Airplanes 
M/S 9R-49  PO BOX 3707                       Renton Avionics/Flight Systems
Seattle, WA  91824                                  Computing Support
(206) 393-9539     rfh3273@galileo.rtn.ca.boeing.com

rfh3273@galileo.rtn.ca.boeing.com (Dick Harrigill) (02/05/91)

I posted a notice last week about the TERM variable:

>  At 10.3 this variable is always "apollo".  It is no longer set
>  to a function of the screen type (e.g. apollo_1280_bw).

I have since received several mail messages, most stating that they have
not experienced this at their own site.  This is interesting because the
TERM variable was indeed reset on my ring using 19"bw (1280bw), 330s (19l), 
and 15" color (19l).  I am using the identacal .RC and startup files that
I used with 10.2, so I can't trace it to something I have done differently.

Before making this post, I called the HP 800-2APOLLO hotline. 
The person I spoke with (I believe Hal Jones??) apparently tried 
this on several HP machines and verbally verfied that this
was indeed the case, and that it seems to have been introduced
at 10.3.  There is, however, obviously something else going on here.
 
Again, I am not advocating that looking at TERM is the best
(or even a good) way to identifiy the screen type.  I am
simply acknowledging the fact that there are programs and
scripts in existance that use this method and may no longer work.

Oh well, this was the first post I did on the usenet; for
me its purpose was mainly to verify whether or not I was
getting out while at the same time expressing an item
of possible interest.  Seems it works....  Thanks for the replies.

 -Dick

-- 
Dick Harrigill, an independent voice from:     Boeing Commercial Airplanes 
M/S 9R-49  PO BOX 3707                       Renton Avionics/Flight Systems
Seattle, WA  91824                                  Computing Support
(206) 393-9539     rfh3273@galileo.rtn.ca.boeing.com

rees@pisa.ifs.umich.edu (Jim Rees) (02/06/91)

In article <262@galileo.rtn.ca.boeing.com>, rfh3273@galileo.rtn.ca.boeing.com (Dick Harrigill) writes:

  I posted a notice last week about the TERM variable:
  >  At 10.3 this variable is always "apollo".  It is no longer set
  >  to a function of the screen type (e.g. apollo_1280_bw).
  I have since received several mail messages, most stating that they have
  not experienced this at their own site.  This is interesting because the
  TERM variable was indeed reset on my ring using 19"bw (1280bw), 330s (19l), 
  and 15" color (19l).  I am using the identacal [sic] .RC and startup files that
  I used with 10.2, so I can't trace it to something I have done differently.

Maybe that's your problem.  The startup files change from release to release,
and what you should do is merge any local changes you've made with changes
that Apollo has made.

pato@apollo.HP.COM (Joe Pato) (02/06/91)

In article <262@galileo.rtn.ca.boeing.com>,
rfh3273@galileo.rtn.ca.boeing.com (Dick Harrigill) writes:
|> I posted a notice last week about the TERM variable:
|> 
|> >  At 10.3 this variable is always "apollo".  It is no longer set
|> >  to a function of the screen type (e.g. apollo_1280_bw).
|> 
|> I have since received several mail messages, most stating that they have
|> not experienced this at their own site.  This is interesting because the
|> TERM variable was indeed reset on my ring using 19"bw (1280bw), 330s (19l), 
|> and 15" color (19l).  I am using the identacal .RC and startup files that
|> I used with 10.2, so I can't trace it to something I have done differently.
|> 
 
|> -- 
|> Dick Harrigill, an independent voice from:     Boeing Commercial Airplanes 
|> M/S 9R-49  PO BOX 3707                       Renton Avionics/Flight Systems
|> Seattle, WA  91824                                  Computing Support
|> (206) 393-9539     rfh3273@galileo.rtn.ca.boeing.com

The TERM variable is controlled by the entry in the /etc/ttys file.  If
you look at this file you will probably find that the "term" entry for the
display is set to "apollo".  This is the default setting we send out with
every machine.  You should edit this entry to correspond to the display
type attached to the machine.

                    -- Joe Pato
                       Cooperative Computing Division
                       Hewlett-Packard Company
                       pato@apollo.hp.com

rees@pisa.ifs.umich.edu (Jim Rees) (02/07/91)

In article <4fa32e87.20b6d@apollo.HP.COM>, pato@apollo.HP.COM (Joe Pato) writes:

  The TERM variable is controlled by the entry in the /etc/ttys file.  If
  you look at this file you will probably find that the "term" entry for the
  display is set to "apollo".  This is the default setting we send out with
  every machine.  You should edit this entry to correspond to the display
  type attached to the machine.

I've never changed /etc/ttys, and mine lists the display type as 'apollo'. 
But when I log in my TERM is set to the display type that I have.  This is
done in the pm at process creation time.  But if you have a display type
that was invented after April 7, 1987, your TERM will just be "apollo."

I happen to think this is reasonable, although it could be better
documented.

pato@apollo.HP.COM (Joe Pato) (02/08/91)

In article <4fa7e183.1bc5b@pisa.ifs.umich.edu>, rees@pisa.ifs.umich.edu
(Jim Rees) writes:
|> In article <4fa32e87.20b6d@apollo.HP.COM>, pato@apollo.HP.COM (Joe
Pato) writes:
|> 
|>   The TERM variable is controlled by the entry in the /etc/ttys file.  If
|>   you look at this file you will probably find that the "term" entry for the
|>   display is set to "apollo".  This is the default setting we send out with
|>   every machine.  You should edit this entry to correspond to the display
|>   type attached to the machine.
|> 
|> I've never changed /etc/ttys, and mine lists the display type as 'apollo'. 
|> But when I log in my TERM is set to the display type that I have.  This is
|> done in the pm at process creation time.  But if you have a display type
|> that was invented after April 7, 1987, your TERM will just be "apollo."
|> 
|> I happen to think this is reasonable, although it could be better
|> documented.

Whenever you use /bin/login (e.g., via telnet or in a window or xterm)
the data in the /etc/ttys file will override any info otherwise set by 
the PM.

                    -- Joe Pato
                       Cooperative Computing Division
                       Hewlett-Packard Company
                       pato@apollo.hp.com