47 new of 74 responses total.
You get two guesses.
so where's your mail file kept, then, walter?
Try
!man getmailfilename mailfmt
!cat /etc/mailfmt
I hope to update sshd with a version of openssh sometime soon.
So to fix the problem in ssh, just add a line to my .profile that says setenv MAIL=/var/spool/mail/e/a/ea or is there something else that I need to do?
Since your login shell is .csh, you should put the line
setenv MAIL /var/spool/mail/e/a/ea
in your .login file (note: no "=" character in the command).
That line should go in your .login (as csh is your login shell).
Those with sh/ksh variants should do:
MAIL=/var/spool/mail/x/y/xyz
export MAIL
Where xyz is their login ID.
Wups, remmers slipped in, but that's a good thing as I didn't look closely enough to notice the extraneous "=".
Thanks John. #32 seems to have fixed the problem.
/var/spool/mail/i/z/i
This response has been erased.
I"ve had trouble dialing in for the past few days. Last night I tried 5 phone numbers, starting with 3000, and made two tries on each number.
!df says the /bbs partition is 100% full.
Just now, dial-=in connects but gives no response.
Like #40, and about the same time this afternoon. Trying another line (-3554 ?) got me in okay, -3000 worked okay just now...
Filesystem kbytes used avail capacity Mounted on /dev/sd0h 284215 254877 917 100% /bbs
If I run the mesg command right now, it gives the error
Unable to find your tty (ttyte) in utmp file
Another user in party had a similar message on the same tty (ttyte). A scan of party should uncover the info which was dumped into party at that time.
More complaints in party about ttyte.
I notice Picospan and Backtalk sometimes disagree on which items are "new" and which have "new responses". For instance, when I join the DIY conference in Picospan, I see: /------------------------------------------\ | 7 newresponse items and 4 brandnew items | \------------------------------------------/ and when I join it in Backtalk I see /------------------------------------------------------\ | Diy has 31 items: 11 brand new, 0 with new responses | \------------------------------------------------------/
Looked into that a bit. Copied over Mark's .fixit.cf file. I see the two different messages too. The items that the disagreement is about are all ones that were marked "unseen" when Mark joined in October of 1998 and have since had new responses posted to them, making them "new" items. Doing "read brandnew" shows 4 items, while "read newresp" shows 7. However the seven "newresponse" items, when you read them, show item text and all responses - it doesn't think any part of it is old. They sure act like brandnew items. I can't figure out why Picospan thinks 7 of these are newresponse items. My diagnosis: Picospan bug.
The ttyte bug bit again tonight; Leslie was on that tty and could not send me tels.
Re #47: Weird. THanks for the diagnosis.
An "unseen" item is treated as an item that is up to date (so "read new" won't show you ancient crud), but for which you haven't seen any responses (so if someone else responds to it, you'll see what happened before in that item.) Since it was previously "up to date", it's not "brandnew", so a response to it makes it a "newresponse" item. Since you haven't seen any responses in it, it's going to look very much like a "brandnew" item - it's the same logic in any case, so I can't imagine why you'd want it to look different. I suppose I could have invented a 3rd category, "newunseen", and perhaps even put more logic into the item range processing so you could say things like "read new except newunseen", but that seems a bit like overkill. (Then again, hmmm....) There's a balance here between being too complicated or too simple. What I think is more important is the behavior for "d new" (or when you join a conference) - the "X newresponse and Y brandnew" message. That should give you a notion of how busy this conference is, and what sort of activity is going on. Counting "newunseen" items as "newresponse" is I think more fair than counting them as "brandnew". That the consequence of this is that "read newresponse" shows an item that looks and acts much like a "brandnew" item is, I think, a reasonable tradeoff for consistency's sake. So, um, no, I don't agree this is a "bug" in PicoSpan, it's doing what it was designed to do, and there are reasons why the design was so. You could argue that the design is faulty, and that "unseen" items ought to in general be treated differently, and you'd not be alone. Thing is, I don't know of any graceful way to allow people to "catch up", and I'm convinced I'd be catching flak no matter what solution I picked.
No, mdw, I think you did it correctly as did janc.
I think Backtalk just breaks it out differently? Picospan is telling
you there are 7 new responses to 7 items that you didn't ever read after
you joined and 4 new items since you joined. Backtalk is saying there
are 11 items that you haven't read ( 7 posted before you joined and 4
posted since the last time you read).
I think mdw has actually put quite a bit of ('human engineering')
thought into how people actually can usefully use picospan - something
that is extremely rare for a programmer to do (consider Micro$oft Word
for example). 'janc' has done a far better job than most as well
(although I wish there was a way to show the poster's login on item list
so I can easily click the box to forget all of that horrible 'bdh's
posts...)
(For example of shitty coding, consider programs (such as WORD(thless)) that have a 'fonts' option. How typically they display a list of font names (only sometimes if you click on one displaying what they look like) like I really am a typesetter and know the exact name of the font I want to use (Personally, I really was and know far more about fonts than I care to, but I am not your average (l)user). How better the interface would be if the 'fonts' listed a chart of pictures of the various fonts, allowed you to click on one, and then a scroll bar to select the available size (fixed or dynamic). The average 'joe user' doesn't need to know the 'technical name' of the font he wants to use, nor really cares.)
I just dialed in, and got the message "unable to find your tty (ttyte) in utmp file" In fact, I got it twice. Is this a major thing?
eeyore ttyte 216.93.104.37 Fri Feb 2 01:06 - 01:06 (00:00) eeyore ttyte 216.93.104.37 Fri Feb 2 00:58 - 01:06 (00:07) It is rather odd. Perhaps a file system ran out of space and the utmp (or wtmp) files are 'insane' and this error message is returning the wrong string (or defaults due to nonexistant string) for the actual error?
I got that message several times this week too. But it did't seem to affect my use of pine or bbs so I did't worry about it.
(actually, in the version of Word I use the individual fonts are all listed in their font so you can see what they look like.)
(I agree with Mooncat, they started doing that on later versions of Office/Word 97, and it's standard with Word 2000)
There are approximately 25 users on the system, but there's a telnet queue. That doesn't seem right.
puzzled? !tel xxxxx tel: Panic - Unable to find your tty (ttyq5) in /etc/utmp ! (say, is this unusual?)
Got hangups on -3000 and -5041 dialing in just now. (-3554 worked.) The modems played a few second, then *click* - no "CONNECT...", no "Welcome to Grex...".
Basically, the ttyte thing and the tel thing are signs that the utmp file is messed up. Some energetic staff member should fix it. I'm not energetic.
some dumb sunovabitch has managed to totally fill /a - please to clean this up? My partfile is now trashed.
I'm getting "Authorization Failed" messages from Backtalk.
I'm also getting "Authorization Failed" from Backtalk. Glad to know it's not just me.
Bad participation file. /a problem?
/a filled up yesterday.
There is a login queue, but there are under 40 users logged in. This seems to have happened to me several times today. ??
I got a long queue, but it went from 22 to 21 to 10 to 2 to on. In rather rapid succession. I thought that was a little odd...
Really bad lag right now.
resp:58, resp:67 :: today it's 35 users on Grex and a queue of 9. This isn't the way the system is supposed to work: it's like putting up a unnecessary FULL sign.
I've noticed this problem too.
It's something staff can fix when it occurs, but only Marcus would know the long-term problem/solution.
Could be a denial-of-service attack, I suppose. The queue does serialize actually opening a pty, so if several requests come in "at once", the extra people could end up in the queue even though there are apparently empty slots.
(net connections have been choppy and stuttered over the past few hours. dunno if it's just Grex or if it's actually this end of the net.)
You have several choices: