Historical questions about mail daemon
Charlie
appearances of the mail daemon.
3.4.3 for windows which I play now does not.
What happened (not that I'm complaining)?
Also, was there ever a version where the mail daemon announced "real"
mail (from outside the game)?
hept...@gmail.com
James
> When I was playing Nethack years ago, one feature was random
> annoying appearances of the mail daemon.
> 3.4.3 for windows which I play now does not.
> What happened (not that I'm complaining)?
As far as I know, it was always a build option.
> Also, was there ever a version where the mail daemon announced
> "real" mail (from outside the game)?
The only ones I've seen all did.
Basically, it was a very useful option in the oldest days,
before advanced GUIs, when nethack (or was it still hack or
rogue back then?) took over the entire screen; it replaced the
mail check in the shell and other places. It's been a long time
since I've seen anyone compile it in, though, and I suspect that
it wouldn't work if you're system doesn't have a mounted mail
directory (e.g. you're using POP or IMAP).
--
James
Janis Papanagnou
> When I was playing Nethack years ago, one feature was random annoying
> appearances of the mail daemon.
>
> 3.4.3 for windows which I play now does not.
>
> What happened (not that I'm complaining)?
See the Nethack Guidebook...
A mail daemon may run up and deliver mail to you as a scroll of
mail (on versions compiled with this feature). To use this
feature on versions where NetHack mail delivery is triggered by
electronic mail appearing in your system mailbox, you must let
NetHack know where to look for new mail by setting the ``MAIL''
environment variable to the file name of your mailbox. You may
also want to set the ``MAILREADER'' environment variable to the
file name of your favorite reader, so NetHack can shell to it
when you read the scroll. On versions of NetHack where mail is
randomly generated internal to the game, these environment
variables are ignored. You can disable the mail daemon by
turning off the mail option.
And in the options section...
mail
Enable mail delivery during the game (default on).
>
> Also, was there ever a version where the mail daemon announced "real"
> mail (from outside the game)?
Sure. I only get mail from outside the game. (Playing on Unix, though.)
Playing at NAO you can receive mails from other logged on wachers, BTW.
Janis
Doug Freyburger
>
> When I was playing Nethack years ago, one feature was random annoying
> appearances of the mail daemon.
>
> 3.4.3 for windows which I play now does not.
Windows does not run biff and so can not announce incoming e-mail
messages.
> Also, was there ever a version where the mail daemon announced "real"
> mail (from outside the game)?
I remember playing the version where Rodney had the Amulet and there was
an arena as an endgame on old Solaris boxes. Reading a scroll of mail
on those hosts launched mailx in a sub-shell. I tended to turn off biff
on those hosts because Nethack wasn't the only mail aware application I
ran.
James
> Charlie wrote:
> > When I was playing Nethack years ago, one feature was random
> > annoying appearances of the mail daemon.
> > 3.4.3 for windows which I play now does not.
> Windows does not run biff and so can not announce incoming
> e-mail messages.
Is it a question of biff, or more generally, how the system
handles email. On historical Unix, email was placed as it
arrived in a user readable directory; nethack, and a lot of
other programs, would check the timestamp of this directory, and
notify you when it changed. Most home systems, however, and a
lot of office systems as well (and all Windows systems I've
seen), now use POP or IMAP for mail delivery, with no local
directory; I don't think nethack can handle these.
(Technically speaking: the traditional Unix mail transfer agent,
sendmail, works in push mode: when someone wants to send me
mail, he contacts the demon directly, and "pushes" the mail
directly onto my system, where it is stored. POP and IMAP work
in pull mode: when someone wants to send me mail, he contacts
some more central mail server, who stores the mail for me until
I actively "pull" it up onto my system.)
> > Also, was there ever a version where the mail daemon
> > announced "real" mail (from outside the game)?
> I remember playing the version where Rodney had the Amulet and
> there was an arena as an endgame on old Solaris boxes.
> Reading a scroll of mail on those hosts launched mailx in a
> sub-shell. I tended to turn off biff on those hosts because
> Nethack wasn't the only mail aware application I ran.
Most Unix shells can still be configured to check the mail file
before outputting the prompt. If you're running a single user
Linux at home, using POP or IMAP to get mail from your
provider's server, that feature is useless.
--
James Kanze
Jorgen Grahn
> On Oct 30, 6:42 pm, Doug Freyburger <dfrey...@yahoo.com> wrote:
>> Charlie wrote:
>
>> > When I was playing Nethack years ago, one feature was random
>> > annoying appearances of the mail daemon.
>
>> > 3.4.3 for windows which I play now does not.
>
>> Windows does not run biff and so can not announce incoming
>> e-mail messages.
>
> Is it a question of biff, or more generally, how the system
> handles email. On historical Unix, email was placed as it
> arrived in a user readable directory; nethack, and a lot of
> other programs, would check the timestamp of this directory, and
> notify you when it changed. Most home systems, however, and a
> lot of office systems as well (and all Windows systems I've
> seen), now use POP or IMAP for mail delivery, with no local
> directory; I don't think nethack can handle these.
Correct; unless I'm mistaken nethack does what everyone else (biff,
xbiff, finger, your shell ...) does and compares timestamps on your
$MAIL file (the "mail spool").
It's not just historic Unix either -- a Linux host or any other Unix
still has that mail architecture. It's just that many people bypass
it for most of their daily mail (by using some webmail interface, or
reading remote over IMAP).
> (Technically speaking: the traditional Unix mail transfer agent,
> sendmail, works in push mode: when someone wants to send me
> mail, he contacts the demon directly, and "pushes" the mail
> directly onto my system, where it is stored. POP and IMAP work
> in pull mode: when someone wants to send me mail, he contacts
> some more central mail server, who stores the mail for me until
> I actively "pull" it up onto my system.)
But what happens next can be that whatever pulls the mail (often the
fetchmail utility) feeds it into sendmail, which places it in your
mail spool, which in turn makes the little blue & run around.
...
> Most Unix shells can still be configured to check the mail file
> before outputting the prompt. If you're running a single user
> Linux at home, using POP or IMAP to get mail from your
> provider's server, that feature is useless.
It depends on how you use POP or IMAP (see above).
I run my mail the traditional way -- but not on the same machine where
I run Nethack, unfortunately.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
James
> On Mon, 2009-11-02, James wrote:
> > On Oct 30, 6:42 pm, Doug Freyburger <dfrey...@yahoo.com> wrote:
[...]
> > Is it a question of biff, or more generally, how the system
> > handles email. On historical Unix, email was placed as it
> > arrived in a user readable directory; nethack, and a lot of
> > other programs, would check the timestamp of this directory,
> > and notify you when it changed. Most home systems, however,
> > and a lot of office systems as well (and all Windows systems
> > I've seen), now use POP or IMAP for mail delivery, with no
> > local directory; I don't think nethack can handle these.
> Correct; unless I'm mistaken nethack does what everyone else
> (biff, xbiff, finger, your shell ...) does and compares
> timestamps on your $MAIL file (the "mail spool").
> It's not just historic Unix either -- a Linux host or any
> other Unix still has that mail architecture. It's just that
> many people bypass it for most of their daily mail (by using
> some webmail interface, or reading remote over IMAP).
It's more a question of your mail transfer agent, than of the OS
itself, I think. And while it's true that all of the current
Unix I know provide sendmail (and generally some more modern
incarnations as well, which work more or less in the same
manner), most Internet providers for home systems (at least the
ones I know) will only feed POP or IMAP, and not SMTP (which is
what sendmail uses) directly. If not, I'd use sendmail on my
Linux box at home, if only because it is immediate.
> > (Technically speaking: the traditional Unix mail transfer
> > agent, sendmail, works in push mode: when someone wants to
> > send me mail, he contacts the demon directly, and "pushes"
> > the mail directly onto my system, where it is stored. POP
> > and IMAP work in pull mode: when someone wants to send me
> > mail, he contacts some more central mail server, who stores
> > the mail for me until I actively "pull" it up onto my
> > system.)
> But what happens next can be that whatever pulls the mail
> (often the fetchmail utility) feeds it into sendmail, which
> places it in your mail spool, which in turn makes the little
> blue & run around.
That's one possibility, but since you're using POP or IMAP
anyway, why bother.
The other point, of course, is that today, you can have your
mail client up and running in permanence, in another window.
The main advantage of having the shell and various other
programs letting you know when mail arrives is when only one
program can access the screen and the keyboard at a time. You
don't have to interrupt what you're doing to explicitly check if
any mail has arrived.
--
James Kanze
Jorgen Grahn
> On Nov 9, 6:34 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> But what happens next can be that whatever pulls the mail
>> (often the fetchmail utility) feeds it into sendmail, which
>> places it in your mail spool, which in turn makes the little
>> blue & run around.
>
> That's one possibility, but since you're using POP or IMAP
> anyway, why bother.
Because it makes the blue '&' run around ;-)
That's actually part of the reason I run it that way. It brings the
mail into the existing infrastructure, with procmail, finger, biff and
stuff, and it makes me less dependant on any specific mail client.
Also, my mail client of choice (Mutt) assumes that this infrastructure
exists. It doesn't know SMTP, and the POP3/IMAP support is (from what
I've heard) spotty. The only thing it does well is to read and write
mail.