On Sat, 10 May 2008 11:09:38 -0700, Robert Maas, http://tinyurl.com/uh3t
wrote:



Reading all of the stuff you did to read the screen manpage made my head
hurt. I am not familiar with the terminal you are using, but is there
any way to save the output locally? Then you can do a command like

man screen | cat

and the data is saved locally in a clean text format.

Robert Maas, http://tinyurl.com/uh3t wrote:
By "doing everything at the terminal", I meant on the Unix side.
Perhaps I should have said "assuming all your interaction with
Unix takes place through a Unix terminal session". (The alternative
would be starting up an X11 session and remotely displaying windows
from the Unix machine to the Mac. It is uncommon to do this with
dialup, but definitely possible, and in fact I used to do just
that, occasionally.)

Others may mean something different when they say "dialup", but
when I say dialup, I mean using a traditional modem over a
traditional telephone line. I mean using a system where in order
to make the network connection, you have to dial a telephone number,
because you are using a telephone line. What you do with that
two-way stream of data that the modem allows, once you've established
the stream, does not affect whether I call it dialup. :-)

For what it's worth, you could either (a) use a terminal emulator on
your local side to talk directly to a session on the remote side over
the dialup link, or (b) use PPP or SLIP to multiplex connections
to multiple sessions (using multiple terminal emulators). There
are other options as well, so my point was merely that the slow
speed of dialup generally makes graphical interaction with the remote
system not very practical, and thus you are left with character-based
interaction, and on Unix that usually means interacting through
a terminal session. Which is the case where 'screen' is useful.
Therefore, I was making a connection between dialup and 'screen'
being useful.

Yes, one of the weaknesses of 'screen' is that the names of its
commands and its terse explanations on the help screen are very
much inscrutable. Once you've learned to use them, they're still
hard to remember sometimes. Eventually sheer muscle memory will
probably win out and overcome that, but it's harder to learn than
it needs to be.

That is usually my policy. It's rare (though possible!) that
the hangup of the modem fails to detach the previous screen.
Even if it does, I am fine with retyping "screen -d" to detach
it, then typing my "screen -r" again. Usually, when something
was expected to work but fails, I'd rather take a moment to
analyze it and check if I understand what happened, rather
than just unconditionally charging forward.

There is no explicit feature within 'screen' to do this. But, you
can accomplish it by (ab)using the 'copy' feature. Type control-A
then "[" (or control-A ESC instead) to enter copy mode, and from
there you can navigate around using arrow keys. Hitting enter will
mark the beginning of a region of text to copy, and hitting enter
again will mark the end and perform the copy. But you can also
just navigate around and see what you want to see, hiting ESC to
abort the copy interaction and return to the end of the buffer.

You can enable different sorts of keybindings to use within copy
mode. By default, I think it is 'vi'-like, but it can be changed
to be 'emacs'-like.

The one thing you can't do, as far as I know, is select more than
one screen full of text from the terminal emulator side (i.e. in
your case, the Mac side) to copy out to another program on the
computer running the terminal emulator. This is because the
terminal emulator does not know about the scrollback feature of
'screen'. Indeed, scrolling around using the feature that 'screen'
provides will just appear to the terminal emulator to be more
output that it should buffer. It can make it harder for the
terminal emulator

Ah yes, then you've found copy mode already.

Yes, I mean that the Unix system is expecting to talk to a terminal
(and draw characters onto a grid, and take keyboard input). Your
Mac provides a terminal emulator that the Unix system can interact
with like it is a terminal. 'screen' is a program that knows how to
interact with a terminal, and it also knows how to emulate a terminal.
So Unix treats 'screen' as a terminal, 'screen' behaves as a terminal,
and 'screen' treats your Mac terminal emulator as a terminal as well.

Yes, and sticking to control-Z can be a lot less confusing, because
'screen' isolates separate jobs into separate visual contexts,
which makes it harder to track what's going on, whereas ctrl-Z
intermixes them, which is aesthetically uglier but which allows
you to see the big picture better.

Quite possibly, but it depends. On such a system, modem lines are
often the scarcest resource, because every line costs a monthly fee
from the telephone company.

Main memory and CPU time on the machine are also limited resources,
but not very scarce. At worst, you may use some of those resources,
but at best your process will be idle and Unix will swap the memory
pages out to disk, and you will use neither RAM nor CPU time.

So, the negatives might be small indeed. Your system admin probably
reserves the right to not like it, but whether he exercises the right
is hard to say. :-)

Oh, you said you were using a Mac, and I assumed you meant a
relatively modern one. Nevertheless, the old classic Macs were
a lot of fun, and make a perfectly serviceable computer in many
respects.

Ah, that is a fairly limited situation. It would probably be
possible to get PPP going, since Mac OS 7.5.5 supports, if I
recall correctly Open Transport PPP, and there *may* be software
on the Unix side to do PPP even without any help from root.
(Basically, you'd have a TCP/IP stack in userland software with
the ability to transparently convert your TCP streams into
Berkeley socket calls, so that when you send a "SYN", it does
a connect().)

But, even if you got that working, it would be slow, and to my
knowledge 'rsync' does not run on the classic Macs.

Perhaps kermit is treating text files as binary files, and thus
leaving all bytes unchanged. I'm far from a kermit expert, but
I believe it supports character set conversion and file format
conversion and things like that. So it may be possible to get
it to do the conversion as part of the transfer, with the right
settings. Unfortunately, the documentation is not great (if you
don't have the book), so it will not be trivial.

You could probably do this at the command line to remove a little
of the tedium. I am surprised you don't want Mac format, which
has a simple CR at each line end (rather than CR LF). It's easy
to convert from a Unix (LF at line end) to old-style Mac (CR at
line end) file format with e.g.:

tr '\n' '\r' < unix-file > mac-file

And the other direction with:

tr '\r' '\n' < mac-file > unix-file

You could set up a shell function or alias for that fairly easily
to avoid all that typing:

u2m ()
{
tr '\n' '\r' < "$1" > "$1".mac
}

m2u ()
{
tr '\r' '\n' < "$1" > "$1".unix
}

You should be able run "u2m foo" to convert a Unix-newlines (LF) file
called "foo" into a Mac-newlines (CR) file called "foo.mac", and
similarly for the "m2u".

- Logan

During the critical time, when the modem's mean-time-between-failure
was less than 2 minutes, there was no way to get more than just the
first page or two of the man pages for 'screen' downloaded before
it'd die again and I'd need to start from the top. In theory, if I
knew in advance it was going to be so bad, each time it died I
might have copied what had printed to VT100 so-far to local edit,
then after reconnecting I might have used the 'more' feature of
'man' to immediately skip to the point I had already to pick up
where I left off. But the manual effort of copying*pasting the
appropriate / command to skip might have occupied the last ten
seconds available before the next disconnect, so I might not have
even gotten the / command executed before it died again. Maybe I
was too optimistic. Each time I re-dialed, I hoped the modem would
stay up long enough to get all the man pages output in one piece.
That never happened, but at least one time I got to the place where
it told about the C-a ? command, and then after I got screen
started before the modem disconnected again, one other time it got
to the place where it told me how to reattach that old screen
session, which I had to do about a hundred times that night.

I don't know what you're trying to say there. Where would I "do" a
command like that? The only place I could "do" that command would
be on the Unix shell account, but the modem dies before that
command could finish executing, so what good would that do??

By the way, Saturday modem connections were flaky again, although
not quite as bad as Friday night on the average. Occasionaly the
modem would stay connected for up to a half hour at a time. Today,
so-far the modem has stayed connected all the time since I first
dialed in today (22 minutes ago), through finding your article and
composing this followup so-far. I'm using 'screen' just in case it
goes bad again.

** AT 11:12 PDT, 23 MINUTES AFTER CONNECT, JUST AS I WAS TRYING TO
GET TIMESTAMP TO UPLOAD THIS FOLLOWUP, MODEM LOST CARRIER AGAIN.
RE-DIALING... BACK ONLINE AT 11:14 READY TO UPLOAD THIS.

Thanks for clarifying. Yes, that's my only option for access to
Unix, or to InterNet (indirectly) from home. Most stuff is done in
scrolling mode, but lynx operates in "full screen" mode instead.
But in both cases it's a Unix terminal session on a Unix shell-only
account on a computer system which is dedicated to shell+Web.

That would require some sort of packet-based communication
connecting the Mac to Unix, which is not available here.

OK, just to satisfy my curiosity: What kind of packet connection
did you have between your Mac and the remote Unix? (I'm guessing
PPP or SLIP or DIALNET or ...?)

OK, you're using "dialup" in the generic sense, *anything* using
modems over voice-grade lines, as opposed to DSL or EtherNet or
direct TCP/IP or cable modem or other non-voice-grade digital
service. When I say I use dialup modems with VT100 emulator, I am
using "dialup" in the same sense. But most people nowadays use
"dialup" as synonym for dialup-PPP/or/SLIP.

** SECOND MODEM DROPPAGE TODAY AT 11:28, REDIALING IN BACKGROUND AS
I CONTINUE COMPOSING THIS RESPONSE LOCALLY. PREVIOUS LOSS OF
CARRIER WAS AT 11:12, ORIGINAL LOGIN WAS AT 10:49, SO MODEM'S MEAN
TIME BETWEEN FAILURE IS ABOUT 20 MINUTES SO-FAR TODAY.

That's what I'm doing. That's my only option.

That's not an option for me. My Macintosh has only a 69030 CPU, too
slow to do PPP/SLIP efficiently, and only 8MB of RAM, thrashed
horribly in 1998 when I tried a free one-month trial of AT&T
WorldNet, took 20 minutes just to download the AT&T WorldNet home
page, and 5 minutes just to scroll **LOCALLY** when I clicked the
scroll bar on MS-IE after the page was already downloaded to MS-IE.

** THIRD MODEM DROPPAGE TODAY AT 11:35, REDIALING IN BACKGROUND AS
I CONTINUE COMPOSING LOCALLY. I DIDN'T EVEN *USE* UNIX DURING THAT
BRIEF UPTIME, DIDN'T EVEN BOTHER TO REATTACH SCREEN BEFORE IT
DROPPED CARRIER. NOT REATTACHING SCREEN NOW EITHER, UNTIL I FINISH
COMPOSING OR NEED UNIX FOR SOME REASON.

It is true that downloading images over 19200 bps dialup takes
quite a while, compared to comparably-reasonable quantities of
text. A full screen of text, if I'm scrolling through a file with
'more', or paging through a Web page with lynx, takes 1920
characters (24*80 VT100 screen) i.e. about 1 second, whereas a JPG
to fill the screen would take about 25-100k bytes between a
quarter-minute and a full minute. But that's only on a computer
fast enough with enough memory to run PPP or SLIP efficiently. Even
a full minute to download a full-screen JPG would be "fast"
compared to what this machine is capable of. I tried to download a
an image from Mars from a NASA WebSite over AT&T WorldNet, and
after one hour of download it had gotten only the first half inch
of the top of the image. (I was using GIF-watcher which allows
peeking at a partially-written image while the disk file was still
open for writing from the Web browser. Every 5 or 10 minutes I'd
use it to check progress, which was far slower than the Bob&Ray
skit of Slow Talkers of America.)

If I could run the Web from here, without images, but spend the
extra quarter-to-full minute to download an occasioal image
deliberately, that would be entirely reasonable. Most of the time
the images in Web sites are distracting advertisements flashing all
over the screen, of *negative* value to me. Yahoo! Mail (when I'm
at public library or other public computer lab which has such
access) is especially bad with animated GIFs flashing so badly I
can't concentrate on what I'm trying to read from my e-mail
folders. But when I was trying AT&T WorldNet, even after I waited
20 minutes for the AT&T WorldNet to download, then immediately
typed in a URL for one of my own text-only Web pages, still it took
several minutes to download each text-only Web page, compared to
fraction of second for download plus one second to display with
VT100 dialup to lynx. So even if I could get a PPP service that had
a text-only home page, still it wouldn't be decent here on this
slow small-RAM Mac.

Actually 'screen' is mostly useful only when the modems are flaky,
so that each time the modem disconnects I can get back to exactly
the same screen I had last (except AFAIK 'screen' doesn't keep
scrollback data the way the local VT100 emulator does here, so
direct VT100 when modems are reliable is better than 'screen'
reconnects in that respect).

Other than dealing with reconnections due to flaky modems, what
other valuable use do you consider 'screen' to have? Personally
I've gotten so used to ctrl-Z and %<number> to switch jobs that I
don't at all need 'screen''s feature of switching between multiple
terminal sessions over a single 'screen' activation. *) Also,
using a single session allows me to locally (**) scroll back to
other things I've been doing recently, which multiple 'screen'
sessions within single (***) VT100 screen wouldn't allow me.

* FOURTH MODEM DROPPAGE TODAY AT 11:57 SINCE FIRST LOGIN AT 10:49
(MEAN TIME BETWEEN FAILURES APPX. 17 MINUTES), REDIALING IN
BACKGROUND AS I CONTINUE COMPOSING LOCALLY. AGAIN, I DIDN'T EVEN
*USE* UNIX DURING THAT BRIEF UPTIME, DIDN'T EVEN BOTHER TO REATTACH
SCREEN BEFORE IT DROPPED CARRIER. NOT REATTACHING SCREEN NOW
EITHER, UNTIL I FINISH COMPOSING OR NEED UNIX FOR SOME REASON.

** FIFTH MODEM DROPPAGE TODAY AT 12:02, SAME REMARKS AS ABOVE, BUT
MTBF DOWN BECAUSE THAT WAS SUCH A SHORT UPTIME.

*** SIXTH MODEM DROPPAGE TODAY AT 12:04, GETTING INTO HORRIBLY-BAD
MODE JUST LIKE SATURDAY NIGHT!!

There is one situation where loss of connection *does* almost
always fail to disconnect my login: When I'm at a public InterNet
terminal which supports TELNET, and I've used it to log into my
shell account (so that not only can I see my list of things-to-do
which I edit from home then look at when at public terminal), but I
can actually edit the file to check off things I've already done
(so I won't forget I did them and see them still in the to-do list
next time I'm at a public terminal). From time to time, the TELNET
program on Windows gets a disconnect from host, and almost every
time that happens, when I re-connect and log back in again, I see
I'm still logged in at another terminal, and I don't know how to
kill the other session except to run 'ps' and manually kill the
other processes with the magic KILL flag to force an immediate
KILL, which is usually too much trouble to bother.

Not being familiar with 'screen', I had to consider the possibility
that 'screen' might not detach when the modem craps (*) out, so I
needed to consider learning both the detach-and-reattach and
just-reattach commands. But in fact, what you say is true, it
always detached, so just 'screen -r' has been sufficient so-far.

* 7TH MODEM DROPPAGE TODAY AT 12:11.

Hmm, given that -r usually is sufficient, I agree with your logic
and will probably do what you suggest if ever is otherwise, now
that you've explained it.

I don't understand how that will recover what scrolled off the
screen's emulation of a VT100 screen because my running program
spewed it during the time after the modem unexpectedly disconnected
until the time I could log back in and reattach the screen session.

I need to put 'screen' into a mode of saving (*) *all* text that
rolls off the top of the screen, so that *if* during that mode I
lose modem connection I can later scroll back to view it. After I
put 'screen' into such a save-all-text mode, I need to be able to
interact with my Lisp or other interactive session normally,
including the abilty to press RETURN (ENTER) at the end of each
command (line of input) without 'screen' interpreting it as some
special get-out-of-mode or mark-end-of-saved-data command.
Your description of C-a [ doesn't sound like it'd be useful to me.

* 8TH MODEM DROPPAGE TODAY AT 12:19, RE-DIAL GOT BUSY SIGNAL,
REDIALED AGAIN AT 12:20.

Yes. Thanks for clarifying that my guess was correct.

Yes, especially as I mentionned that the VT100 emulator on my Mac
keeps track of appx. 34 screensful of stuff that's scrolled off the
top of the 24-line window, and I can scroll to any point within
that appx. 800-line virtual screen using the local (Mac) scrollbar
on that window to go back to view something, even to copy blocks of
stuff from already-scrolled-past stuff to paste into local edit
window. I can even go back a few screens to see some line of input
echoed back and copy that and then paste it back in to be executed
again.

Bad assumption. Take a look at what I have:
* REATTACHING 'SCREEN' NOW BECAUSE I'M ACTUALLY GOING TO DO
SOMETHING ON UNIX, GETTING THE URL TO PASTE IN HERE:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
Note that I bought my current Mac for $200 (plus $100 for monitor),
more than ten years ago, from the used/surplus-computer table at a
small Mac-only shop (went out of business 5+ years ago). The
monitor died about 5 years ago, so I had to drive to Fry's (before
my car died 4.5 years ago) and buy a VGA monitor plus a Mac-to-VGA
adaptor (because Mac stuff was no longer being sold anywhere I
could find), another $100 cost. So far that new Dell monitor has
survived except a couple years the '-' button wore out so I can no
longer adjust brightness, so I have to completely shut it off each
night when I go to bed.

Macintosh Performa isn't a "classic". It's newer than a "Macintosh
II", which is newer than a "Macintosh SE", which is newer than the
"Macintosh Plus" which is the only other Mac I owned. The Plus died
in 1999, power/video board overheaded and died for the third time,
and it would cost too much to (*) repair it when Y2K would have
made it impossible to set the date&time after end of 1999 anyway.

* 9TH MODEM DROPPAGE TODAY AT 12:40, SINCE FIRST LOGIN TODAY AT 10:49,
MEAN TIME BETWEEN FAILURES 12 MINUTES, OR 11 MINUTES IF YOU COUNT
THAT BUSY SIGNAL AS ANOTHER FAILURE.

Like I said, I already tried that in 1998, just a few months after
I bought this used computer, and it was so horrendously slow as to
be worse than useless. But if you believe you can make it run
faster, orders of magnitude faster, like 1-2 seconds instead 5
minutes per 2k text-only Web page, like 30 seconds instead of 20
minutes per typical Web page with images, like half-second instead
of 5 minutes per scrolling local window within InterNet Explorer,
feel free to arrange to come over here and give it a try.

It's not allowed to emulate PPP or SLIRP etc. over shell-only
account, so we'd need to use *your* PPP account on *your* ISP when
testing, but if you can demonstrate a way to make it work at decent
speed then I might be glad to pay the extra $5 per month to upgrade
my shell-only account to a PPP+shell account.

Nor mid-archaic Macs. "classic" Mac is Plus or SE running System
4.2 or 6.0.3 or 6.0.7, while mid-archaic Mac (*) is Mac II or
Performa running 6.0.7 or 7.5.5, and semi-new Mac is PowerBook
running 7.5.5, and really-new Mac runs System X (Linux-lookalike)
with Intel x86 CPU.

* 10TH MODEM DROPPAGE TODAY AT 12:55, SINCE FIRST LOGIN TODAY AT 10:49.

I *do* want Mac format at my end. Kermit on the Mac automatically
converts between DOS format along the communication channel and Mac
format on the local disk. Kermit on Unix, on my previous ISP prior
to 2000, automatically converted between DOS format on the
communications channel and Unix format on the remote disk. But the
current ISP has a broken version of Kermit that thinks the host
files must be in DOS format, and breaks totally if I try to
download a file that isn't in DOS format, because it thinks a Unix
format file is all one huge long line, so the entire file is
transmitted as a single packet, which utterly breaks Kermit when it
reaches end-of-file and *still* hasn't seen the DOS end-of-line
mark.

It's been years since I was dumb enough to try to download a text
file without first converting to DOS format, so I don't remember
the exact error message, so I'll do a try just now to refresh my
memory ... OK, it gets all the way to the end of the file, showing
progress in number of bytes, then the VT100 emulator's Kermit
utility beeps and puts up an alert saying that the download was
unsuccessful. The Unix Kermit server now prints out this error
message:

3AEToo many retriesA
*************************
SEND-class command failed.
Packets sent: 161
Retransmissions: 11
Timeouts: 1
Transfer canceled by receiver.
Receiver's message: "Too many retries"
Most recent local error: "Unknown error: 0"

HINTS... If the preceding error messages do not explain the failure:
. Give me a SET FLOW XON/XOFF command and try again.
. Try it again with SET PREFIXING ALL.
. Try it again with SET STREAMING OFF.
. Try it again with SET PARITY SPACE.
. As a last resort, give a ROBUST command and try again.
Also:
. Be sure the source file has read permission.
. Be sure the target directory has write permission.
(Use SET HINTS OFF to suppress hints.)
*************************

(/home/users/rem/) C-Kermit>

Now if I convert the Unix file to DOS format by
query replace ^J ^M^J
then try kermit download again ... hmm, that fails too.
Loading into local text editor, I see the first file attempt is all
one line (which crashes the text editor and freezes the entire Mac
sometimes, although not this time, fortunately), while the second
attempt is just fine Mac-format file up to the point where it gives
the Google Groups copyright character, which is outside the
US-ASCII character set, which explains why the good download
crashed. Here's the relevant text:
Create a group - Google Groups - Google Home - Terms of Service -
Privacy Policy
<A9>2008 Google
That's printed by 'more', which shows hexadecimal code of any
non-ASCII character.

Yeah, before replying to your message, I did this:
- In google groups, clicked on SHOW ORIGINAL button.
- Used lynx to print the entire Web page (*) to a file called 'tmp'.
- Ctrl-Z out of lynx, and used 'more' to spew out screen-at-a-time
the whole 'tmp' file to VT100 emulator.
- Scrolled back emulator locally to find start of the spewed text.
- Dragged cursor from top of spewed text (your message) to bottom,
auto-scrolling as the cursor sits just below bottom edge of window,
until it reached end of your message.
- Used copy-from-emulator command to copy *all* that selected text,
your entire message, header and body, but not the copyright banner
at the bottom because I didn't think I'd want to reply to that.
- Clicked over to my local NNTP edit and pasted your entire message
into there.
Then at that point in replying to your message, when I wanted to
give a demo of Kermit download, I did 'ls -lt | more' to see what
recent file I might want to download, saw 'tmp' sitting there,
decided to try it, not realizing it wasn't a valid US-ASCII text
file, because of that one Latin-1 copyright symbol near the end. (**)

* 11TH MODEM DROPPAGE TODAY AT 13:16, SINCE FIRST LOGIN TODAY AT 10:49.
RE-DIAL FAILED BECAUSE OF LINE BUSY, RE-DIALED AGAIN AT 12:16

** 12TH MODEM DROPPAGE TODAY AT 13:24.

So let me try a different file which doesn't have any non-USASCII
characters in it ... OK, I was mistaken, it doesn't crash Kermit,
it downloads fully, but then it shows as one very long line, which
crashes my Macintosh if the file is larger than the Mac allows
single lines to be in a TextEdit window. It's a good thing I used a
relatively small file, just three thousand 3329 characters (all on
one line after download). I remember the last time I tried to load
such a long file into an edit buffer. It slowly tried to cram more
and more of the text into the edit buffer, first showing that
horizontal scrolling was needed, then starting to wrap around to
show strange black characters on top of the text it had previously
displayed, then that overprinting line got more and more black,
until the entire Mac froze and I needed to cold-boot.

That's no good, because Kermit requires DOS format (CR LF), then
converts to Mac format by omitting LF characters when writing to
disk. That's why if I download a Unix format file (CR only), on the
Mac with CR removed it's all one very very long line.

Let me try in Emacs (which I understand better and can see visually
as I work), replacing LF (Unix) with just CR (Mac) ... done, in
EMACS buffer shows as one long wrapped line with ^M where all the
line breaks used to be. Now gonna try downloading with Kermit ...
hmm, it downloaded fine. Taking a look on the Mac ... hmm, normal
correct Mac file. Oh well, I guess it doesn't make any difference
whether I convert to DOS or Mac format before Kermit download, so
long as I don't leave it Unix format!! Reverse engineering the
Kermit algorithm, I think when writing to Mac disk the Kermit
feature of the VT100 emulator just passes CR like regular text and
omits LF, so both CR-LF and CR on transmission end up CR on Mac but
LF by itself ends up *nothing*.

So I stand corrected, convert LF to either CR-LF or just CR works
equally, but in EMACS (*) if I convert to just CR then it's all one
run-on line which is difficult to see whereas CR-LF shows as normal
line breaks with ^M at end of each line, which is better to view
IMO. So I'll stick to CR-LF whenever I need to download a file that
is too large to download via 'more'.

** 13TH MODEM DROPPAGE TODAY AT 13:46, SINCE FIRST LOGIN TODAY AT 10:49.

By the way, if I try to 'more' that Mac-converted file, it looks like:
From MAILER-DAEMON@yahoo.com Wed Aug 1 04:17:43 2007^M [space.gif]^M X-Ap
parently-To: rem642b@yahoo.com via 209.191.68.160; Wed, 01 Aug^M 2007 04:17:43
-0700^M [space.gif]^M X-Originating-IP: [209.191.68.157]^M [space.gif]^M
Return-Path: <>^M [space.gif]^M Authentication-Results: mta494.mail.mud.ya
hoo.com from=yahoo.com;^M domainkeys=pass (ok)^M [space.gif]^M Received: f
rom 209.191.68.157 (HELO web34708.mail.mud.yahoo.com)^M (209.191.68.157) by mt
a494.mail.mud.yahoo.com with SMTP; Wed, 01 Aug^M 2007 04:17:43 -0700^M [spac
...
If I instead convert to DOS format, then 'more' shows me:
From MAILER-DAEMON@yahoo.com Wed Aug 1 04:17:43 2007
[space.gif]
X-Apparently-To: rem642b@yahoo.com via 209.191.68.160; Wed, 01 Aug
2007 04:17:43 -0700
[space.gif]
X-Originating-IP: [209.191.68.157]
[space.gif]
Return-Path: <>
[space.gif]
Authentication-Results: mta494.mail.mud.yahoo.com from=yahoo.com;
domainkeys=pass (ok)
[space.gif]
...
so apparently 'more' given a DOS format file transparently treats
it as if a Unix-format file, compared to EMACS which when in
Unix-file mode shows with ^M at end of each line. Now if I *start*
EMACS on a already-DOS-file, it uses DOS mode and doesn't shw me
the ^M, just like 'more' does. Let me try to trick 'more' by having
the first few lines be Unix mode then convert the rest to DOS mode
... in EMACS in Unix mode it looks like:
From MAILER-DAEMON@yahoo.com Wed Aug 1 04:17:43 2007
[space.gif]
X-Apparently-To: rem642b@yahoo.com via 209.191.68.160; Wed, 01 Aug
2007 04:17:43 -0700^M
[space.gif]^M
X-Originating-IP: [209.191.68.157]^M
[space.gif]^M
...
Now let me try 'more' on that:
From MAILER-DAEMON@yahoo.com Wed Aug 1 04:17:43 2007
[space.gif]
X-Apparently-To: rem642b@yahoo.com via 209.191.68.160; Wed, 01 Aug
2007 04:17:43 -0700
[space.gif]
X-Originating-IP: [209.191.68.157]
[space.gif]
...
hmmm, apparently 'more' treats each line separately, allowing a mix
of DOS and Unix format lines, both showing without any ^M.

OK, I think we've definitely reached the point of TMI.

Emacs query-replace is easier because (1) I've used it many times,
(2) I can single-step it via comma or space before I press
exclamation-mark to do all the rest, so I can see if I'm getting it
correct before I bury myself too deep, (3) the final result is
right there on-screen before I save to file, to give me additional
confidence I got it right.

Except I need to do it so rarely that it's faster to do the Emacs
query replace manually than to search ~/bin/* to try to find which
shell script I made for doing it more automatically. (*)

** 14TH MODEM DROPPAGE TODAY AT 14:00, SINCE FIRST LOGIN TODAY AT 10:49.

OK, so-far 13 modem droppages just during the time it took me to
compose this followup text locally on my Mac. Now let's see if I
can upload it to the NNTP server before the modem drops carrier
again ...

AFTER I GOT THE TIMESTAMP, JUST AS I WAS ABOUT TO COPY&PASTE THE TELNET
COMMAND TO CONNECT TO THE NNTP SERVER:
14TH MODEM DROPPAGE TODAY AT 14:04, SINCE FIRST LOGIN TODAY AT 10:49.
MEAN TIME BETWEEN FAILURE <14 MINUTES.

Robert Maas, http://tinyurl.com/uh3t wrote:
:
:
Not that you're likely to want to go this route, but if it were a
high priority for you to achieve this, you could probably pull it
off by installing NetBSD on that machine as a replacement for Mac OS.
A Motorola 68030 is not a very fast CPU, but with a well-implemented
TCP/IP stack and serial driver, it should be able to support PPP at
19200 BPS, given the proper software, and I would expect NetBSD to
be able to do that.

The mac68k port is still apparently maintained, judging by the fact
that the latest release, NetBSD 4.0, is available for mac68k:

http://www.netbsd.org/ports/mac68k/
ftp://ftp.netbsd.org/pub/NetBSD/NetB...8k/INSTALL.txt

Of course, you would have to give up the Mac-ness of the system,
but in exchange you would gain the ability to run lots of modern
Unix software. Much of what has been ported to NetBSD should run
on the mac68k edition.

NetBSD/mac68k supports the Performa 600, and has a minimum memory
requirement of 8 MB, so it may be able to run OK on your hardware.

I'm not saying that it's a good idea, but it would be fun to try
as an experiment, just to see if it would work.

- Logan

On Sun, 11 May 2008 19:55:19 -0500, Logan Shaw
<lshaw-usenet@austin.rr.com> wrote:

The 68030 isn't the problem - I once worked on a system that had a
40Mhz 030 driving 4 10-T ethernet ports and a pair of 56K modems all
while doing 3D image processing, print preparation and print
monitoring.

Most likely the culprit is MacOS - as you noted. But even so, 19.2
should be nothing for an 030 Mac with 8MB unless there is quite a bit
of VMM thrashing ... the RS-422 ports are 1Mbps and the AppleTalk
ports 5.5? Mbps, and they are generally reliable under heavy loads.
It's been a while since I played with Macs or MacOS, but IIRC the
network and serial interrupts have higher priority than the disk.
There would have to be a hell of a lot of thrashing going on before
there would be PPP timeouts - the TCP/IP stack is pinned in memory and
the serial port and modem are both buffered.

Is it possible to close applications or shut down daemons and free up
some memory? Not much help I know, but most Macs I've seen had tons
of shit running in the background.


--
for email reply remove "/" from address

Robert Maas, http://tinyurl.com/uh3t <usenet2.3.CalRobert@SpamGourmet.Com> wrote:

It does that automatically. If you find that it's not storing enough
history for you, put

defscrollback 1000

or some other number of lines in your ~/.screenrc. (You say that your
Mac terminal emulator stores about 34 screenfuls of 24-line screens, so
that's 816 lines; 1000 is a slight upgrade, then.)

It's a bit tedious to use, but effective. Basically, C-a [ puts screen
into a strange selecting-text mode during which you can wander back and
forth through the scrollback history; when you've seen what you wanted
to see, hit ESC to return to the usual terminal-emulation mode. The
cursor jumps back to wherever it was before, and the display snaps back
to showing what it was showing before you started.

So you have to switch back and forth between viewing scrollback and
normal interaction, which is annoying, but the feature is nonetheless
very useful. Essentially, when you've been screwed by another modem
droppage: reconnect, hit `screen -r', C-a [ to review history, scroll
about to see what you missed, ESC, and then continue.

Golly. Which version of Emacs are you using? Modern Emacsen (certainly
Emacs 21, 2002) will notice Unix, DOS and Mac line endings automatically
and just continue to edit them. You can convert by visiting the file,
hitting C-x RET f undecided-{unix,dos,mac} RET C-x C-s (say). There's
an indicator in the mode line telling you which coding system -- and in
particular which line-ending) Emacs is using.

-- [mdw]

usenet2.3.CalRobert@SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t) writes:
Yes, they REALLY want you to upgrade to ADSL.

--
__Pascal Bourguignon__

George Neuner <gneuner2/@/comcast.net> writes:

IIRC, on the Macs with serial ports, only the "A" or "modem" port
would have interrupts be of higher priority. The "B" or "printer"
port wouldn't.

--
__Pascal Bourguignon__

Oh, thanks, I misunderstand what somebody said before and/or what
the 'man' page said. I tried copy mode just now, and in copy mode I
looked at the 'man' page (I gave the 'man screen' command and ran
down several pages *before* entering copy mode, then used copy mode
as a way to scroll back). The default was to go back only about
four full screens. I had the darndest time getting *out* of copy
mode, back to regular mode. Finally in desperation I just pressed
space, which said it had set a mark, then pressed space again,
which said it had copied 0 charactes, then pressed space again,
which finally was seen by 'man' already in progress. I ran 'man' a
while longer until I noticed that it said copy mode was like a vi
editor. It said any characters not listed would exit copy mode, but
the list of copy-mode characters was already past the four-screen
buffer, and I couldn't remember what all those characters had been,
so I took a wild guess and pressed =, and it said copy mode was
aborted, so I guess I got lucky.

Oh. I should have scrolled forward (locally on my Mac) in the edit
buffer that contains your message I'm editing my reply to. Then I
would have seen that and not been so frustrated. But I hadn't read
your entire message so I didn't know it later had the info I
wanted. Oh well. Somebody long ago (when the entire ARPANET had
only 64 hosts, 90% of which were military inaccessible) said good
advice is to read everything before doing anything, but nowadays if
you try to read the entire InterNet before responding to anything
... you get the idea? (Do you remember that ad on TV a few years
ago when somebody upgraded to high-speed DSL, and they actually
were able to read all the way to the end of the InterNet, and the
computer monitor displayed a message YOU HAVE REACHED THE END OF
THE INTERNET. THERE IS NO MORE TO SEE.)

GNU Emacs 20.7.2 (i386-unknown-freebsdelf4.1.1, X toolkit)
of Sat Nov 18 2000 on ...
Copyright (C) 1999 Free Software Foundation, Inc.

Do you mean if you are already editing a Unix-format file, so Emacs
is in Unix-file mode, and in the edit you *change* line endings
with query replace, and you're still in that same edit buffer? Or
do you mean if you *start* to edit a file which is *already* in
some non-Unix format? I'll do an experiment where I change line
endings to be Mac format (bare CR without LF), exit editor,
re-start editor, and see what's on-screen ... OK in that case
*after* I have it re-start that file (I re-started EMACS on the
file, but I presume killing the buffer then C-x C-f the file again
would have worked too), it shows (Mac) instead of (DOS) or :---
near the left of the mode line, and on-screen it looks normal
instead of ^M mess. So we're both right, just talking about
different situations.

Let me try figuring out what you mean there ...

The target text contains the following non ASCII character(s):
latin-iso8859-1: ?
These can't be encoded safely by the coding system undecided-mac.

Dang, that copyright symbol again!! That's what I get for being
lazy, editing the most recent file on the disk, which is your
message downloaded from Google Groups via lynx P command.

Hmm, if the purpose of all this is to prepare a file for download
with Kermit, your way is safer, because it warns me if the file has
any non-USASCII characters in it, instead of discovering that near
the end of a Kermit download when Kermit bombs.

Yes, I know about that, noticed it after I *uploaded* a file from
my Mac and noticed that EMACS showed it as a DOS file.

I don't see that specifically. The mode line here just says:
---1(Mac)---F1 tmpmac (Fundamental)--L1--Top------------------------
That's when I load back in the file I previously converted to Mac
format using query replace ^J ^M

Robert Maas, http://tinyurl.com/uh3t <usenet2.3.CalRobert@SpamGourmet.Com> wrote:

It applies some heuristics to the file at visit-time to decide what
kinds of line-endings it has. It then converts the buffer to an
internal format (probably Unix-style line endings) and remembers what
transformation it applied so that it can do the inverse thing when you
save the buffer.

Messing with C-x RET C-f changes Emacs's idea of which transformation to
apply when saving. In particular, it doesn't actually change the buffer
contents at all.

There's also (on Emacs 22 only :-( ) C-x RET C-r which tells Emacs that
its heuristics guessed the wrong coding system and should try to read
the file into your buffer again using one you specify explicitly.

Hmm. I got that wrong.

* Just `unix', `mac' or `dos' work and you don't need the `undecided-'
prefix.

* Emacs 20 doesn't behave the same way as my Emacs 22 here, and
insists on asking you which coding system to use if it can't work it
out. It may be better to shut it up by explicitly asking for
utf-8-unix or latin-1-mac or whatever. In particular, when it asks
you at save time which coding system to use, it /doesn't/ let you
specify the line-ending convention and seems to end up in an awful
mess.

Sorry.

That bit's the line-ending. The `1' is telling you that it's using a
one-byte representation for characters.

-- [mdw]

On Tue, 13 May 2008 15:12:50 +0200, pjb@informatimago.com (Pascal J.
Bourguignon) wrote:

You're definitely right about the ports being different.

I don't have my Inside Macintosh books handy (they're in a box
somewhere - I haven't worked on a Mac in ages), but my hazy
recollection of the priority order puts the disk 5th, behind the
system timer, vertical retrace, Appletalk and serial A.

George
--
for email reply remove "/" from address

Ah, thanks for the explanation. Since EMACS was originally invented
on a PDP-10 where newline is CR-LF, I imagine maybe this mapping
was originally invented to avoid the problem of C-f or C-b ending
up halfway between the CR and LF (or complicated logic to count two
characters in the buffer as one when executing such a command,
especially with repeat count). But I'm just guessing there.

Ah, thanks for the extra explanation!

That wouldn't be any good at all, because I have no way to view
anything except US-ASCII, and Kermit bombs when it encounters any
character with the parity bit on. It's better that I force it to
check for all US-ASCII characters and warn me if that's violated
*before* I start Kermit to download it.

Early last year I wrote software to convert between various
notational conventions:
- UTF-8
- Latin-1
- US-ASCII with brace-pictures for non-USASCII characters.
If after I see the warning I investigate and find it's an
unimportant part, then I just delete the offending character before
trying to convert the file again. On the other hand if I discover
there are a *lot* of non-USASCII characters then I look carefully
to see whether I'm looking at UTF-8 or Latin-1. For example:
Lat1: As<ED> dando una mirada a todos estos a<F1>os, ve<ED>a que no hab<ED>a
BraP: As{i'} dando una mirada a todos estos a{n~}os, ve{i'}a que no hab{i'}a
Utf8: <E8><B5><B7> <E5><88><9D> <E3><80><80> <E7><A5><9E> <E5><89><B5>
Just glancing at the hexadecimal notations given by 'more' shows
whether the non-USASCII bytes are in groups with first byte in
different range from other bytes (UTF-8), or non-USASCII bytes are
individual (Latin-1). Once I recognize whether a passage is in
UTF-8 or Latin-1 I can apply the appropriate conversion to brace
pictures, whereupon I can see the text visually here.

Loading a DOS-format file (converted yesterday, earlier in this
thread), into EMACS, whereupon I see:
----(DOS)---F1 tmp2dos (Fundamental)--L1--Top------------------------
I don't see a "2" before the (DOS), so I guess the notation is inconsistent.

Yeah, I copied that part too from GG's display of your message.
<A9> must be the copyright symbol.

<http://groups.google.com/group/misc.misc/msg/cea714440e591dd2>
= <news:rem-2008jun25-003@yahoo.com>
First of all, I like the way that I can rearrange icons on the desktop
and inside folders and have they stay put until I move them again.
For a personal computer, this is infinitely better than MicroSoft
Windows where every time I re-open a window it rearranges the icons
to standard layout and every time I put an icon on the desktop it
immediately moves to the next available standard grid position
nowhere near where I want it.
The Mac as a personal computer is also better than Unix which
doesn't even have icons on a desktop in the first place.

But it's moot because my Mac has only 19.9 MB free so I can't
install anything of any significant size here anyway.

I'm sure 19.9 MB wouldn't be enough disk space to do it just for
fun to see if it would work.

Thanks for at least trying to suggest an idea. Here's a description
of my situation here, in case you have any more ideas and want to
check if they would work here before spending a lot of time/energy
composing a newsgroup article I have to dismiss as not possible
here: <http://www.rawbw.com/~rem/NewPub/mySituation.html>

Why this response is so belated:
<http://groups.google.com/group/misc.misc/msg/cea714440e591dd2>
= <news:rem-2008jun25-003@yahoo.com>
That was 1998 when I tried AT&T Worldnet and found to be so
horrendously slow that it was worse than useless. That was a long
time ago, but I seem to recall it was thrashing an awful lot. I
suspect InterNet explorer takes a huge chunk of RAM, and the PPP
stack takes another large chunk, and random-accesses within it all
pretty badly. But I have no way to try it again to see if my memory
is accurate.

I have no idea how to get info about whether any PPP timeouts
occurred. Without any data, I can't discuss this topic further.

Yeah, but most of the used memory is in the system: When I go to
Finder and mouse-down on the Apple in the upper left corner and
drag down to the first entree, "About This Macintosh ..." it shows
me a bar chart with numbers, which at the moment show:
- McSink 20k
- Risk 512k (wasn't running when I was trying PPP service)
- System Software 5002k
- VersaTerm 284k (wasn't running when I was trying PPP service)
- Xlisp 2.1g 800k (wasn't running when I was trying PPP service)
so it's not like anything I normally have running *also* (in
addition to InterNet Explorer), except the System Software, is
taking up a lot of RAM.

I'm not aware of any daemons that normally run on a Macintosh with
System 7.5.5, so perhaps you can give me an idea how to search for
them to see if any are running that I don't know about?


-
Nobody in their right mind likes spammers, nor their automated assistants.
To open an account here, you must demonstrate you're not one of them.
Please spend a few seconds to try to read the text-picture in this box:

/------------------------------------------------------------------------\
| |\/| _ _ _ _ _ _ _| _ |_ _ | _ . _ |
| | | \/ _) (_) | ) | ) (- (- (_| _) | ) (- | |_) | | ) |
| / | |
| _ | _ _ __ |_ _ _ _ _ |_ |
| (_| | (_) (- |_) | (_| , | ) (_) |_ |
| _/ |
| _ _ _| _ _ __ |_ _ _ |
| \)/ (_) | ) (_| (- | |_) | (_| . |
\------(Rendered by means of <http://www.schnoggo.com/figlet.html>)------/
(You don't need JavaScript or images to see that ASCII-text image!!
You just need to view this in a fixed-pitch font such as Monaco.)

Then enter your best guess of the text (40-50 chars) into this TextField:
+--------------------------------------------------+
| |
+--------------------------------------------------+

Shortly after I posted my thread-starter, a spammer harvested my
address and sent me two Nigerian 419 spam before I could disable
the address.

After I disabled this address, eleven additional e-mail were sent
to this address, all discarded, no NDN issued in any case. Most of
these additional/discarded messages were probably from the spammer,
but I have no way to know. Not one legitimate message arrived prior
to the two Nigerian spam.

In case anyone reading this thread sent me e-mail and I never
replied, that's why, I never received your e-mail.

Anybody who wants to reply to me privately on this topic
(if you tried before, I hope you saved a backup copy of your message text),
try this address instead (camoflaged here):
make <digit2> <dot> <digit5> <dot> CalRobert <at the same domain as before>
Spammers flood my mailbox with several hundred e-mail per day.
Blame it on them that I have to take such drastic measures to try
to separate the very very few legitimate e-mail I receive from the
thousand times more spam that I receive.
Blame it on Yahoo! Mail for not providing any proper spam-filtering
system whereby I could **reject** any e-mail I don't want, and I
have to resort to a third-party (SpamGourmet) filtering system
which also has the bad design of accepting-then-discarding e-mail
to addresses I've already disabled instead of rejecting the e-mail
so that you'd get a NDN (Non-Delivery Notice) from your mail agent,
but at least SpamGourmet lets me spawn variants of the same basic
address that all feed to the same mailbox so that I can disable
some variant addresses and keep others active while needing to look
in only one mailbox for all the e-mail that arrived via all those
variants.

On Sat, 28 Jun 2008 04:58:14 -0700
make1.5.calrobert@spamgourmet.com (Robert Maas, http://tinyurl.com/uh3t) wrote:

Not sure about how Yahoo handles mail, but I've found that greylisting has worked magic for cutting spam at the server level. The best part is it doesn't pull false postitives based on message content, but delays acceptance of an email (with a 45X error message denoting to retry delivery soon). This is very effective for stopping random return address and volatile open proxy styles of spam. Only false positives are from old SMTP servers that do not adhere to SMTP RFC (the list is very short and virtually unseen on the interweb). Definately worth looking into if you or your mailserver admin can be assed with implimenting it (these days there are many implementations for all the mainstream SMTP servers).
-a

On Sat, 28 Jun 2008 04:58:14 -0700, Robert Maas, http://tinyurl.com/uh3t
wrote:

WRT your original post (after two months ;-) a few remarks:

A "chunk" contains various things:
0 - { bookkeeping: timestamp , reference to filename, flags}
1 - the function name or body (or a reference to it)
2 - the "names" of the parameters that is uses (or references to it)
3 - the actual values for these parameters (or references to it)
4 - the resulting function value.

1 is necessary to re-evaluate the the function, if needed.
2 is necessary to construct the dependency graph (DAG)
3 is the searchkey for the caching. (note: there could be multiple chunks
for the same functionname, but for different function argument values.
4 is the cached function value (payload).

You probably want the topology {0,1,2,3} in core all the time.
It would be pretty costly to do a diskread for every node traveral you do.
(but a traversal would end once you find a node that is up to data wrt
it's precursors.)

If there is no other process writing to the backing files you can
always assume that if a chunk is in core -->> it is valid, and if it is
more or equally recent than it's precursor -->> the cached value is valid.
If it is out-of-date --> recompute it (and mark dirty, or write to file)

The same goes *recursively* for the children (precursors), which implies
that you can never check a chunk's valididy _before having checked it's
children's validity_. Which may become costly.

As you noted yourself before: changing the function bodies or the topology
invalidates it plus all of it's descendants.

HTH,
AvK