[comp.sys.pyramid] read from /dev/tty problems

kenj@yarra.oz.au (Ken McDonell) (07/23/90)

This response is in reply to comments made by Bj|rn Gr|nvall
(bg@cyklop.nada.kth.se) from Royal Institute of Technology, Stockholm, Sweden.

I tried to respond by e-mail, but the mail bounced.

I have tried your sample program, and cannot get it to fail on OSx
5.0c-900110, using any of an rcp pty, xterm pty or script pty.

Could you please provide some more information on the version of
OSx in which you see the problem, and the precise conditions under which
you can make it hapen?

> ... I
> have mentioned this in comp.sys.pyramid a number of times but most
> probably the OSx hackers don't read news.

A couple of points,
1. I read news regularly, but have not seen you comments previously (is
   it possible they are not escaping for worldwide distribution?)

2. All sorts of Pyramid foks read news, including the "OSx hackers".

---- 
Ken McDonell			  E-mail:     kenj@pyramid.com kenj@yarra.oz.au
Performance Analysis Group	  Phone:      +61 3 820 0711
Pyramid Technology Corporation	  Disclaimer: I speak for me alone, of course.
-- 
Ken McDonell			  E-mail:     kenj@pyramid.com kenj@yarra.oz.au
Performance Analysis Group	  Phone:      +61 3 820 0711
Pyramid Technology Corporation	  Disclaimer: I speak for me alone, of course.

karl_kleinpaste@cis.ohio-state.edu (07/24/90)

kenj@yarra.oz.au (Ken McDonell) writes:
   Could you please provide some more information on the version of
   OSx in which you see the problem, and the precise conditions under which
   you can make it hapen?

We have the same problem under OSx 4.anything (currently 4.4c, I
haven't bothered to go to 5.0 just yet -- delays, delays) and under
both X10 and X11.  Just start an xterm, any xterm, and you'll find
that /dev/tty is (evidently) not attached to it.  Anything which reads
/dev/tty fails; e.g., just as a quick test, I ran crypt in an X11R4
xterm, got an "Enter key:" prompt which did not wait for me to type
anything.  FTP password prompts do the same thing.  Running "script
/dev/null" in an xterm gets around the problem.

   1. I read news regularly, but have not seen you comments previously (is
      it possible they are not escaping for worldwide distribution?)

This has been discussed here occasionally -- I've mentioned it once or
twice myself.

Is it possible that it works for you because you're running a
Pyr-supplied X11 with probable bug fixes?  Most of us peons just run
the MIT-supplied X distributions.

--karl

bob@MorningStar.Com (Bob Sutterfield) (07/25/90)

In article <KARL.90Jul24094256@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes:
   kenj@yarra.oz.au (Ken McDonell) writes:
      Could you please provide some more information on the version of
      OSx in which you see the problem, and the precise conditions
      under which you can make it hapen?

   We have the same problem under OSx 4.anything (currently 4.4c) and
   under both X10 and X11.  Just start an xterm, any xterm, and you'll
   find that /dev/tty is (evidently) not attached to it.

The quickest test is to say `cat < /dev/tty` to a shell running in an
xterm.  If it returns immediately (as is the case in xterms on
Pyramids running the MIT X distributions), you've found the bug.  If
it waits for tty input (as is the case on lots of other things running
MIT X), you're clean.  The presence or absence of the "-ls" switch
seems to make no difference.  The X server host type seems to make no
difference.

      I read news regularly, but have not seen you comments previously
      (is it possible they are not escaping for worldwide
      distribution?)

   This has been discussed here occasionally -- I've mentioned it once
   or twice myself.

This has happened at least since OSx 4.0 (perhaps 4.0beta, but I'm not
positive I tried it then) and X10R3, and has been occasionally
reported in comp.sys.pyramid and comp.windows.x for several years.
I've got no particular beef with Pyramid on this one, since MIT X is
not their product.  It's just monotonous to explain it to the users...