[comp.sys.pyramid] xterm /dev/tty fix

karl_kleinpaste@cis.ohio-state.edu (09/10/90)

adams@swbatl.sbc.com writes:
   As to the 
   /dev/tty problem that hoses getpass(3) (and pg(1), nastily) I've been
   using the "screen" utility (comp.sources - long ago) to get around
   this problem until our soon to happen upgrade to 5.0.

Upgrading to 5.0 may not help.  When this topic last came up here, the
enclosed article was posted.  We changed our xterm sources to
accommodate, and now we have functional /dev/tty in xterm.  Try it,
you'll like it.  Although this person didn't think the change should
fix xterm, it does, at least under 4.4c.

--karl

    ----------------
From: gprieur@pyramid.pyramid.com (Gordon Prieur)
Newsgroups: comp.sys.pyramid
Subject: Re: Problem porting X11R4 clients to OSx5.0
Date: 9 Aug 90 14:59:53 GMT

In article <BOB.90Aug7091403@volitans.MorningStar.Com> bob@MorningStar.Com (BobSutterfield) writes:
>>>   Just for the record, I've compiled and run the X11R4 xterm with no
>>>   problems (and no major code changes).
>>>
>>Can you say "cat < /dev/tty" and have it wait 'till you type
>>something?  What non-"major code changes" were required?

Yes, I can say "cat < /dev/tty" and have it wait till I type. The only change
to xterm in this version was in main.c, where the line

        close(open(ttydev, O_WRONLY, 0));

was changed to
        close(open(ttydev, O_RDWR, 0));

The reason for this eludes me, and I'm not in a position to recompile the
source without the fix, but it seems unlikely that its going to change the
behavior you see. I remember the original article posting the problem stated
they were running OSx 4.4. I've tested this xterm with both 5.0 and 5.1. I
suggest your problem is from an old version of OSx. If you are running a
version 5 and still see the problems, you should report it as a bug (by
sending mail to bugs@pyramid.com).

                 Gordon Prieur
      -m-------  Pyramid Technology Corporation
    ---mmm-----  1295 Charleston Rd, P.O. Box 7295
  -----mmmmm---  Mt. View, CA 94039-7295  (415) 335-8533
-------mmmmmmm-  {decwrl,hplabs,sun,uunet}!pyramid!pyrps5!gprieur
    ----------------

ejp@bohra.cpg.oz (Esmond Pitt) (09/11/90)

In article <KARL.90Sep10102251@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes:
> adams@swbatl.sbc.com writes:
>    As to the 
>    /dev/tty problem that hoses getpass(3) (and pg(1), nastily) I've been
>    using the "screen" utility (comp.sources - long ago) to get around
>    this problem until our soon to happen upgrade to 5.0.
>
> Upgrading to 5.0 may not help.  When this topic last came up here, the
> enclosed article was posted.  We changed our xterm sources to
> accommodate, and now we have functional /dev/tty in xterm.  Try it,
> you'll like it.  Although this person didn't think the change should
> fix xterm, it does, at least under 4.4c.

This applies to xterms built in the ucb universe. It is possible by
various subterfuges* to build it in the att universe, in which case the
problem is not evident [OS/x 5.0], because the device is opened in the
correct mode under that flavour.

*Details for porting X11R4 to the att universe are available from me on
request. If there's enough interest, I will post here.


-- 
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz
D

adams@swbatl.sbc.com (Tom Adams - 235-7459) (09/11/90)

In article <607@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes:
>In article <KARL.90Sep10102251@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes:

>*Details for porting X11R4 to the att universe are available from me on
>request. If there's enough interest, I will post here.

I'm curious about the more general problem of resolving references to network
facilities when code is compiled in the AT&T universe.  It's easy enough
when all the references are in a seperate source module, but when someone
mixes networking code with AT&T specific stuff in the same source module
it's a real pain to get going.   Has anyone been able to pull all the
networking stuff into a seperate object library? I've started a few times
and gotten hung up at different places.  This comes up regularly here when
moving code from Sys V machines with added networking facilities. 
-- 
uunet!swbatl!adams or adams@swbatl.sbc.com     
Tom Adams: 314-235-7459: Southwestern Bell Telephone Advanced Technology Lab
BOOKS WANTED: pre-1930 radio, electrical & scientific topics