[Zope] Zope 2.8.5 install

[Tim Peters]

[Robert Conner]
> Well color me purple, it does work.

Good!  How could anything on Windows fail to work ;-)?

> I was just so used to seeing the "Zope Ready to handle Requests"
> message that when it never appeared I just assumed it was not working
> at all. I've broken Zope on my computer 100 times and always when its
> broken it does not display "Zope Ready to handle Requests". I won't
> make any more excuses for myself here, they don't help anything. Man,
> I'm sorry for the inconvenience.

Not a problem:  if one person doesn't understand what they're seeing,
then at least a hundred more won't understand it either, and it's very
good to have a discussion about it archived on a public mailing list
then.

FWIW, I don't know why Zope doesn't display anything useful in the
console anymore, and I don't even know whether that's unique to
Windows.

>> Or another way (something I'd never do in real life, but I guess some
>> people do)

> I always run Zope in the console.

So do I, but there's difference:  I open a DOS box and type
"bin\runzope" myself.  What I never do is use the Start menu
"shortcut".  A DOS box you open yourself stays visible even if Zope
dies ungracefully, and after the first time you type "bin\runzope" you
only have to hit two keys (up-arrow ENTER) to start it again.

> The only reason I even use the Windows version is for development. As far as I can
> tell the fastest way for me to stop and restart Zope if to close down the command
> window and then start it back up again. When I develop, I restart Zope
> all the freeking time, so the faster the restart, the better.

Doesn't the ZMI have a "restart Zope" button?  If you open your own
DOS box, then a sloppy all-keyboard restart dance is "Ctrl+Break
up-arrow ENTER", and a careful all-keyboard restart dance is "Ctrl+C
up-arrow ENTER".  The latter gives Zope a chance to close files
gracefully, but by the same token it takes longer for Zope to shut
down.  "Ctrl+Break" kills the process instantly (and runs some risk of
leaving data in I/O buffers without writing it to disk).