brighton@phuket.uucp (Bill Carson) (05/30/91)
Here are a couple of really annoying bugs that I'm experiencing on
a NextStation/2.1, and was wondering if anyone else has run across
these, and if there are any fixes available.
My apologies if these are known bugs - I have not seen any reference to
them here or in any documentation (on, or off-line)
------------------------------
1) /usr/ucb/Mail and csh job control
Mail that you're composing (and sending) with the standard BSD Unix
utility, /usr/ucb/Mail, disappears if you suspend the process.
Particulars:
/bin/csh as a login shell, nothing fancy (editmode=dumb), & Terminal.
NextStation, OS 2.1, Workspace v. 218, PostScript v. 2.1.55.3
-rwxr-xr-x ..etc.. 106496 Oct 22 1990 /bin/csh [sum 43676]
-rwxr-xr-x ..etc.. 57344 Nov 11 1990 /usr/ucb/Mail [sum 12738]
To repeat:
% mail whoever
Subject: test message
Type some text here and then edit it (~v/~e), OR filter this text through
a command:
~|cat
(continue)
~p
[ your text here ]
(continue)
And you should see all your text, No problem.
Now suspend this and bring it back to the foreground:
^Z
Stopped
% fg
(continue)
~p
(continue)
And now all your text is gone. Vanished. Very annoying.
Note:
For this bug to manifest itself, Mail needs to have exec'ed
another process that "filters" your mail (via ~v, ~e, ~|)
before suspending/foregrounding the process.
------------------------------
2) uuxqt and the Workspace (netinfo?)
Our machine is a standalone NextStation, no network at all.
I first noticed this problem when receiving mail from offsite,
which arrives over the modem via uucico, and delivered with uuxqt.
Everything works fine, as long as the Workspace is running.
If no one is logged into the console, uuxqt fails to deliver
the mail to the intended receiver.
Particulars:
Using the supplied /etc/sendmail/sendmail.cf, but very slightly
modified (to remove other bugs -- spurious ^M's and spaces in hdrs)
"@(#)main.mc 1.0 88/10/26 NeXT; from SMI 3.2/4.3 NFSSRC"
-r-sr-x--x root wheel 81920 Nov 11 1990 /usr/lib/sendmail [sum 61146]
---s--s--- uucp daemon 32768 Nov 11 1990 /usr/lib/uucp/uuxqt [sum 61201]
Our /etc/passwd is the supplied "barebones" version, and all users
on this machine are added with the UserManager app; thus, there are
no "user" passwd entries in /etc/passwd - they are kept whereever
the UserManager (NetInfo?) hides them.
To repeat:
Given that the hostname of your machine is "phuket",
and that your login name is "brighton",
and you have uucp/mail set up correctly,
force your mail to be delivered via uuxqt:
% (sleep 15 ; echo testing | mail phuket\!brighton ) &
Now, logout of the console. (using command-q with the Workspace menu)
Wait 20 seconds. Login and read root's mail:
% su
...
# Mail -u root
And you will see that the mailer-daemon sent this message to phuket!postmaster
----- Transcript of session follows -----
451 Who are you?: Bad file number
550 phuket!brighton... User unknown
Now, if you do this again with the -v flag:
% (sleep 15 ; echo testing | mail -v brighton ) >& /tmp/x &
(logout, wait, login) You'll get this in /tmp/x:
Who are you?: Inappropriate ioctl for device (bug)
brighton... User unknown (bug)
postmaster... aliased to root (normal)
Saving message in /LocalUser/brighton/dead.letter (normal)
/LocalUser/brighton/dead.letter... Can't create output (another bug :-|
Note:
If you have a dummy entry in /etc/passwd like this, brighton:*:10538:20:::
then the mail gets delivered properly (even though this passwd entry is
not being referenced when you login.)
------------------------------
All in all, I have been very impressed with the 4.3BSD compatibility of
the shell-level utilities, but these are pretty annoying bugs.
In fact, given this compatibility, has anyone been successful in
attaching a UNIBUS or MASSBUS device to the Next computer, as referenced
in the intro(4) man page? :-)
Thanks..
--
Bill Carson brighton@phuket.nbn.com ...!moon!phuket!brighton
And remember to put an OD under your pillow. Maybe the source-fairy will visit.