chuck@felix.UUCP (12/03/87)
Reply-Path: For that matter, any and all patches or enhancements to ksh for ultrix would be appreciated. I would like to find out why I often get the message 'ksh: : Invalid identifier' when I log in from one port but dont get it when I do a set +vx or log in from a different port. Please, send me any ksh mods that you might have. -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 cbosgd!n8emr!lwv HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps We haven't inherited the world from our parents, but borrowed it from our children.
chris@mimsy.UUCP (Chris Torek) (02/05/88)
In article <20344@felix.UUCP> jdp@adiron.UUCP (Powell) writes:
-I don't remember this bug being reported before so here goes:
-
-ULTRIX 1.2 is semi-4.2BSD compatible but 4.2BSD will not exhibit
-this bug:
The bug is in the program that attempts to demonstrate the bug,
not in the kernel. (jdp seems to know that, but his posting may
be unclear to others.)
-readfd = (1 << 3);
-if (select(getdtablesize(),&readfd,0,0,0) < 0)
- fprintf(stderr,"Error in select %d\n",errno);
-else
- fprintf(stderr,"select ok\n");
-The second time and probably all remaining times that select is called,
-it will fail with the error number corresponding to invalid file descriptor.
-Replace the getdtablesize() with the expression (8 * sizeof readfd) for
-portability.
s/portability/correctness/: `8*sizeof(readfd)' assumes that the type
`char' is eight bits wide. Better yet, borrow the fd_set type and
FD_xxx macros from a 4.3BSD <sys/types.h> (which is what DEC should
have done).
-...getdtablesize() and NOFILE under standard ULTRIX 1.2 are greater
-than 32 (namely 64). The readfd parameter is a 32-bit value so it
-can never tell select() to poll file descriptors 32 - 63 but
-apparently select() is looking for advice about all 64 descriptors
-because you told it to. Shame on you :-)
Right.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
lwv@n8emr.UUCP (Larry W. Virden) (05/17/88)
I am in search of a device driver guru who knows tty drivers quite well. In specific, I am attempting to expand the clist buffer size so that I no longer lose data. I can get DZ driver to work with the expanded buffers but the dh driver just 'hangs'; it appears to be handing when attempting to do the uballoc. I need some tips on where to go from here. -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.
andrew@stl.stc.co.uk (Andrew Macpherson) (08/12/88)
You are missing the obvious setenv NAME "The name I want to appear" Works wonderfully. -- Andrew Macpherson andrew@stl.stc.co.uk - or - ...!mcvax!ukc!stl!andrew "It is always a great mistake to treat the individual on the chance that he may become a crowd" -- Mr Justice Codd: (A.P.Herbert)
toivo@uniwa.OZ (Toivo Pedaste) (09/08/88)
Reply-to: toivo@uniwa.OZ (Toivo Pedaste) We have recently installed an Ultrix system which is being accessed through a Decserver. Sessions are being disconnect back to the Decserver local mode and there is no indication of why. Is there some sort of timeout. Is there a log option which will indicate the reason for disconnection.
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (09/26/88)
Reply-to: mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) ->We recently ported Ultrix-32 V2.2 onto our VAX8600. We find that "talk" ->does not work between our system and SUNS when "talk" is initiated by ->the SUN ( works if it is initiated by VAX ). - - This happened to us when we upgraded to 2.2 Make sure talk can read the - file /etc/ttys. I can confirm that the same behavior occurs at my site between Suns and Ultrix 2.2. The /etc/ttys file is mode 555 on the Ultrix system and 644 on the Suns, so read permission for "talk" is not the problem. Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
burzio@mmlai.UUCP (Tony Burzio) (12/23/88)
Reply-to: burzio@mmlai.UUCP (Tony Burzio) I am having difficulties with sending mail from ULTRIX V2.0-1 to other UNIX machines. The address originally was specified in the username@system SMTP format. When the mail is delivered, however, the return path is in the system!username UUCP format. Since the return path should take the SMTP path, replying to the message causes sendmail to quite rightly complain "UUCP host name xxxxx not recognized at this site". Does anyone know how to stop this behaviour? ******************************************************************* Tony Burzio * This computer = 2 1/2 years of my salary! Martin Marietta Labs * Hmmm... Could be time to go to Rio... *******************************************************************
avolio@decuac.dec.com (Frederick M. Avolio) (12/31/88)
Reply-to: avolio@decuac.dec.com (Frederick M. Avolio) 1. Let's have better subject lines than "Submission for ....." [ Oops. My fault. Sorry.... -- Art Z. ] 2. Sendmail.... You need to play with your sendmail.cf file. There are a handful distributed with ultrix in /usr/src/usr.lib/sendmail/cf directory. You seem to be using one that assume uucp connections. You want one that doesn't. Not having your sendmail.cf in front of me this is the bext I can do. What is happening is that a rule somewhere says something like R$+@$+ $2!$1 I suggest running sendmail in debug mode to see who is putzing around with the address Fred
goodrum@unccvax.UUCP (Cloyd Goodrum) (03/18/89)
Reply-to: goodrum@unccvax.UUCP (Cloyd Goodrum) Does anyone out there have any experience running AT&T's c++ under Ultrix V2.0-1? Are there any special problems one should know about? Any info would be appreciated. -- Cloyd Goodrum III UNCC Computer Science Department Charlotte, N.C. unccvax!goodrum@mcnc.org